Onderwerp: Database layout voor monitoring script

Hoi,

Wij zijn bezig ons monitoring script uit te breiden, we willen namelijk nu onze statistieken gaan loggen. Omdat we met dit script daarna ook het monitoren als service willen aanbieden, moet de database layout redelijk efficient zijn (weinig ruimte innemen, om te zorgen dat het doorzoeken van de database lekker snel gaat).

Op dit moment gebruik ik een simpel script om na downtime de tijd (in seconden) en de datum+tijd naar de een andere table te loggen. Dit is te doen als je niet zo veel statistieken hebt (van één server, bijv), maar is niet meer grappig (denk ik) als je straks elke dag 500 servers eruit hebt liggen (dat betekend dagelijks 500 rows erbij).

Is mijn manier (alle stats loggen naar één table) slim, of kan ik beter statistieken na, bijvoorbeeld, een maand overzetten naar een andere table (en dus dan de stats van exact een maand terug 'catchen', door ze per server op te gaan tellen). Nadeel daarvan is wel dat je minder exacte statistieken hebt (je kan na een maand enkel de stats bekijken van, bijv, een maand).

Of is het misschien slim om bij elke 100 (ik roep maar wat) servers een aparte table/database aan te maken? Het doorzoeken van de rows is dan natuurlijk een stuk minder intensief (minder te doorzoeken), het aantal rows te doorzoeken blijft dan overigens wel gelijk (enkel versprijd over verschillende tables of databases).

Kan iemand die ervaring heeft in het verwerken van veel gegevens hier misschien wat over zeggen? Of ben ik nu gewoon 'overdreven' bezorgt, en is 100k rows helemaal niets om je zorgen over te maken.

Jochem

100k rows is niets om je zorgen over te maken als je indexes goed staan. Als het echt te groot wordt is het wel een idee te gaan archiveren, maar denk niet dat je dat punt snel zult bereiken.
Wat je absoluut niet wil is dat je dezelfde soort data in meerdere tabellen opslaan. Verder zou ik erop letten dat je je database aardig normaliseert, zodat je niet bijvoorbeeld 50.000 keer de servernaam opslaat, maar deze maar 1x opslaat en dan een aparte tabel met servernaam <> id koppelingen hebt. Maar dat behoort tot de basiskennis bij relationele databases.

Bedankt.

Als ik het laatste goed begrijp, raad je dus in principe per server ook nog een aparte table te maken. Maar dat komt er dus op neer dat ik straks 2000 tables met id's (van de servers) in m'n database heb staan (als wij 2000 servers zouden monitoren). Is dat wel 'normaal' en/of goed voor de performance? Of begrijp je dan verkeerd en bedoel je dat niet?

Jochem

Langzame en slechte database:

http://www.ff.net/langzaam_db.jpg

Snelle database:

http://www.ff.net/snel_db.jpg


Uiteensplitsen zodat er nergens dubbele rows komen (normalsatie, geloof 2e normaal-regel). Op deze manier blijft je db overzichtelijk en snel. De pijlen die je ziet zijn Foreign Keys, iets wat MySQL niet super goed ondersteund, maar wel MSSQL bijvoorbeeld.

Ik weet totaal niet wat je opslaat dus heb ik maar even wat gemaakt (zie plaatjes), maar ik denk dat je het idee wel snapt. Database ontwerp is een vak, niet iets wat ik in een paar posts kan uitleggen Zijn trouwens ook de best betaalde mensen in de IT-wereld, omdat een goed ontworpen database gewoon de backbone is van een (web)applicatie.

Mocht je iemand kennen die Informatica gedaan heeft op de Uni/HBO dan raad ik aan om die even lief aan te kijken en een snelle database voor je te ontwerpen. Scheelt je veel hoofpijn later. Mocht je het toch zelf willen onthoud dan dat het niet gewenst is dat je 2 rows hebt waar enkele waardes hetzelfde zijn; uitsplitsen in meerdere tabellen.

Uitsplisten doe je dus niet door van elke server een tabel te maken! Zie het voorbeeldje. Eigenschappen groeperen. Tabel servers heeft 500 rows op deze manier (als je 500 servers hebt). Elke error heeft een verwijzing naar de server. Op deze manier zijn de SQL queries ook veel makkelijker.

Beste Jochem,

1000 rows is echt niks voor een database. Enkel de ellende begint als de database gaat groeien en je over een tijd meer gegevens uit je database wilt halen. Een goed database ontwerp is essentieel daarvoor. Als je voor een bepaalde systeem of klant de gegevens naar voren wenst te halen zou het al aan te bevelen zijn om de gegevens over meerdere tabellen te verdelen.

Als je wilt kan ik wel eens mijn kritische naar je database ontwerp kijken en tips en adviezen geven. Dit geheel kosteloos :-)
Stuur ff SQL scriptje van je database dan kijk ik er naar.

Met vriendelijke groet,
Marcel Witt

Ok, bedankt FreddyB, een dergelijk idee had ik inderdaad ook al, bedankt voor het duidelijke voorbeeld!

PlanPro, ik stuur je graag m'n SQL script, deze komt er vanavond of morgen aan. Het was overigens 100.000, niet 1.000 .

Jochem

Hoi Jochem,

Laat ik nou afgestudeerd zijn in de richting "databases". Wat de posters hierboven zeggen is allemaal 100% correct.

In lekentaal moet je inderdaad eigenschappen groeperen en niet dezelfde data dubbel in je database hebben staan.

Een database heeft juist door zijn manier van werken geen last van grote datasets. Dat is het voordeel van een database ten opzichte van een bestand, je kunt er een index op bij laten houden waardoor je heel snel resultaten eruit kan opdiepen.

Ik zou voor jullie server (servers?) nog niet gaan denken aan opsplitsen of archivering. Tegen de tijd dat je database de bottle neck wordt kun je meestal makkelijk zat de ene implementatie omzetten in de andere, maar voor die tijd vermoed ik dat je scripts al een keer of wat over de kop zijn gegaan.

http://www.yapf.net/faq.php?cmd=100&itemid=700

Allemaal door lezen, en je kan aan de slag.