Onderwerp: Aanschaf nieuwe DB server

Een hotspare is handig maar ivm continuïteit ga ik mee met John (Systemdeveloper). Als je dan toch al een luxe oplossing hebt waarom dan hotswap achterwege laten?

@TS: als je niet zeker weet wat de db omvang is of wat meer info zou willen zoals de situatie nu is stuur dan even een PB. Ik kijk dan even met je mee.

Oorspronkelijk geplaatst door vDong

Een hotspare is een extra disk die al in de kast zit en automatisch gebruikt wordt zodra er een disk uitvalt. Hoewel het wel handig is om hotswap te hebben om de defecte disk te vervangen, is het absoluut niet noodzakelijk voor het gebruik van de hotswap disk.

Na 20 jaar weet ik echt wel het verschil tussen hostspare en hotswap, hoor
Je pakt toch een hotspare om sneller zonder downtijd weer een werkende raid te krijgen? Uiteraard is een hotswap niet nodig als je zin hebt om je klant alsnog down te gooien, ook al is het binnen een nachtelijk onderhoudswindow, en de bak open te schroeven.
Echter met een hotswap kun je dat gemakkelijk live en overdag doen of via een telefoontje naar het dc.

@TS: als je niet zeker weet wat de db omvang is of wat meer info zou willen zoals de situatie nu is stuur dan even een PB. Ik kijk dan even met je mee.

In de eerste plaats gaat het om mobiele devices die via een simkaart hun verzamelde data naar ons backoffice stuurt waar deze data in de database wordt gezet. Omdat het om aardig wat devices gaat die elke 5 / 10 / 60 seconde hun logwaardes sturen is de database echt groot. Mede ook door de index om het allemaal een beetje te laten performen. Het kan misschien veel sneller met betere hardware maar het was acceptabel en het budget was toen kleiner dan nu. Er zijn meer klanten, dus meer data waardoor de database nog sneller groeit en daardoor gelukkig nu ook een groter budget. Voordeel is wel dat we dus heel veel data opslaan maar dit niet continu wordt uitgelezen, de grote queries vallen dus best mee. De database is dus groot omdat we veel opslaan maar deze data wordt niet continu gebruikt zeg maar.

Dan nu de getallen, er zijn wat overige databases maar het overgrote deel wordt bepaald door een database (uitgelezen met MySQL Administrator) van 75GB en een index van 105GB.

CREATE TABLE `database`.`log_data_uint16` (
`deviceid` mediumint(8) unsigned NOT NULL default '0',
`logid` smallint(5) unsigned NOT NULL default '0',
`timestamp` timestamp NOT NULL default '0000-00-00 00:00:00',
`value` smallint(11) unsigned NOT NULL default '0',
PRIMARY KEY (`deviceid`,`logid`,`timestamp`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Deze tabel is er ook voor uint8, uint32, uint64 en de signed types. Aan de key kan je zien dat de data dus per device, per logid wordt binnengehaald. Dit gaat dan over het algemeen om een uur een dag en maximaal eigenlijk een maand. In de query wordt deze data dan gegroepeerd tot maximaal 500 waardes waaruit een grafiek wordt gecreëerd.

Nu ben ik wel benieuwd of het allemaal toch wel mee valt en logisch is dat het soepel draait op de huidige machine of dat je denkt dat het stukken sneller kan met betere hardware?

Misschien dwalen we nu alleen een beetje af van mijn initiële vraag al sta ik open voor andere suggesties, wat zou voor die 2000/3000 euro een betere setup zijn om de core business zoals hierboven omschreven op te laten draaien?

Ik zou een cumalatieve tabel toevoegen met de reeds gegroepeerde waardes. Mysqld performt pas goed als ie zijn indexen in het geheugen kan laden en dat lijkt me met 105GB aan indexen een beetje lastig.
(Een truukje kan zijn om je value veld ook nog in de index te gooien. Dat maakt de index iets groter maar het voordeel is dat mysql niet meer hoeft te lezen uit de datafile omdat alle velden reeds in de index zitten).
Verder kun je de tabel nog partitioneren (op maand/week/whatever) zeker omdat je maximaal 500 waardes gebruikt.

Eigenlijk lijkt het meer op een logtabel en dan zou ik eens kijken of je de index niet helemaal kunt dumpen en eventueel vervangen door een inserttrigger/cronjob die een cumulatieve tabel bijwerkt. Spaart je direct 105 gb aan indexen waardoor alleen de cumulatieve indexen nog ram gebruiken. Dat is sowieso een stuk minder en zal retrievel een stuk sneller maken.

Een iets andere opzet kan je dus al veel performance schelen en problemen in de toekomst als je data 3 keer zoveel is of een storing (Een index nieuw moeten aanmaken van 105GB duurt wel even namelijk).

De truuk van de value ook in de index is inderdaad wel een idee, verder is het eigenlijk een logtabel. Hoe ouder hoe verder bovenaan de data staat, de nieuwe data komt er onder.

Al zou ik me in dat logtabel stuk verder moeten verdiepen.

Je laatste punt heb ik momenteel opgelost. Elk device heeft nu een eigen database in plaats van alle devices in één enkele tabel. Je haalt toch altijd data op van maar 1 device per keer. Dit maakt backuppen ook makkelijker en de data is meer geïsoleerd.

Maar deze dingen zouden misschien nog iets kunnen optimaliseren maar voor de rest denk ik dat het wel soepel draait als je kijkt naar de hardware die we hebben staan.

Mijn vraag was dan ook eigenlijk of je nog suggesties hebt wat betreft de aan te schaffen hardware voor dit soort werkzaamheden in de 2000/3000 euro range?

Zolang je niet megaveel geheugen nodig hebt omdat je geen gekke joins maakt zou je eens kunnen kijken naar 2x480gb ssd's en 2xsata backupdisks (voor mysqldumps of zo), beide in raid 1 en een snelle quadcore.
Als je dan nog budget over hebt -> aanvullen met ram.

Met partitioneren bedoelde ik eigenlijk http://dev.mysql.com/doc/refman/5.1/...ing-types.html maar jouw manier kan net zo goed werken.

Klopt het dat die logtabel MyISAM is? Mogelijk haal je meer snelheid als je werkt met innoDB.

Wellicht een idee om ook een MySQL DBA naar je hele setup te laten kijken, een goede MySQL configuratie kan ook veel schelen. InnoDB e.d. kan mogelijk interessant zijn afhankelijk van de hoeveelheid geheugen/je MySQL configuratie en applicatie. Verder zou ik zeker een hotspare nemen en een disk/cold spare op locatie laten leggen zodat je direct een defecte disk kan vervangen indien deze failed.