'Databaseserver' voor particulier - advies gevraagd

[BertS]

Ik heb een sql-database met ca 15mln records. Die data wordt extern aangeleverd, en zal periodiek 2x per jaar) volledig ververst moeten worden (= leeggooien en opnieuw opbouwen) uit ascii-files. De data wordt wekelijks bijgewerkt (+40.000 recs).

Op deze data wordt een 100-tal formules losgelaten, die behoorlijk wat reken/selectiewerk vragen (bijv. gemiddelde van 15 recs uit die 15mln / gemiddelde van 15 andere recs uit die 15 mln, vergeleken met de max uit 25 recs uit die 15mln. in één formule komen gemiddeld een stuk of drie van dergelijke constructies voor)

Op de resultaten van dat rekenwerk worden vervolgens allerlei queries uitgevoerd, zoals het aantal keer dat bepaalde formules True op hebben geleverd binnen een bepaalde selectie.

Het is nu zo opgebouwd dat de formules worden doorgerekend 'na' het bijwerken van de brongegevens. De resultaten worden in een andere tabel weggeschreven, zodat de query-performance een beetje acceptabel blijft.

Het vullen van de database en het rekenwerk zijn dus batchgewijs opgebouwd. Voor de wekelijkse batch is dat niet zo heel veel, maar voor de halfjaarlijkse is hij behoorlijk zwaar.

Het queryen op de rekenresultaten (tabel met 15mln recs, 100 velden, half 'bit' en half 'float') gebeurd dagelijks met wisselende queries.


Eea wil ik op een aparte machine gaan draaien. Het draait nu bij wijze van test op mn gewone desktop (P-IV, 2.66, 1GB ram), maar ik wil het op een aparte 'server' gaan draaien.

en dan nu de vraag:
Hebben jullie tips voor de aanschaf van hardware waarmee de performance zo optimaal mogelijk is?
(Wat ook financieel nog een beetje interessant blijft, want het is voor 'hobby' )

[Sosabowski]

Welke software ga je draaien en nog belangrijker wat is je butget?

[Icey]

Denk ook aan een backup mogelijkheid. Raid is een optie omdat je er dan zelf weinig omkijken meer aan heb. Maar dan heb je een backup 'in' je systeem, en niet extern... dus als er wat gebeurd ben je alsnog de sjaak...

[BertS]

IorGie schreef op vrijdag 24 december 2004 @ 16:50:
Welke software ga je draaien en nog belangrijker wat is je butget?

Het gaat draaien op MSDE 2000 (evt later overstappen naar v 2005), met een Access/VB6-frontend.
Budget is max € 1.500,-

[Croga]

Icey schreef op vrijdag 24 december 2004 @ 16:53:
Denk ook aan een backup mogelijkheid. Raid is een optie omdat je er dan zelf weinig omkijken meer aan heb. Maar dan heb je een backup 'in' je systeem, en niet extern... dus als er wat gebeurd ben je alsnog de sjaak...

Bij een systeem wat twee keer per jaar volledig gerefreshed wordt en waarvan je de wekelijkse updates kunt bewaren is een backup eigenlijk nauwelijks van belang. Als je een crash krijgt bouw je de database opnieuw op van de laatste volledige refresh en zet vervolgens de wekelijkse updates terug. Als ik het geheel zo lees worden er geen updates door de gebruiker gedaan....

[BertS]

Croga schreef op maandag 27 december 2004 @ 07:24:
[...]


Bij een systeem wat twee keer per jaar volledig gerefreshed wordt en waarvan je de wekelijkse updates kunt bewaren is een backup eigenlijk nauwelijks van belang. Als je een crash krijgt bouw je de database opnieuw op van de laatste volledige refresh en zet vervolgens de wekelijkse updates terug. Als ik het geheel zo lees worden er geen updates door de gebruiker gedaan....

Inderdaad, backup is niet echt relevant. De wekelijkse update wordt wel door de gebruiker uitgevoerd, maar die worden in de halfjaarlijkse sessie automatisch ook meegenomen.
De data kan op elk willekeurig moment volledig opnieuw gegenereerd worden. (het zit alleen in deze database om er eigen analyses op uit te voeren)

[Rukapul]

Hoe lang duurt het uitvoeren van de wekelijkse batch berekeningen nu en wat is de maximale toegestane tijd? Als dat makkelijk gaat dan boeit de hardware mbt dit punt dus totaal niet.

Hoe vaak voer je queries uit en hoe lang mogen die duren? Hoe groot is de dataset die uit de batch berekening volgt? Als je die heel vaak gebruikt en de resultaten snel moet hebben dan is het voordelig om ze in memory te kunnen houden, maar anders maakt het wederom niet uit (wellicht handig om de indices in geheugen te kunnen houden).

Kortom: kom met wat meer getallen mbt grootte van de verschillende datasets en deadlines.
Zonder meer details voldoet elk degelijk, maar niet te duur systeem, want dan weet je toch niet waar je op moet optimaliseren.

[BertS]

Bedankt voor je concrete vraag naar getallen. Een poging:

Batch
Voor de wekelijkse batch:
Nog niet alle formules zitten erin, maar het komt neer op ca 1 minuut per formule. Is niet direct problematisch, omdat dit een batch is die probleemloos in de nacht kan draaien

In de 'halfjaarlijkse' batch is het een ander verhaal. Dan hebben de formules gemiddeld al snel 4 uur per stuk nodig.
Ook dit is niet het punt waar het meeste in geïnvesteerd moet worden, omdat ik de bestaande dataset dan nog in de lucht kan houden voor het queryen. Wel is het prettig als dit een eindje teruggebracht kan worden.

Queries
Queries worden dagelijks uitgevoerd. Omvang van de onderliggende dataset variëert van ca 75k tot ca 10mln recs.
Hierop wordt een groupby uitgevoerd op 1 veld, waarna ca 2.500 recs overblijven. Op dit veld wordt ook een Sort uitgevoerd.
Op de overige velden wordt meestal een Count of een Sum uitgevoerd. Het aantal velden (velden=formules hier) per resultaatset varieert van 5 tot 20.

Bij deze queries is de performance zéér belangrijk. Er zullen zeer veel verschillende queries ontstaan.
Hierbij is 'execution time' belangrijker (hoe kleiner hoe beter) dan het evt in memory houden. Gezien de diversiteit aan queries zal het laatste nl bijna onmogelijk zijn. En als blijkt dat bepaalde (statische) queries wel erg frequent worden uitgevoerd, kan ik die resultaten evt nog in aparte tabellen wegschrijven en in de batches bijwerken.

Samenvattend
- Wekelijkse batch niet echt relevant
- Voor de halfjaarlijkse batch is het prettig als het rekenwerk wat sneller kan (nu 100 formules x ca 4 uur...)
- Belangrijkste is de execution-time van queries.

[IJnte]

Over het algemeen zijn de AMD Opteron Processoren sneller in Database Rekenwerk. Is je budget alleen beschikbaar voor Hardware, of ook voor software:?

[Verwijderd]

Mag ik vragen waar je prive zo'n enorme database voor nodig bent. Een gemiddeld adresboekje beslaat geen miljoenen records.

[BertS]

IJnte schreef op maandag 27 december 2004 @ 11:55:
Is je budget alleen beschikbaar voor Hardware, of ook voor software:?

In principe voor beide.

[BertS]

Verwijderd schreef op maandag 27 december 2004 @ 11:56:
Mag ik vragen waar je prive zo'n enorme database voor nodig bent. Een gemiddeld adresboekje beslaat geen miljoenen records.

Jij wilt niet weten hoeveel vrienden ik heb

Maar in dit geval gaat het om aandelen (7250 fondsen * 10 jaar * 250dgn)
De halfjaarlijkse refresh is ivm opheffen/samenvoegen/splitsen e.d. van fondsen.

[IJnte]

Zoek voor de gein es naar Benchmarks van een Opteron processor op Tom's Hardware en op 2Cpu.com

[IJnte]

bee-es schreef op maandag 27 december 2004 @ 12:00:
[...]

Jij wilt niet weten hoeveel vrienden ik heb

Maar in dit geval gaat het om aandelen (7250 fondsen * 10 jaar * 250dgn)
De halfjaarlijkse refresh is ivm opheffen/samenvoegen/splitsen e.d. van fondsen.

offtopic:
Wat hou je dan allemaal bij?? Heb je grafieken e.d. nodig om te kunnen daytraden:?

[MrBarBarian]

Ehm, ben je je 1.500,-- euro niet al kwijt als je alleen al de Licentiekosten hebt betaald (wilde gok hoor!)?

[BertS]

IJnte schreef op maandag 27 december 2004 @ 12:02:
[...]

offtopic:
Wat hou je dan allemaal bij?? Heb je grafieken e.d. nodig om te kunnen daytraden:?

offtopic:
't is niet voor mijn hobby. Ik doe de database+applicatie. de logica/ het doel is niet voor mij
Maar het gaat om het signaleren van gedragingen, trends e.d.. idd dmv grafieken.

[BertS]

MrBarBarian schreef op maandag 27 december 2004 @ 12:07:
Ehm, ben je je 1.500,-- euro niet al kwijt als je alleen al de Licentiekosten hebt betaald (wilde gok hoor!)?

Welke licentiekosten?
Het draait nu op MSDE, en dat gaat prima hoor, gratis
de enige relevante beperking is een max omvang van 2Gb per database, maar dat is geen probleem.
De enige software(licentie) die er volgens mij op moet is een OS

[lier]

MrBarBarian schreef op maandag 27 december 2004 @ 12:07:
Ehm, ben je je 1.500,-- euro niet al kwijt als je alleen al de Licentiekosten hebt betaald (wilde gok hoor!)?

HW icm SBS2003 vanaf 1000 euro... (bv Dell) ?

mmmm, net te laat

[ Voor 4% gewijzigd door lier op 27-12-2004 12:28 ]

[BertS]

IJnte schreef op maandag 27 december 2004 @ 12:01:
Zoek voor de gein es naar Benchmarks van een Opteron processor op Tom's Hardware en op 2Cpu.com

Ik heb die test op Tom's Hardware bekeken. Bij de database (select) is de Opteron idd beduidend sneller, maar op de volgende pagina (memory transfer) scoort de intel weer beter.
Nu de vraag: wat is belangrijker?

[IJnte]

Insert en Select zijn sneller met een Opteron dan elke andere processor. Memory transfer is vooral belangrijk als je veel bestanden kopieerd,schrijft, leest e.d. Vooral met Games en Renderen (dus 3D werk) is dat een doorslaggevende factor.. Zo denk ik er iig over.
Zoek ook even op wat nieuwere benchmarks. Op het forum van 2CPU.com vindt je ook erg veel info. Gebruik daar de search eens, en kijk wat je daar aantreft.

[BertS]

IJnte schreef op maandag 27 december 2004 @ 12:32:
Insert en Select zijn sneller met een Opteron dan elke andere processor. Memory transfer is vooral belangrijk als je veel bestanden kopieerd,schrijft, leest e.d. Vooral met Games en Renderen (dus 3D werk) is dat een doorslaggevende factor.. Zo denk ik er iig over.

Kijk, dat soort info zoek ik!
Ik kan me nl indenken dat Memory transfer ook best relevant is voor de resultaatset?
(als ik een query uitvoer zie ik het geheugengebruik behoorlijk oplopen onder taakbeheer, terwijl de processor niet zo heel erg druk is)

*is druk bezig met het bestuderen van reviews*

[janvk]

Ik denk dat inderdaad backup via tapes niet belangrijk zijn maar dat bijvoorbeeld een raid systeem wel veel tijd kan schelen. Het opnieuw ophalen van de data kan dagen tijd in nemen.

Dus wat is je verdienste op het moment dat je geld spendeert aan de extra schijf en raidcontroller ten op zichte van je verlies op het moment dat je uit de lucht bent door een hard disk crash.

[IJnte]

janvk schreef op maandag 27 december 2004 @ 12:52:
Ik denk dat inderdaad backup via tapes niet belangrijk zijn maar dat bijvoorbeeld een raid systeem wel veel tijd kan schelen. Het opnieuw ophalen van de data kan dagen tijd in nemen.

Dus wat is je verdienste op het moment dat je geld spendeert aan de extra schijf en raidcontroller ten op zichte van je verlies op het moment dat je uit de lucht bent door een hard disk crash.

Verkeerde topic

[BertS]

Op zich is het natuurlijk niet verkeerd om ook aan de backup te denken, maar het eerste is voor mij de optimale performance.

[lier]

Je vroeg om tips....

1) Geheugen (en een boel...)
2) Snelle disken minimaal SATA, maar liever SCSI
3) Processor met lekker veel cache

[BertS]

lier schreef op maandag 27 december 2004 @ 13:46:
Je vroeg om tips....

1) Geheugen (en een boel...)
2) Snelle disken minimaal SATA, maar liever SCSI
3) Processor met lekker veel cache

ik vroeg om tips ja
Dat de drie punten die je noemt van belang zijn lijkt me redelijk duidelijk. Waar het mij nog even gaat is:
1. De volgorde van belangrijkheid van die drie dingen (waar kan ik het beste mn geld aan besteden)
2. Welk geheugen is hiervoor het beste geschikt? (ik denk aan 2 of 4 Gb dual channel 400MHz ofzo?)
3. Welke processor is hiervoor het beste geschikt?

[Rukapul]

Een processor (in de zin van pure rekenkracht) zal hooguit een paar procent schelen (voor een hele grote cache zie ik bv geen noodzaak aangezien die met name voor code voordeel heeft niet voor data die eenmalig gebruikt wordt). De grootste vertragende factor zal waarschijnlijk het lezen van de enorme hoeveelheid data zijn die telkens bewerkt moet worden (uit geheugen of van disk). Ik heb even op het Internet gezocht maar daar wordt geclaimd dat MSDE zowat MSSQL server is en ik mag dus aannemen dat die goed geoptimaliseerd is om van je hardware gebruik te maken. Ik kan me dus voorstellen dat het in het geheugen kunnen houden van de gehele dataset (nodig voor een bepaalde query) erg voordelig kan zijn en dan ook nog wat geheugen vrij hebben voor de (tussen)resultaten (sorteren kan een erg dure operatie zijn bv). Genoeg en snel geheugen is dus wellicht handiger dan een ultrasnelle RAID opstelling voor de normale queries hoewel die wel weer van belang kan zijn wanneer de database (snel) gevuld moet worden (ik neem even aan dat een database server zo snel mogelijk data persistent wil opslaan, maar daar is vast een setting voor).

Bovenstaande is slechts een idee op basis van het toepassen van wat heuristieken. Veel zal echter afhangen van de grootte in MBs van je datasets en de gebruikte databasesoftware. De kans dat je ergens ineens een grote besparing haalt door een query te optimaliseren of een setting van de server aan te passen acht ik vrij groot.

[BertS]

Ik heb inderdaad ook niet de indruk dat de processor de meest belangrijke component is. Maar toch schijnt dat wel behoorlijk uit te maken, gezien de vergelijking op Tom's hardware die eerder genoemd werd.
MSDE==SQL Server. Het is exact dezelfde engine, alleen gaat is die wat aangepast zodat die een maximaal aantal connecties (gebruikers) tegelijk aankan (bij >5 concurrent users rekening houden met slechtere performance), maar dat is hier niet aan de orde. Verder is de max. grootte van een database beperkt tot 2Gb.

Het performen van de queries scheelt inderdaad ontzettend veel (exec.time terugbrengen van ca 12 min. naar 2 min ), maar heeft z'n grenzen.

Op basis van de dingen die genoemd zal het dus in deze volgorde komen:
1. geheugen
2. HDD
3. Processor.

Ik denk zelf aan zoiets:
1. DDR2 DRAM / 1GB x 2 (2GB) PC4200 DDR2, CL4 (Kingston KVR533D2N4K2/2G)
pricewatch: 1GB x 2 (2GB) PC4200 DDR2, CL4 (Kingston KVR533D2N4K2/2G)

2. SCSI harde schijven / Maxtor Atlas 15K, 18,4GB (15.000rpm, Ultra320, SCA, 8MB)
pricewatch: Maxtor Atlas 15K, 18,4GB (15.000rpm, Ultra320, SCA, 8MB)

3. AMD Opteron Processors / AMD Opteron 146 (S940, 2,0GHz, 1MB)
pricewatch: AMD Opteron 146 (S940, 2,0GHz, 1MB)

[ Voor 12% gewijzigd door BertS op 27-12-2004 23:18 ]

[Croga]

bee-es schreef op maandag 27 december 2004 @ 23:15:Ik denk zelf aan zoiets:
1. DDR2 DRAM / 1GB x 2 (2GB) PC4200 DDR2, CL4 (Kingston KVR533D2N4K2/2G)
pricewatch: 1GB x 2 (2GB) PC4200 DDR2, CL4 (Kingston KVR533D2N4K2/2G)

3. AMD Opteron Processors / AMD Opteron 146 (S940, 2,0GHz, 1MB)
pricewatch: AMD Opteron 146 (S940, 2,0GHz, 1MB)

Jammer alleen dat er nog geen Opterons zijn met DDR2 ondersteuning.... Je zult dus standaard PC3200 geheugen moeten nemen voor die Opteron.

[wboevink]

bee-es schreef op maandag 27 december 2004 @ 06:46:
[...]

Het gaat draaien op MSDE 2000 (evt later overstappen naar v 2005), met een Access/VB6-frontend.
Budget is max € 1.500,-

Hoeveel clients draaien erop. De msde versie heeft een beperking op het aantal concurrent connections.

Veel geheugen is belangrijk, en een snelle harde schijf configuratie liefst raid 5 of striping. Verder zijn er tal van documenten te lezen op www.microsoft.com/sqlserver

[0siris]

nog meer vragen: waar gaat die machine staan? Want net als de post hierboven kan ik _veel_ geheugen alsmede een RAID configuratie van een paar 15000 rpm SCSI schijven van harte aanbevelen, maar dat maakt best wel kabaal voor in de huiskamer
Met zelfbouw moet je een heel eind kunnen komen voor 1500 euro.

[BertS]

Croga schreef op dinsdag 28 december 2004 @ 08:56:
[...]

Jammer alleen dat er nog geen Opterons zijn met DDR2 ondersteuning.... Je zult dus standaard PC3200 geheugen moeten nemen voor die Opteron.

Hmm, ok...
Maar wat is dan 'beter'? Kiezen voor ander geheugen, of kiezen voor een andere processor?

[FragDaddy]

Ik denk dat inderdaad backup via tapes niet belangrijk zijn maar dat bijvoorbeeld een raid systeem wel veel tijd kan schelen. Het opnieuw ophalen van de data kan dagen tijd in nemen.

RAID != backup

bij een raidarray bescherm je jezelf hoogstens tegen uitvallen van hardware. Bij een offsite backup bescherm je jezelf ook nog tegen gebruikersfouten, diefstal, brand, etc. etc. etc.

[BertS]

wboevink schreef op dinsdag 28 december 2004 @ 09:02:
[...]


Hoeveel clients draaien erop. De msde versie heeft een beperking op het aantal concurrent connections.

Veel geheugen is belangrijk, en een snelle harde schijf configuratie liefst raid 5 of striping. Verder zijn er tal van documenten te lezen op www.microsoft.com/sqlserver

1 client, dus geen probleem voor msde