Snelle database storage gezocht

[Verwijderd]

Ik zoek een geschikte database storage,
Hij moet echt razendsnel zijn, ik dacht eerst aan flash vanwege de lage accestime, maar ik denk niet dat accestime het probleem is.
Het betreft 1 bestand van iets meer dan 1gb, het is een klantenbestand.
Dmv pasjes loggen de klanten in, maar na het groeien van het database bestand, duurt het soms wel 5 seconde voordat er de gegevens op het display zichtbaar zijn. En dit is cruciaal voor het aanspreken van de klanten als er een mededeling is.

Nu is het systeem 1.6ghz met 384mb ram en een 20gb 5400rpm hd.
1.6ghz lijkt mij meer dan voldoende voor dit soort zaken, ook omdat het systeem met weinig klanten wel snel werkte, het systeem bevat nu zo'n 10 000 klanten met hun gegevens.
Ik schat dat de storage te traag is. in de task manager is er ook een blijvende piek in de cpu time. maar in de fysieke toegang
Wat is jullie mening hierover?
Wat kan ik het beste aanschaffen? Een raptor? of een hele grote 7200rpm hd met een grote datadichtheid (dat is toch ook sneller?)

[kwiebus]

Mijn mening hierover is dat je een best wel vaag en onsamenhangend verhaal ophangt.

[Paul]

Ik denk dat er eerder een probleem in je software hebt

Wiens software is het en kun je die aanpassen? Ga eerst alle query's eens door een analyzer gooien om te kijken _wat_ er nu precies zo lang duurt

[Zsub]

Je hebt inderdaad een re-de-lijk vaag verhaal, maar in ieder geval. Koopt. Meer. Ram.

Easy as that. Zet er 2 gig in en zorg ervoor dat die db er volledig in past en staat. Probeer het dan nog eens Als er dan geen verbetering is gaat je CPU de bottleneck zijn.

[Erkens]

Zsub schreef op woensdag 19 december 2007 @ 23:32:
Als er dan geen verbetering is gaat je CPU de bottleneck zijn.

Zo'n systeem moet met gemak 10.000 users kunnen afhandelen. Ik denk eerder dat het probleem in het database model/queries zit. Maar, meten is weten, dus meet eerst eens hoe vaak de CPU zit te wachten op I/O.

[kmf]

lijkt mij meer dat ie een platte bestand heeft dat elke keer ingeladen moet worden.

maar ja, zonder enige vorm van info kan niemand hier natuurlijk wat mee dan dit antwoorden:

Neem een 4x quadcore server met 100 raptors in raid0 opstelling en 32GB RAM. That should do it.

[Frankie02]

Meer geheugen en een 7200 rpm harddisk, dat zou al een behoorlijke verbetering zijn.

Maar over welk OS praten we eigenlijk? En hoe worden de pasjes aangeboden (via een netwerkapparaat naar de pc of via een seriele verbinding)?

[Femme]

Je bestand is slechts 1GB dus dan zou ik zeggen koop een systeem met 2-3GB RAM zodat al die data met gemak in geheugen gecached kan worden en zorg verder voor een degelijke en snelle opslag, bijvoorbeeld twee Raptor's op een Areca ARC-1200 in raid 1. Het wegschrijven van de data zal dan ook geen vertraging meer oplopen.

[Verwijderd]

Idd als je genoeg geheugen hebt zorgt de filecache van je OS (windows, linux, freebsd doen dat allemaal) er automatisch voor dat je tegen geheugensnelheid toegang tot die bestanden hebt. Misschien is de performance al genoeg als je er gewoon een sloot geheugen in gooit, 2GB is een leuke hoeveelheid. Desnoods maak je die file aan op een memory disk, als de file cache toch niet goed lijkt te werken (lees het hele bestand in en kijk naar de snelheid en vooral de dallen hierin).

Voordeel van geheugen is dat de accesstime vergeleken met hardeschijven astronomisch laag liggen, en dat betekent dus zeer hoge IOps performance.

[Paul]

Ik snap dat het topic in OM staat, maar waarom concentreert iedereen zich op de hardware, terwijl we het over een databeestje van een miezerige 10k records hebben?

"Met weinig klanten wel snel" en maar 10k records klinkt als een typisch softwareprobleem. Een loopje dat alle records lineair afgaat in de zoekroutine of zo, of een verkeerde (of geen) index op de zoekvelden...

Goed, er staat geen info over de concurrent users, maar de huidige hardware moet dit _makkelijk_ afkunnen.

[DrClaw]

houd een index in het geheugen, voor elk van die 10000 klanten. elke index wijst naar de complete record in de file (de offset vanaf het begin van de file dus). Dit hoef je maar 1x te berekenen, bij opstarten (of je slaat het daarna meteen op, dan hoef je het alleen maar in te lezen), en bij elke query met de pasjes hoef je alleen maar een fseek met de offset uit het geheugen te doen.

kosten: halfuurtje programmeren.

[Verwijderd]

Het gene wat ik met een snapp in heb gezien tot nu toe is dat de
I/O toegang de gehele 5 seconde op 100% staat. en de cpu nauwelijks gebruikt wordt. Dus vandaar dat ik me afvroeg wat ik als beste als storage kon gebruiken.

Alshet nu vele kleine bestandjes waren geweest dan had ik snelle accestime nodig gehad, maar omdat het hier om 1 groot opslagbestand betreft denk ik dat ik beter een zo snel mogelijke doorvoersnelheid nodig heb.
Dus dat een een hardeschijf met een hoge doorvoersnelheid meer zin heeft dan het gebruik van een flash drive of iets dergelijks. Of maak ik hier een denkfoutje?

In de database kan ik helaas niks veranderen, hier heb ik geen rechten toe.
Met welke tool kan ik meten wat het programma doet, en de leverancier hierop wijzen?


-> Soms staat de klant meteen in beeld, en soms duurt het 5 seconden na het scannen van het pasje. Ik denk ook dat de database gewoonweg verkeerd is opgebouwd, maar omdat ik hier niks aan kan doen zoek ik dus voor een hardwarematige oplossing om het probleem te verminderen

[disjfa]

Verwijderd schreef op donderdag 20 december 2007 @ 10:25:
Het gene wat ik met een snapp in heb gezien tot nu toe is dat de
I/O toegang de gehele 5 seconde op 100% staat. en de cpu nauwelijks gebruikt wordt. Dus vandaar dat ik me afvroeg wat ik als beste als storage kon gebruiken.

Nog steeds, is het dan niet slimmer te onderzoeken waarom het 5 seconden duurt ipv gewoon wat anders te gaan zoeken Een ander systeem lost echt niet ineens andere problemen op.

[LiquidT_NL]

software probleem. 10k users stelt geen klap voor. Je databaseconstructie is waarschijnlijk niet goed genoeg.

Zoals DrClaw zegt: Klanten gewoon indexeren en het zal al flink wat vlotter moeten lopen.

[Erkens]

disjfa schreef op donderdag 20 december 2007 @ 10:27:
Nog steeds, is het dan niet slimmer te onderzoeken waarom het 5 seconden duurt ipv gewoon wat anders te gaan zoeken Een ander systeem lost echt niet ineens andere problemen op.

Precies, je kan wel hardware blijven kopen dan, want op gegeven moment heb je hetzelfde probleem weer.

[sig69]

Verwijderd schreef op donderdag 20 december 2007 @ 10:25:
omdat het hier om 1 groot opslagbestand betreft

Kan ik hieruit afleiden dat het helemaal niet om een database gaat?

[Verwijderd]

Als er niet actieve klanten gewist worden, dan wordt het systeem weer sneller, maar dat is natuurlijk geen goede oplossing aangezien deze gegevens ook graag bewaard willen blijven

[Tjark]

wat is het voor een database? Een zelf/custom geprogrammeerd iets? Blijkbaar wel zonder caching ofzo... lijkt me niet dat je een standaard SQL oplossing gebruikt of wel? (aangezien die echt wel sneller zouden zijn!)

Als dat zo is (custom/bagger progsel) dan is een simple fix _als_'t_echt_om_de_storage_snelheid zou gaan: een ramdrive opzetten van 1-1,5GB. Daarop de file gooien. Sneller kan niet.

[ Voor 30% gewijzigd door Tjark op 20-12-2007 12:49 ]

[AtleX]

Geef eerst eens wat meer informatie over de gebruikte database software, en de opbouw van je database. Misschien kan je met wat eenvoudige tweaks als indexen plaatsen de load al gigantisch terugbrengen.

[Acid__Burn]

Verwijderd schreef op donderdag 20 december 2007 @ 12:43:
Als er niet actieve klanten gewist worden, dan wordt het systeem weer sneller, maar dat is natuurlijk geen goede oplossing aangezien deze gegevens ook graag bewaard willen blijven

Idd. En als dat niet mag, zet het dan in een andere database / op een andere server.

Maar ik zou ook eens kijken naar je model. Misschien is daar nog wat winst te halen. En gebruik indexes. Goede indexes wel te verstaan.

Bij het opvragen van een klant kan je ook in je query zetten dat hij een specifieke index moet gebruiken om de gegevens op te halen. Dat zal ook wel een hoop schelen.

Maar onthoud: het heeft geen in om te tunen / tweaken als je model niet goed is. Dus begin bij het begin, en ga van model naar keys en indexes, en ga daarna je query's bekijken en tunen.

[Edit]:
Er vanuit gaande dat je MS SQL gebruikt...

[ Voor 3% gewijzigd door Acid__Burn op 20-12-2007 12:57 ]

[Janoz]

Waarom beginnen mensen hier over SQL en database servers??

Dit voorbeeldje ruikt aan alle kanten naar een flatfile oplossing waarbij gewoon elke keer lineair het hele bestand doorzocht wordt. Aan alle kanten roept dit om een fatsoenlijke herimplementatie van de software, maar zoals de topicstarter aangeeft kan dit niet.

Wat je zou kunnen doen is in de machine meer ram zetten en vervolgens een ramdisk aanmaken waarin het bestand past. Dat zal er iig voor zorgen dat de boel een stuk sneller loopt. Vervolgens moet alleen nog even geborgd worden dat er regelmatig gesynchroniseerd wordt met een bestand dat wel op een schijf staat zodat eventuele data niet verloren gaat wanneer de computer uitvalt/gaat.

Enkel ram bijplaatsen geef tgeen enkele garantie dat het wel gaat werken want met een dergelijke implementatie van de 'database' hoef je al helemaal niet te verwachten dat ze wat doen met extra geheugen.

[ Voor 12% gewijzigd door Janoz op 20-12-2007 13:09 ]

[LiquidT_NL]

Of de TS had even aangegeven wat de structuur was, maar dat is achteraf Het zal dan inderdaad een flatfile zijn. Kan je dan niet vanuit de flatfile eens in de zoveel tijd (tijdens rustige uren) indexeren naar een niet-flatfile oplossing, dus gewoon een geïndexeerde database?

[ThunderNet]

Janoz schreef op donderdag 20 december 2007 @ 13:07:
Waarom beginnen mensen hier over SQL en database servers??

Omdat er in de topic title staat van snelle database storage.. en niet snelle storage

[Standeman]

Ik zit me echt af te vragen wel dbms het is...

[Verwijderd]

Ik kom straks weer opde locatie met het probleem.

Hoe kan ik de database structuur zien, of het een flatfile oplossing is of een oplossing met een index etc?

[ThunderNet]

Verwijderd schreef op donderdag 20 december 2007 @ 13:56:
Ik kom straks weer opde locatie met het probleem.

Hoe kan ik de database structuur zien, of het een flatfile oplossing is of een oplossing met een index etc?

met de bijbehorende managementtool

[sig69]

Verwijderd schreef op donderdag 20 december 2007 @ 13:56:
Ik kom straks weer opde locatie met het probleem.

Hoe kan ik de database structuur zien, of het een flatfile oplossing is of een oplossing met een index etc?

Vraag het aan de ontwikkelaar / beheerder van het gedrocht?

[Paul]

Zo te horen _kun_ je het niet eens veranderen en moet alles via die leverancier. Die zou ik dus eens aan zijn jasje gaan trekken dat het zo niet werkzaam is...

Als er echt niets aan het programma kan of gaan veranderen, en het duidelijk de harde schijf is die de boel tegenhoudt zou je inderdaad de data op een ramschijf kunnen zetten. Moet je alleen wel regelmatig een backup maken, server op een UPS etc, want een ramdrive is niet echt persistent.

[LiquidT_NL]

Als het extern is uitbesteed klagen bij de leverancier, en vragen of er geen oplossingen zijn.

[Janoz]

ThunderNet schreef op donderdag 20 december 2007 @ 13:33:
Omdat er in de topic title staat van snelle database storage.. en niet snelle storage

Diagnose stelling is het begin van het probleem en de kunst is om uit een probleem omschrijving de juiste items te destilleren. Als iemand je belt met de mededeling dat 'internet niet werkt' en vervolgens een probleem omschrijving geeft die erg doet denken aan een niet werkende DNS, dan ga je de DNS instellingen checken en niet bellen met de AIX of ze de stekker er weer in willen doen toch?

[ThunderNet]

Janoz schreef op donderdag 20 december 2007 @ 15:28:
[...]

Diagnose stelling is het begin van het probleem en de kunst is om uit een probleem omschrijving de juiste items te destilleren. Als iemand je belt met de mededeling dat 'internet niet werkt' en vervolgens een probleem omschrijving geeft die erg doet denken aan een niet werkende DNS, dan ga je de DNS instellingen checken en niet bellen met de AIX of ze de stekker er weer in willen doen toch?

Je hebt absoluut gelijk, maar daarom is het nog niet vreemd waarom mensen het steeds over database oplossingen hebben.

[Johny58]

Heb goede ervaringen gehoord over Oracle TimesTen. Het is volgens mij een soort volledig in-memory database server. Heb er nooit mee gewerkt, weet er heel weinig over behalve dat het razend snel schijnt te zijn.
Heb weleens iets gehoord over een case waar real time vele GigaBytes per seconde een database in moesten (volgens mij had iets te maken met ruimtevaart).

[LiquidT_NL]

Janoz schreef op donderdag 20 december 2007 @ 15:28:
[...]

Diagnose stelling is het begin van het probleem en de kunst is om uit een probleem omschrijving de juiste items te destilleren. Als iemand je belt met de mededeling dat 'internet niet werkt' en vervolgens een probleem omschrijving geeft die erg doet denken aan een niet werkende DNS, dan ga je de DNS instellingen checken en niet bellen met de AIX of ze de stekker er weer in willen doen toch?

heb je gelijk in. Maar mij lijkt het dat de TS dit in professioneel verband doet, dus voor een bedrijf of iets dergelijks. Dan mag je toch wel verwachten dat iemand weet waar hij mij bezig is, en ten minste bekend is met de termen?

Maar niet dus
@TS: is niet beledigend bedoeld ofzo, ik wil ook niet suggeren dat je geen postrecht hebt ofzo, maar een beetje duidelijkheid zou fijn zijn

[asing]

Quick win : defragmenteer de disk eens waar je database op staat. Ik heb hier laatst een server zien omvallen wegens de fragmentatie.

De beheerder zag het, meldde dat het kwart voor 4 's middags was en dat hij al een half uur thuis had moeten zijn.... en hij ging. De volgende morgen was dat doosje dus op zijn bek gegaan.

[Janoz]

Ik blijf er bij dat het oplossen van het probleem in eerste instantie gewoon bij de leverancier van de software/ het pasjessysteem ligt. Komen zij er niet of te laat mee gewoon een ramdisk gebruiken. Cronjob die elke 10 minuten de datafile van de ramdisk naar de HD kopieert. Deze oplossing is een stuk goedkoper dan een nieuwe hardeschijf en geeft gegarandeerd meer snelheidswinst dan de snelste HD die je zo kunt kopen.

[ThunderNet]

Janoz schreef op donderdag 20 december 2007 @ 15:49:
Ik blijf er bij dat het oplossen van het probleem in eerste instantie gewoon bij de leverancier van de software/ het pasjessysteem ligt. Komen zij er niet of te laat mee gewoon een ramdisk gebruiken. Cronjob die elke 10 minuten de datafile van de ramdisk naar de HD kopieert. Deze oplossing is een stuk goedkoper dan een nieuwe hardeschijf en geeft gegarandeerd meer snelheidswinst dan de snelste HD die je zo kunt kopen.

Als het een database is met 10k records, dan lijkt het me echt eerder een design/software fout. En zou ik daar de oplossing zoeken. Als dat geoptimaliseert is, dan zou ik pas naar de hardware verbeteringen kijken. Maar dit is al eerder genoemd in het topic

[LiquidT_NL]

ThunderNet schreef op donderdag 20 december 2007 @ 15:53:
[...]

Als het een database is met 10k records, dan lijkt het me echt eerder een design/software fout. En zou ik daar de oplossing zoeken. Als dat geoptimaliseert is, dan zou ik pas naar de hardware verbeteringen kijken. Maar dit is al eerder genoemd in het topic

Dat zeg Janoz toch ook?

Alleen de TS geeft aan geen aanpassingen in het bestand te kunnen maken, dus redesignen kan (hij) niet (doen). Dus het is door een bepaalde afdeling gedaan, welke dat dan zal moeten doen, of een leverancier, maar als die laatste weigert of er lang over zal gaan doen, dan zul je toch iets moeten oplossen. En dan is een RAMdisk een goede (tijdelijke) oplossing.

[ThunderNet]

Heb over een zin in zijn post overheen gelezen, en zo verkeerd geinterpreteerd mijn excuses

[Verwijderd]

Verwijderd schreef op donderdag 20 december 2007 @ 10:25:
Het gene wat ik met een snapp in heb gezien tot nu toe is dat de
I/O toegang de gehele 5 seconde op 100% staat. en de cpu nauwelijks gebruikt wordt. Dus vandaar dat ik me afvroeg wat ik als beste als storage kon gebruiken.

De CPU wacht op gegevens vanaf de hardeschijf, zonder dat kan het niet sneller werken. Je storage is in jouw voorbeeld dus inderdaad bottleneck.

Máár in jouw situatie is de oplossing niet het vergroten van de I/O performance maar in het effectief cachen van de data, zodat de processor dankzij de véél lagere latency maar heel even hoeft te wachten op de benodigde gegevens. Dat cachen hóórt je database applicatie te doen. Daarvoor heeft het wel eerst voldoende geheugen nodig.

Stel je hebt 2GB dan hoort je database effectief te cachen, of anders de filecache van je Operating System. Ik denk dus dat met geheugenuitbreiding dat je probleem op een goedkope manier opgelost is.

Alshet nu vele kleine bestandjes waren geweest dan had ik snelle accestime nodig gehad, maar omdat het hier om 1 groot opslagbestand betreft denk ik dat ik beter een zo snel mogelijke doorvoersnelheid nodig heb.

RAM biedt zowel zeer hoge IOps als zeer hoge doorvoersnelheid.

In de database kan ik helaas niks veranderen, hier heb ik geen rechten toe.

Aanpassingen aan software zijn kostbaar. Wellicht is het kosten-technisch veel beter om gewoon voor 100 euro RAM in die machine te duwen dan kun je zelfs de slecht opgezette software op jouw machine prima draaien. Daar kan een programmeur misschien anderhalf uur voor werken, maar reken maar dat de factuur hoger zal zijn.

Janoz schreef op donderdag 20 december 2007 @ 13:07:
Enkel ram bijplaatsen geef tgeen enkele garantie dat het wel gaat werken want met een dergelijke implementatie van de 'database' hoef je al helemaal niet te verwachten dat ze wat doen met extra geheugen.

Als na de geheugen-uitbreiding naar 2GB of meer er geen significante performance-verbetering optreedt, en nog steeds veel IO, dan zet je de database gewoon op een memory disk. Daarmee ga je er meerdere honderden procent op vooruit qua IO zodat je hier een flinke bottleneck hebt weggenomen. Ook al is het probleem een slecht opgezette database, soms moet je om kostentechnische redenen voor een simpelere of goedkopere oplossing te kiezen.

[ Voor 6% gewijzigd door Verwijderd op 20-12-2007 23:42 ]

[Janoz]

Verwijderd schreef op donderdag 20 december 2007 @ 23:39:


[...]

Als na de geheugen-uitbreiding naar 2GB of meer er geen significante performance-verbetering optreedt, en nog steeds veel IO, dan zet je de database gewoon op een memory disk. Daarmee ga je er meerdere honderden procent op vooruit qua IO zodat je hier een flinke bottleneck hebt weggenomen. Ook al is het probleem een slecht opgezette database, soms moet je om kostentechnische redenen voor een simpelere of goedkopere oplossing te kiezen.

Lees dan ook even wat ervoor staat:

Wat je zou kunnen doen is in de machine meer ram zetten en vervolgens een ramdisk aanmaken waarin het bestand past. Dat zal er iig voor zorgen dat de boel een stuk sneller loopt. Vervolgens moet alleen nog even geborgd worden dat er regelmatig gesynchroniseerd wordt met een bestand dat wel op een schijf staat zodat eventuele data niet verloren gaat wanneer de computer uitvalt/gaat.

en mocht je dat gemist hebben:

Janoz schreef op donderdag 20 december 2007 @ 15:49:
........Komen zij er niet of te laat mee gewoon een ramdisk gebruiken...........

Ik begrijp dus eigenlijk niet wat je met je opmerking wilt bereiken....

[Verwijderd]

Nouja als het goed is hoef je geen ramdisk te gebruiken, omdat de filesystem cache vanzelf al je RAM opslokt. Dus dan wordt de data vanzelf uit het RAM geserveerd. Maar mocht dat nou om een of andere reden niet goed werken, dán kan hij die ramdisk eens proberen. En ja sorry, je zei het idd al.