Hej!
Jeg går og overvejer at ændre radikalt på følgende database :
http://statdb.dassic.com/files/mysql-statdb-database-tables.sql
....som bruges i løsningen på
http://statdb.dassic.com/
Ovenstående database er let at implementere og let at forstå & bruge, men
har følgende problemer :
1. Normaliserer ikke data (hvilket bevirker stort set alle efterfølgende
problemer ;-().
2. Bliver for langsom hvis man propper mange data ind (selv med index).
3. Nødvendiggør at man laver select distinct på mange data, da meget af det
der skal laves distinct på ikke er lagt ud i dedikerede tabeller.
4. Gemmer meget redundant data (jvf. 1) som bevirker at database bliver sløv
og fylder meget.
Det meste fungerer fint for de fleste i den eksisterende løsning, men når
man har 200 unix systemer registeret som sender data hvert 5. minut så er
det nogle hundrede MB om dagen, og det holder dette database design ikke
til....det bliver for langsomt og for stort.
I næste version har jeg derfor tænkt mig at lave lidt om, men jeg ved ikke
lige i hvilken retning der er bedst at gå. Råd fra erfarne ønskes :)
Mit umiddelbare bud er at denne type data egner sig perfekt til en form for
træstruktur hvor jeg definerer nogle grundliggende ting såsom cpu, memory,
disk og de underliggende elementer under hver af disse kategorier og så
efterfølgende ender op med kun at skulle indsætte en tidskode (som evt. kan
være fælles for alle systemer) samt de rå værdier.
Dette vil uden tvivl gøre access til data _meget_ hurtigere, og eliminere
redundans.
En nem implementering ville være noget med for hver unik type data oprettes
med et identifikations ID i en tabel, og herefter oprettes der tabeller per
unik type data og som navngives med samme ID navn/nummer.
Det vil give mig mit performance boost, være nemt at lave, men resultere i
en hulens masse tabeller. Ikke videre smart så vidt jeg kan se da jeg
hurtigt vil ende op med flere tusinde tabeller.
Alternativet er at lade data parseren analysere de data den modtager lidt
dybere og herefter gå i gang med at oprette/vedligeholde tabeller der
indeholder de enkelte delmængder af de ting der identificerer data således
at man har en tabel der kun indeholder filsystemsnavne og en anden med
system navne og filsystemstabellen så linker til IDs i disse og derudover
kun gemmer de rå data (size, free, used) og evt. tidskode.
Det er mere komplekst at lave da jeg skal lave en masse kode der
vedligeholder en træstruktur implementeret i en SQL database, men
umiddelbart tror jeg at dette er den *rigtige* måde at gøre det på, not ?
....er der nogen "best practise" m.h.t. denne slags data ?. Eller nogen her
der har erfaringer med at implementere den slags ?
Jeg har luret lidt på den måde man gemmer på i RRDTool (round robin fil
database). Ikke SQL, men ganske genialt.
Deruver har jeg kigget lidt på BMC Patrol som i sit PSL sprog og sit design
netop implementerer en dynamisk træstruktur...men jeg har ingen idé om
hvordan den underliggende database ser ud.
Ville det være bedre at bruge LDAP til dette ???. Med LDAP får jeg jo
strukturen foræret.
/Jesper