Bekijk Volledige Versie : snelle database server
Hai,
Wat is handige hardware (workstation) voor een database?
Het gaat om een grote database (enkele tabellen met meer dan 1 miljard records, in totaal 30-50 gb aan data), waar in sommige gevallen ook nog eens complexe queries op gedraaid moeten worden.
Er zullen niet veel mensen tegelijkertijd op werken (1-3 mensen).
- heeft het zin om meer processors in te zetten
- moeten het vooral snellere processors zijn
- gaat het om geheugen
- (de data staat sowieso op snelle ssd's)
Graag jullie advies.
Hangt nogal af van de type DB/index/query/job.
Over het algemeen is disk + memory de key, CPU komt daarna pas.
Okey...
Maar aan welke specificaties moet ik denken? Sommige queries duren nu enkele uren. Hoe kan dit versneld worden?
(p.s. nu werken we vooral met oracle, in de toekomst zal dat veranderen)
- Indexen (juist minder of juist meer)
- TempDB naar losse SSD
- Eigen temp tabellen maken via job, met alleen de data die je nodig hebt, en daar je query op draaien
- enz :)
Hardware specs waag ik me niet aan zonder meer kennis van data, doel enz.
Gokje -> BI ?
asusk7m550
10/10/13, 19:47
Kijk ook eens goed naar je queries. Ik heb wel eens meegemaakt dat als je een queries splitst in twee losse, het geheel en stuk sneller wordt.
Maar kort door de bocht zeg ik, snelle schijven en goede index.
systemdeveloper
10/10/13, 20:55
Altijd eerst naar je database ontwerp kijken. Het heeft totaal geen zin om dingen te roepen als meer van dit of minder van dat als je niet precies weet hoe het datamodel in elkaar zit en wat de toegangspaden zijn.
Heel globaal kun je zeggen dat elke db beter af is met meer power en meer ram, maar daar houdt het wel een beetje op.
Wat systemdeveloper en Bart L zeggen, zou ook als je niks aan je structuur kunt aanpassen kijken naar je TempDB niet op SSDs te cachen maar in je RAM, kwestie van genoeg RAM (128GB) en daar een ramdisk van maken. Daarna kijken naar optimalisatie van je queries en je DB structuur.
Hai,
Wat is handige hardware (workstation) voor een database?
Het gaat om een grote database (enkele tabellen met meer dan 1 miljard records, in totaal 30-50 gb aan data), waar in sommige gevallen ook nog eens complexe queries op gedraaid moeten worden.
Er zullen niet veel mensen tegelijkertijd op werken (1-3 mensen).
- heeft het zin om meer processors in te zetten
- moeten het vooral snellere processors zijn
- gaat het om geheugen
- (de data staat sowieso op snelle ssd's)
Graag jullie advies.
In volgorde :
1 - DBA Die Het Echt Snapt
en daarna
2 - RAM
3 - de rest (w.o. snelle disken, maar die had je al) .
Ik zou niet veel verwachten van een groot aantal CPUs. Misschien dat CPUs met een grote L1/L2/L3 cache nog wat meerwaarde hebben, meer iig dan een hoge kloksnelheid of hogere floating point performance bv.
Maar de beste kans op performance haal je toch uit een goed passend datamodel, en iemand die queries analyseert en optimaliseert.
Je hebt dan iemand nodig die theorie en praktijk ook van die specifieke database kent, op hoog niveau snapt waar de query voor dient, (en dus de query kan herschrijven, indien nodig) en met de aanwezige tools (performance analysers) kan zien wat de database maakt van de query .
Database engines doen hun best om queries zo snel mogelijk te doen, maar net als bij compilers kan een echt goede dba ze een handje helpen.
systemdeveloper
11/10/13, 00:53
Mijn ervaring is dat je met grote databases (1 miljard records is wel aardig) altijd tegen dingen gaat aanlopen, ook al doe je alles netjes via het boekje. De truuk is dan meestal om een beetje out-of-the-box te denken en simpelweg veel ervaring te hebben. Er zijn mensen die al 10 jaar met databases werken, maar ook nooit een serieus probleem zijn tegengekomen dat niet met 5 minuten googlen opgelost kon worden.
Een adhoc-query die uren duurt is per definitie fout. Niemand kan namelijk informatie uit dat soort hoeveelheden halen. Over het algemeen heb je hier tabellen boven zitten die gedurende de dag met triggers, stored procedures e.d. zorgen voor een ingedikte tabel met de gevraagde informatie. Stel je hebt een tabel 'hits' met een record voor elke webhit, dan knal je daar een trigger/sp/cronjob bij die bv. een tabel vult 'hits-per-dag/uur/minuut/site/whatever' die je vervolgens gebruikt in je adhoc queries.
Kun je dit soort truukjes niet doen en moet je echt elke keer een grote hoeveelheid data verwerken, dan moet je dat opslitsen in meerdere concurrent processen die je eventueel lokaal over een aantal cores of misschien zelfs over meerdere servers verdeelt.
Maar.... laat er gewoon eens iemand een tijdje naar kijken. Kan je een paar euro kosten want een dba is gewoon niet goedkoop. (Is ie dat wel, dan is het geen goede dba want we kennen die prijzen echt wel), maar het kan je veel geld schelen in de oplossing en hij kan meedenken richting toekomst, voor het geval dat je volgend jaar wellicht 2-5 miljard records hebt.