Database voor grote datasets, wat is wijsheid?

[voodooless]

We draaien momenteel een Postgresql database voor het opslaan van geografische logpunten en routes van 10K+ object.

Vooralsnog was de werkwijze hier in sequenteel: logpunten erin -> script erover om de zooi te verwerken.

Dat werkt ook prima, tot we nu zover zijn dat het ophalen van de logpunten en het verwerken ervan een dag lang duurt. Dus dingen gaan parallel lopen, en ook gaan we opschalen naar een flink aantal extra gebruikers.

De database met punten is op dit moment grofweg 60GB groot en snel groeiende. Momenteel wordt er binnen Postgresql gewerkt met partitionering, en dat scheelt al een hele berg. Echter gaan we straks flink wat extra load op de database zetten, waarbij veel meer IO gegenereerd zal worden.

Op dit moment is het soms al niet meer werkbaar, zeker als het backup script een dump aan het maken is van de hele database.

Dit moet dus allemaal sneller en beter. Hardware is op zich geen probleem, maar het moet wel zinvol zijn.

De grote vraag is dus: wat is zinvol? In eerste instantie is het van groot belang dat een nieuwe opzet om zal moeten kunnen gaan met flink wat IO. Momenteel is het een server met Raid 10, quad core 1.8 Ghz en 4 GB memory. Dat maakt best wel wat IO, maar voor veel concurrent requests die allemaal op verschillende plekken dingen uit de dataset halen zal het gewoon niet voldoen vrees ik.

Een DB cluster zou misschien oplossing bieden. Ik heb al zitten kijken naar PGpool II en Sequoia. Beiden zien er veelbelovend uit, maar er zitten zeker wel wat haken en ogen aan, zoals bijvoorbeeld een bepaalde custom function die we zelf hebben geschreven voor het indexeren van plaats en straatnamen. Dat soort dingen zullen we dan anders moeten implementeren. Is op zich niet erg, maar dan moet het gebruik van de cluster wel van voordeel zijn voor ons.

Andere mogelijkheid is natuurlijk om een monster van een server neer te zeggen met een berg disks, en een berg memory, waarmee het mogelijk is om veel gelijktijdige IO te doen.

De vraag is bij de laatste mogelijkheid: hoe lang gaat dat goed? Een cluster schaalt natuurlijk veel beter. Server erbij, en je kunt weer vooruit.

Misschien hebben jullie nog ideeën? We hoeven ook niet perse bij Postgresql te blijven, maar dat heeft wel duidelijk de voorkeur. Kom echter niet met iets als Oracle aanzetten, daar hebben we helaas het budget niet voor

[Gomez12]

Verwachten jullie in de nabije toekomst nog zo'n boost van gebruikers, of blijft hierna het aantal gebruikers redelijk gelijk?

Bij redelijk gelijk aantal gebruikers zou ik eerder voor zwaardere server gaan. HW is niet zo duur en het snelst te realiseren.
SW mag je eerst gaan testen, bestaande querys herschrijven etc. etc. Zie ik veel manuren inzitten en altijd hou je de mogelijkheid op bugs, die je naderhand nog eens moet gaan fixen.
Imho is het iets te laat om nu nog SW te gaan testen als je nu al problemen hebt...

Maar ken de opstelling van je db-server niet. Maar als een invoeractie rustig 1 dag mag duren dan gok ik dat 99% van de acties lees-acties zijn, dan kan je ook eens naar een mysql-cluster kijken waarbij je de invoer plaats laat vinden op de hoofd-server, lees-acties vinden alleen plaats op de member-servers. Maarja dit werkt alleen als die invoeractie vertraagd wordt door de read-querys en als 99% van je query's ook read-query's zijn, anders krijg je alsnog een write-queue van hier tot tokio op de hoofd-server omdat deze ook nog de members moet voeden...

[Motrax]

Even los van de keuze van de database en omgeving, dat backup script klinkt niet bepaald geavanceerd.

Is het een volledige dump die 's nachts plaats vind? Mag je db een koude backup hebben in de nacht? Hoe zit het met wijzigingen overdag? Is incrementeel een optie?

Load verlagen rondom de backup kan je heel even wat ademruimte geven.

En in hoeverre is er naar optimalisatie gekeken? Er wordt wel vaak om nieuwe hardware geroepen en zoals je terecht aangeeft, moet deze ook nut hebben, maar vaak zijn performance problemen het resultaat van niet helemaal optimale SP/SQL.

En waar komt je load vandaan? Puur leesacties van gebruikers, of ook mutaties? Kan je de mutaties en het bijwerken van de indexen uitstellen tot 's nachts?

Als het puur om leesacties van de gebruikers gaat, is daar optimalisatie mogelijk, of is dit allang bekend en moet er echt nieuwe hardware bij?

offtopic:
Ik werk alleen maar met Oracle & MS SQL, dus verder hou ik mijn mond

[voodooless]

Gomez12 schreef op dinsdag 24 juni 2008 @ 01:11:
Verwachten jullie in de nabije toekomst nog zo'n boost van gebruikers, of blijft hierna het aantal gebruikers redelijk gelijk?

Nope, er wordt een duidelijke groei verwacht. En zelfs als er geen groei is groeit de dataset nog steeds met enkle gigabytes per maand.

Zie ik veel manuren inzitten en altijd hou je de mogelijkheid op bugs, die je naderhand nog eens moet gaan fixen.
Imho is het iets te laat om nu nog SW te gaan testen als je nu al problemen hebt...

Is niet erg. We gaan het hele systeem omgooien. Vrijwel alle omringende software wordt van 0 af opnieuw opgebouwd.

Maar ken de opstelling van je db-server niet. Maar als een invoeractie rustig 1 dag mag duren dan gok ik dat 99% van de acties lees-acties zijn, dan kan je ook eens naar een mysql-cluster kijken waarbij je de invoer plaats laat vinden op de hoofd-server, lees-acties vinden alleen plaats op de member-servers. Maarja dit werkt alleen als die invoeractie vertraagd wordt door de read-querys en als 99% van je query's ook read-query's zijn, anders krijg je alsnog een write-queue van hier tot tokio op de hoofd-server omdat deze ook nog de members moet voeden...

Daar hebben we niets aan. Zowel invoeren verwerken als lezen gebeurt door elkaar, en gedurende de hele dag door. Het zijn wel relatief simpele queries, ze halen echter nogal veel data op.

Motrax schreef op dinsdag 24 juni 2008 @ 01:20:
Is het een volledige dump die 's nachts plaats vind? Mag je db een koude backup hebben in de nacht? Hoe zit het met wijzigingen overdag? Is incrementeel een optie?

Als Postgres incrementele backups kan doen zou dat mooi zijn, dat is iets om uit te zoeken. Momenteel gebeurt 's nachts veel te veel werk voor een backup, en overdag eigenlijk ook.

In de nieuwe situatie zal er echt de hele dag door activiteit zijn.

En in hoeverre is er naar optimalisatie gekeken? Er wordt wel vaak om nieuwe hardware geroepen en zoals je terecht aangeeft, moet deze ook nut hebben, maar vaak zijn performance problemen het resultaat van niet helemaal optimale SP/SQL.

Daar hebben we natuurlijk al naar gekeken, en gaan we ook zeker nog naar kijken in de nieuwe opzet. Het is eigenlijk zo dat de queries eigenlijk redelijk simpel zijn en in vrijwel alle gevallen direct op indexen werken, probleem is gewoon de grote datasets.

En waar komt je load vandaan? Puur leesacties van gebruikers, of ook mutaties? Kan je de mutaties en het bijwerken van de indexen uitstellen tot 's nachts?

Load komt van alle kanten. Veel dingen zijn simpele lees en schrijfacties, deze dingen kunnen we niet s'nachts doen, want data dient a-la-minuut beschikbaar te zijn. In ieder geval in de nieuwe situatie.

Veel acties hebben slechts betrekking op een relatief klein deel van de dataset, maar andere kunnen zich uitstrekken over de hele breedte.

Duidelijk is nu al te zien dat de server vooral bezig is om van disk te lezen, zelfs bij een simpele select op een id (primary key) tussen twee waardes.

Ga je dan ook nog andere dingen doen loop het helemaal vast en kun je minuten lang wachten op een antwoord.

Verder kan ik nu wel gaan tweaken aan dingen om het weer vlot te trekken, dat is echter geen structurele en goed schalende oplossing. Vroeg of laat loop het weer tegen de rand aan.

[DaCoTa]

Kijk eens naar SSD's. Tenminste, ik heb geen budget gezien, maar als het random reads zijn, kun je daarmee een heel eind verder komen dan een RAID 10.

[ Voor 5% gewijzigd door DaCoTa op 24-06-2008 02:22 ]

[voodooless]

SSD's zijn misschien wel een oplossing. Je zit echter nog steeds met de schaalbaarheid.

Oplossen zou je dat kunnen met een intelligent en schaalbaar filesysteem zoals bijvoorbeeld ZFS. Moet je alleen een server hebben met meer dan voldoende disk plekken.

[EfBe]

Begrijp ik het goed dat je eigenlijk 1 tabel hebt met erg veel rows en dat je daarin veel inserts en leesacties hebt?

Wat doet dat script precies? M.a.w.: trekt dat alle data uit de db naar een client, of houdt dat de data in de db? Leesacties, die vinden plaats op geprocesste data (data geproduceerd door het script) ? Over hoeveel rows praten we? Want 10K is echt geen 'grote dataset' . Een grote dataset is miljoenen rows en een paar miljoen inserts/reads per dag. Het aantal rows is belangrijker dan hoeveel ruimte ze innemen op disk.

Het punt is nl. dat je op een gegeven moment tegen fysieke grenzen aanloopt en je moet terugvallen op clusters, waarin andere regels gelden: lezen en schrijven gebeurt niet meer tegelijk op dezelfde tables, tenzij je een cabinet erneer zet en een cluster ervoor.

Je kunt ook het 'shard' idee toepassen, dat is in feite partitionering, maar op PK range bijvoorbeeld. Wat het in feite inhoudt is dat je zelf de data horizontaal splitst dus, row 1-10000 zitten op bak 1, 10001-20000 op bak 2 etc. Dit werkt wanneer de lees acties niet bv hele tabellen gaan joinen, maar record voor record lezen, zodat je in je code kunt switchen.

[ Voor 10% gewijzigd door EfBe op 24-06-2008 11:29 ]

[matthijsln]

Gebruik je trouwens wel geometry datatypes en spatial queries met PostGIS? Mogelijk dat daarmee je indexen efficienter zijn. Ook kan je misschien meer processing dmv spatial SQL in de db doen wat efficienter is dan alleen de data pullen?

[ACM]

Allereerst: draai je al postgresql 8.3? Zonee, zou ik zeker upgraden, er is aardig wat werk gestoken in betere benutting van het I/O-systeem (o.a. door lagere overhead van records). Helaas vereist dat wel een dump/restore, maar met mijn 90GB-db duurde dat een paar uur.

voodooless schreef op dinsdag 24 juni 2008 @ 00:51:
Vooralsnog was de werkwijze hier in sequenteel: logpunten erin -> script erover om de zooi te verwerken.

Heb je alle (nieuwe) logpunten van alle routes nodig voor je die verwerking kan doen? Zonee, dan kan je natuurlijk vrij triviaal de boel in een queue-achtige oplossing plaatsen en die gewoon met meerdere consumers uitlezen terwijl ie aan de andere kant gevuld wordt. Op die manier kan je triviaal opschalen naar meerdere parallele taken voor het invoeren van de data.

Verder vraag ik me af of je verwerking van dusdanig zware aard is, dat het interessant kan zijn om dat process in meerdere servers te splitsen, waarbij je dus de ruwe data op machine/pool A hebt en de uiteindelijk verwerkte data op machine/pool B hebt. Op die manier kan je B wellicht ook wat gunstiger tunen voor het uiteindelijke werk, bijvoorbeeld door de records veel kleiner te maken.

De grote vraag is dus: wat is zinvol? In eerste instantie is het van groot belang dat een nieuwe opzet om zal moeten kunnen gaan met flink wat IO. Momenteel is het een server met Raid 10, quad core 1.8 Ghz en 4 GB memory. Dat maakt best wel wat IO, maar voor veel concurrent requests die allemaal op verschillende plekken dingen uit de dataset halen zal het gewoon niet voldoen vrees ik.

Ik vind 4GB wel heel erg weinig geheugen voor een moderne database... Gezien de kosten ervan zou ik niet eens minder dan 16GB overwegen. Je weet natuurlijk wel dat de hoeveelheid geheugen de belangrijkste factor is voor de performance van de database he? Hoe groter het geheugen, hoe meer van de actiefste datapages snel toegankelijk zijn en hoe meer het I/O-systeem gebruikt kan worden voor het ophalen van willekeurige data. Zeker als je daardoor je indexen compleet toegankelijk houdt is meer geheugen interessant.
Bij I/O moet je er ook op letten dat 'raid 10' niet zo veel zegt, bij veel I/O-load kan het best nuttig/nodig zijn om te investeren in een behuizing met 10+ harde schijven (SSD is helaas nog steeds nogal prijzig, voor de prijs van 4x64GB kan je geloof ik ook 30 snelle harde schijven kopen..).

De vraag is bij de laatste mogelijkheid: hoe lang gaat dat goed? Een cluster schaalt natuurlijk veel beter. Server erbij, en je kunt weer vooruit.

Lang niet alle cluster-opzetten zijn even schaalbaar. Dus ga er niet zomaar van uit dat je een triviale 'even een server er bij en klaar'-aanpak weet op te zetten. Je kan echter wel kijken naar een hybride-oplossing, meerdere vrij zware servers inzetten.

Misschien hebben jullie nog ideeën? We hoeven ook niet perse bij Postgresql te blijven, maar dat heeft wel duidelijk de voorkeur. Kom echter niet met iets als Oracle aanzetten, daar hebben we helaas het budget niet voor

Je naar de omgebouwde postgresql van greenplum kunnen kijken. Wat jij hier beschrijft zou wel eens in hun straatje kunnen vallen.

voodooless schreef op dinsdag 24 juni 2008 @ 01:46:
Als Postgres incrementele backups kan doen zou dat mooi zijn, dat is iets om uit te zoeken. Momenteel gebeurt 's nachts veel te veel werk voor een backup, en overdag eigenlijk ook.

Vziw kan PostgreSQL dat door middel van log-shipping. Daarbij maak je periodiek een complete backup (bijv elke zondag) en je houdt alle wijzigingen tov die data bij door je WAL-logs naar een archief-directory te kopieren ipv te verwijderen na dat ze vol zijn.
Hoe dat verder in zijn werk gaat weet ik niet, ik heb het zelf nooit gebruikt.

In de nieuwe situatie zal er echt de hele dag door activiteit zijn.

In mijn genoemde aanpak met een queue kan je het verwerken van die queue natuurlijk eventueel tijdens de backup stilleggen. Mits dat binnen het business model mogelijk is natuurlijk.

Daar hebben we natuurlijk al naar gekeken, en gaan we ook zeker nog naar kijken in de nieuwe opzet. Het is eigenlijk zo dat de queries eigenlijk redelijk simpel zijn en in vrijwel alle gevallen direct op indexen werken, probleem is gewoon de grote datasets.

Nog meer reden om er voor te zorgen dat je indexen compleet in het RAM passen dus.

Duidelijk is nu al te zien dat de server vooral bezig is om van disk te lezen, zelfs bij een simpele select op een id (primary key) tussen twee waardes.

"" ""

Verder kan ik nu wel gaan tweaken aan dingen om het weer vlot te trekken, dat is echter geen structurele en goed schalende oplossing. Vroeg of laat loop het weer tegen de rand aan.

Maar het zorgt er wel voor dat het langer doorschaalt, als je de boel goed tweakt en getweakt houdt.

[justmental]

Met SSD's maak je je I/O's heel goedkoop maar ik ben bang dat je daarmee alleen uitstel van executie bewerkstelligt.
Waarschijnlijk zit het schaalbaarheidsprobleem in je applicatie en database.
Je noemt bijvoorbeeld de eenvoudige query's via index lookups. Voor veel taken is het handiger om complexere query's te hebben om het aantal calls terug te brengen en de database in te zetten op het vlak waar hij sterk in is.
Die database is echt klein en een dag is erg lang.

[voodooless]

EfBe schreef op dinsdag 24 juni 2008 @ 11:27:
Begrijp ik het goed dat je eigenlijk 1 tabel hebt met erg veel rows en dat je daarin veel inserts en leesacties hebt?

Het is inderdaad hoofdzakelijk een grote tabel met inserts en leesacties. Momenteel gebeuren deze nog gescheiden van elkaar, maar straks gaat er veel meer door elkaar lopen.

Wat doet dat script precies? M.a.w.: trekt dat alle data uit de db naar een client, of houdt dat de data in de db? Leesacties, die vinden plaats op geprocesste data (data geproduceerd door het script) ? Over hoeveel rows praten we?

Als je het echt weten wil: momenteel hebben we ruim 230.471.921 rows gemiddeld 800.000 rows per dag erbij, resulterende in rond de 40.000 rows voor de verwerkte data.

Applicaties doen van alles. Enerzijds het verwerken van de data. Hiervoor worden flinke blokken uitgelezen, geprocessed, en het resultaat wordt in een andere tabel gedumpt. Andere apps halen flinke blokken data op om deze te kunnen displayen.

Want 10K is echt geen 'grote dataset' . Een grote dataset is miljoenen rows en een paar miljoen inserts/reads per dag. Het aantal rows is belangrijker dan hoeveel ruimte ze innemen op disk.

Ik heb het over 10K+ objecten, niet 10K rows. Dat zijn inderdaad miljoenen inserts en reads per dag

Het punt is nl. dat je op een gegeven moment tegen fysieke grenzen aanloopt en je moet terugvallen op clusters, waarin andere regels gelden: lezen en schrijven gebeurt niet meer tegelijk op dezelfde tables, tenzij je een cabinet erneer zet en een cluster ervoor.

Dat zijn dus oplossingen als PGPool en Sequoia.

Je kunt ook het 'shard' idee toepassen, dat is in feite partitionering, maar op PK range bijvoorbeeld. Wat het in feite inhoudt is dat je zelf de data horizontaal splitst dus, row 1-10000 zitten op bak 1, 10001-20000 op bak 2 etc. Dit werkt wanneer de lees acties niet bv hele tabellen gaan joinen, maar record voor record lezen, zodat je in je code kunt switchen.

Dat is wat er nu dus lokaal gedaan wordt, en dat scheelt al aanzienlijk. Met meerdere machines kan dat ook. Maar zelfde heb je ook met machines waar overal alles op staat. Voordeel is daarbij dan dat je redundancy en flexibiliteit hebt.


Even tussendoor: alvast allemaal bedankt voor de zeer nuttige input . Veel inzichten geven een duidelijk beeld

ACM schreef op dinsdag 24 juni 2008 @ 11:40:
Allereerst: draai je al postgresql 8.3? Zonee, zou ik zeker upgraden, er is aardig wat werk gestoken in betere benutting van het I/O-systeem (o.a. door lagere overhead van records). Helaas vereist dat wel een dump/restore, maar met mijn 90GB-db duurde dat een paar uur.

Momenteel nog 8.2 En dat gaat zeker nog naar 8.3 (tenzij er een andere oplossing gekozen gaat worden natuurlijk ).

Heb je alle (nieuwe) logpunten van alle routes nodig voor je die verwerking kan doen? Zonee, dan kan je natuurlijk vrij triviaal de boel in een queue-achtige oplossing plaatsen en die gewoon met meerdere consumers uitlezen terwijl ie aan de andere kant gevuld wordt. Op die manier kan je triviaal opschalen naar meerdere parallele taken voor het invoeren van de data.

Je hebt alleen de nieuwe punten nodig. Het nieuwe idee is ook precies zoals jij dat beschrijft. Is echter niet alles. Gebruikers kunnen ook historische gegevens inzien, dan heb je het niet over recente info, maar dingen die al jaren in de db staan.

Verder vraag ik me af of je verwerking van dusdanig zware aard is, dat het interessant kan zijn om dat process in meerdere servers te splitsen, waarbij je dus de ruwe data op machine/pool A hebt en de uiteindelijk verwerkte data op machine/pool B hebt. Op die manier kan je B wellicht ook wat gunstiger tunen voor het uiteindelijke werk, bijvoorbeeld door de records veel kleiner te maken.

Dat zal ook deels zo zijn, maar omdat bepaalde informatie direct beschikbaar moet zijn kunnen we dat niet met alles doen.

Ik vind 4GB wel heel erg weinig geheugen voor een moderne database... Gezien de kosten ervan zou ik niet eens minder dan 16GB overwegen. Je weet natuurlijk wel dat de hoeveelheid geheugen de belangrijkste factor is voor de performance van de database he? Hoe groter het geheugen, hoe meer van de actiefste datapages snel toegankelijk zijn en hoe meer het I/O-systeem gebruikt kan worden voor het ophalen van willekeurige data. Zeker als je daardoor je indexen compleet toegankelijk houdt is meer geheugen interessant.

Zeker waar. Daarom komt er sowiso nieuwe hardware. Probleem was dat het oude management "bang" was voor 64 bits linux, en zodoende was je snel klaar. Nu dat probleem uit de weg is kunnen we gewoon serieus over dingen nadenken.

Bij I/O moet je er ook op letten dat 'raid 10' niet zo veel zegt, bij veel I/O-load kan het best nuttig/nodig zijn om te investeren in een behuizing met 10+ harde schijven (SSD is helaas nog steeds nogal prijzig, voor de prijs van 4x64GB kan je geloof ik ook 30 snelle harde schijven kopen..).

Natuurlijk zegt dat niet zoveel. SSD zijn zeker nog best duur, maar als het echt lonend is, is het de investering waard.

Je naar de omgebouwde postgresql van greenplum kunnen kijken. Wat jij hier beschrijft zou wel eens in hun straatje kunnen vallen.

Had ik al gezien ja, eens informeren

In mijn genoemde aanpak met een queue kan je het verwerken van die queue natuurlijk eventueel tijdens de backup stilleggen. Mits dat binnen het business model mogelijk is natuurlijk.

Nope, kan niet

Maar het zorgt er wel voor dat het langer doorschaalt, als je de boel goed tweakt en getweakt houdt.

Natuurlijk is het een combo, en we zullen ook nu de zaak draaiende moeten houden. Maar voor de nieuwe opzet zal het gewoon veel schaalbaarder moeten zijn dan het nu is

[ Voor 44% gewijzigd door voodooless op 24-06-2008 13:19 ]

[djc]

Ken je je read/write-verhoudingen? Zijn er hot spots in je dataset waarbij een goed stuk caching zou kunnen helpen (om te beginnen met meer RAM, zoals ACM al aangeeft)? Is het een optie om ACID deels overboord te zetten en naar minder strikte vormen van consistentie te gaan kijken? Is een relationele database wel de beste oplossing, of zou een andere soort DB wellicht geschikter zijn?

[Verwijderd]

Zelf geen ervaring mee, maar kijk eens naar een product als:
http://www.progress.com/objectstore/index.ssp?ref=hpflash

er zullen nog wel meer vergelijkbare producten zijn.

[EfBe]

voodooless schreef op dinsdag 24 juni 2008 @ 12:54:
[...]
Het is inderdaad hoofdzakelijk een grote tabel met inserts en leesacties. Momenteel gebeuren deze nog gescheiden van elkaar, maar straks gaat er veel meer door elkaar lopen.
[...]
Als je het echt weten wil: momenteel hebben we ruim 230.471.921 rows gemiddeld 800.000 rows per dag erbij, resulterende in rond de 40.000 rows voor de verwerkte data.

Dat is een erg scheve verhouding. Sowieso snap ik iets niet: je hebt 1 tabel, en een verwerkingsscript, maar wat voor data is nou belangrijk? Ik bedoel, als je 800K rows insert maar de data die er feitelijk toe doet is de geprocessete data, dan zou ik me bekommeren om 40K inserts per dag en die 800K rows ergens anders in inserten, bv op een aparte machine. Immers: de verwerkte data lijkt de data te zijn waar het om gaat. Wat me dan niet duidelijk is is: waarom 1 tabel voor beide?

Aangezien de verhouding erg scheef is riekt het naar een tabel met een inmense hoeveelheid historie data die nauwelijks gebruikt wordt. Bij dit soort dingen moet je kijken wat je actieve werkset is: als dat 2miljoen rows is ipv 200miljoen dan kun je 198 miljoen rows verkassen naar een server voor history reports. Die mogen best lang duren voordat ze klaar zijn, want je draait ze immers nauwelijks want de data behoort niet tot de actieve werkset.

Ik heb het over 10K+ objecten, niet 10K rows. Dat zijn inderdaad miljoenen inserts en reads per dag

800K inserts zeg je hierboven, op een gehele dag is dat wel veel, maar geen hoofdpijnhoeveelheid.

Je hebt alleen de nieuwe punten nodig. Het nieuwe idee is ook precies zoals jij dat beschrijft. Is echter niet alles. Gebruikers kunnen ook historische gegevens inzien, dan heb je het niet over recente info, maar dingen die al jaren in de db staan.

kijk, daar heb je al een optimalisatie waar je erg veel winst mee kunt bereiken: oude data, die niet tot de actieve werkset behoort (en dat is OOK data die nog niet is geprocessed door je script) uit je database halen die de actieve werkset vormt.

Zeker waar. Daarom komt er sowiso nieuwe hardware. Probleem was dat het oude management "bang" was voor 64 bits linux, en zodoende was je snel klaar. Nu dat probleem uit de weg is kunnen we gewoon serieus over dingen nadenken.
Natuurlijk zegt dat niet zoveel. SSD zijn zeker nog best duur, maar als het echt lonend is, is het de investering waard.

... maar je hebt geen geld voor oracle... beetje raar? Zo duur is oracle nou ook weer niet.

[leuk_he]

Je eerste bottleneck die je nu blijkbaar tegenkomt is je backup.

Als je data doorgroeit blijft dit een bottleneck. Welke backup methode gebruik je nu?

Maak je een dump van tabbellen, of een online backup?

Eerste kun je slimmer maken, (alleen wijzigingen backupppen) 2e kun je wellicht optimaliseren door te backuppen.

Andere methode afhankelijk van de data is elke dag een backup op een 2e machine te recoveren en daar de queries te draaien die niet realtime vertrouwen op de laatste data.

4GB klinkt mij als relatief klein geheugen(dat heb ik thuis in mijn desktop, databases houden van veel meer geheugen!) . Neem aan dat je naar een 64 bitomgeving kunt waar je een veelvoud kunt gebruiken. Je bottleneck is nu IO: geheugen toevoegen kan hierbij helpen om je IO naar beneden te brengen.

Een cluster klinkt leuk, maar verhoogt de complexiteit wel enorm. Ben daar heeel kritisch in. (link is voor oracle, maar valt ook te vertalen naar andere databases. )

Al de cluster producten genoemd verhogen de complexiteit en voegen nieuwe bottelnecks toe om de oude op te lossen. Als je de mogelijkheid hebt om gewoon (en met gewoon bedoel ik niet hele dure servergrade) ijzer bij te zetten, probeer dat dan een poosje vol te houden.

[voodooless]

Ik heb een mailtje uitgedaan naar Greenplum. Eens kijken of ze inderdaad goedkoop zijn als ze claimen. Andere clustering oplossingen lijken me eigenlijk een beetje te onbetrouwbaar en er plakken teveel nadelen aan.

Anders zal het wel een nieuwe server worden met een flinke disk array, veel memory, en de juiste keuze van os en fs. Ik zit dan te denken aan OpenSolaris met zfs...

Of er moeten zich nog andere dingen aanbieden natuurlijk

EfBe schreef op dinsdag 24 juni 2008 @ 14:21:
Wat me dan niet duidelijk is is: waarom 1 tabel voor beide?

Nee, we hebben natuurlijk niet een tabel voor beiden Dat zou totaal onlogisch zijn natuurlijk. De 800K gaan in een tabel en de 40K resultaat gaan in een andere tabel.

Aangezien de verhouding erg scheef is riekt het naar een tabel met een inmense hoeveelheid historie data die nauwelijks gebruikt wordt. Bij dit soort dingen moet je kijken wat je actieve werkset is: als dat 2miljoen rows is ipv 200miljoen dan kun je 198 miljoen rows verkassen naar een server voor history reports. Die mogen best lang duren voordat ze klaar zijn, want je draait ze immers nauwelijks want de data behoort niet tot de actieve werkset.

Zoals ik dus eerder al zei: historische data wordt wel gebruikt! Namelijk door de eindgebruikers.

800K inserts zeg je hierboven, op een gehele dag is dat wel veel, maar geen hoofdpijnhoeveelheid.

Klopt. Maar hier blijft het niet bij. Met het tempo waarin het nu gaat kan dat volgend jaar best het dubbele zijn..

kijk, daar heb je al een optimalisatie waar je erg veel winst mee kunt bereiken: oude data, die niet tot de actieve werkset behoort (en dat is OOK data die nog niet is geprocessed door je script) uit je database halen die de actieve werkset vormt.

Dat is in feite dus wat we met partitionering al doen natuurlijk.

... maar je hebt geen geld voor oracle... beetje raar? Zo duur is oracle nou ook weer niet.

Kwa aanschaf misschien niet, maar omdat we hier inhouse totaal geen ervaring in hebben is dat ook weer een leertraject dat tijd en geld kost. Bovendien zie ik de voordelen van Oracle nog niet zo heel erg.

leuk_he schreef op dinsdag 24 juni 2008 @ 14:21:
Andere methode afhankelijk van de data is elke dag een backup op een 2e machine te recoveren en daar de queries te draaien die niet realtime vertrouwen op de laatste data.

Cluster is hier natuurlijk master in, zeker iets als Greenplum. Daar kun je gewoon een full dump maken met minimale gevolgen voor de overige processing activiteiten.

Al de cluster producten genoemd verhogen de complexiteit en voegen nieuwe bottelnecks toe om de oude op te lossen. Als je de mogelijkheid hebt om gewoon (en met gewoon bedoel ik niet hele dure servergrade) ijzer bij te zetten, probeer dat dan een poosje vol te houden.

Dat is waar. En ik denk dat het daar ook op uit gaat komen voorlopig. Wat je wel niet wil is dat je later weer tegen de lamp loopt en de zooi weer moet gaan ombouwen omdat het toch wel handig is om het in een cluster te gooien... Je kunt natuurlijk ook beginnen met een "cluster" van 1 server, en later scalen naar meer. Je hebt dan niet de voordelen van een cluster, maar wel de schaalmogelijkheid, en je hoeft achteraf niet je structuur aan te passen.

[ Voor 77% gewijzigd door voodooless op 24-06-2008 14:47 ]

[leuk_he]

voodooless schreef op dinsdag 24 juni 2008 @ 14:25:
Je kunt natuurlijk ook beginnen met een "cluster" van 1 server, en later scalen naar meer. Je hebt dan niet de voordelen van een cluster, maar wel de schaalmogelijkheid, en je hoeft achteraf niet je structuur aan te passen.

Clusters gaan er vaak van uit dat de hardware op de nodes gelijk is. Als je later extra servers gaat aanschaffen die 2x zo snel zijn heb je nauwelijks invloed op welke node je job gaat draaien. Met als gevolg dat je in je planning rekening moet houden dat de job op de traagste node draait. Als nodes synchroniseren (moet waarschijnlijk wel...) wachten ze op de langzaamste node.

ZFS lijkt me zeker mooi schaalbaar speelgoed(positief bedoeld).

[voodooless]

leuk_he schreef op dinsdag 24 juni 2008 @ 15:11:
Clusters gaan er vaak van uit dat de hardware op de nodes gelijk is. Als je later extra servers gaat aanschaffen die 2x zo snel zijn heb je nauwelijks invloed op welke node je job gaat draaien. Met als gevolg dat je in je planning rekening moet houden dat de job op de traagste node draait. Als nodes synchroniseren (moet waarschijnlijk wel...) wachten ze op de langzaamste node.

Dat is waar. Daarom moet je ook gewoon geen traag spul neerzetten natuurlijk. Een voordeel: hardware wordt goedkoper naarmate het minder high-end wordt (door verstreken tijd);)

Ander voordeel van ZFS is de backup mogelijkheid. Je kunt gewoon een snapshot maken, en van daaruit een backup maken. Zijn mooie tools en guide voor te vinden i.c.m PostgreSQL

[ Voor 12% gewijzigd door voodooless op 24-06-2008 15:26 ]

[leuk_he]

voodooless schreef op dinsdag 24 juni 2008 @ 15:23:
[...]
Ander voordeel van ZFS is de backup mogelijkheid. Je kunt gewoon een snapshot maken, en van daaruit een backup maken. Zijn mooie tools en guide voor te vinden i.c.m PostgreSQL

Wijkt niet zoheel veel af van Online backup wat je nu al kan. Je backup blijft uiteraard disks benaderen en dus het systeem vertragen.

PS, de WAL is een goede kandidaat om op een aparte supersnelle (SSD) volume te zetten.

[Niemand_Anders]

Ik blijf toch een beetje zitten met die ene grote tabel. Hoe vaak wordt daar data uit verwijderd? Hoe vaak voer je een vacuum uit? Als Postgres (of eigenlijk elke andere database) merkt dat de indexen niet meer kloppen met de inhoud van de pages (index bevat veel verwijderde records) dan gebruikt de database de index niet meer, maar valt terug op een table scan.

Clustering maakt de zaken zoals ook de andere aangeven meestal een stuk complexer vooral als er op meerdere nodes wijzigingen worden doorgevoerd. De cluster moet de wijzigen dan mergen met de andere nodes. In het geval van data processing heb je helaas weinig aan een master <--> slave cluster. Wijzigingen worden doorgevoerd op de master welke deze doorgeeft aan de slaves, maar lees acties (select queries) worden uitgevoerd op de slaves. Deze methode werkt goed voor websites en desktop applicaties. Maar als het aantal wijzigen dicht in de buurt van de lees acties ligt ben je dat voordeel kwijt en lever je zelfs performance in. In de meeste gevallen zijn 'dirty' nodes niet een optie. Daarbij worden de slaves onafhankelijk van elkaar geupdate en is het mogelijk dat slaves nodes niet altijd dezelfde data bevatten.

[voodooless]

Niemand_Anders schreef op woensdag 25 juni 2008 @ 09:34:
Ik blijf toch een beetje zitten met die ene grote tabel. Hoe vaak wordt daar data uit verwijderd?

In principe nooit.

Daarbij worden de slaves onafhankelijk van elkaar geupdate en is het mogelijk dat slaves nodes niet altijd dezelfde data bevatten.

Dit soort dingen kun je voor clusters helaas niet zomaar generaliseren. Ik heb ondertussen over verschillende cluster toepassingen gelezen, en die hebben allemaal hun eigen werking, en dus ook allemaal weer andere voor en nadelen. Als je voor een cluster zou gaan, zou je goed moeten kijken naar de verschillende oplossingen en daar een duidelijke afweging moeten maken.

Greenplum is mooi, maar toch wel bedoeld voor databases die nog een keer extreem veel groter zijn dan die van ons, in de terra- en petabyte range Ik ga alsnog informeren natuurlijk.

Verder denk ik dat we moeten gaan gewoon een extra force machine met een berg disks, eventueel SSD's een berg memory, en voldoende cores, om zo de IO throughput te kunnen maximaliseren. Ik lees verder zeer goede verhalen over ZFS. Enerzijds over de performance, en anderzijds over de schaalbaarheid van het fs.

[burne]

voodooless schreef op donderdag 26 juni 2008 @ 09:28:
In principe nooit.

Pardon my french, maar is een database dan wel de meest handige manier van opslaan? Is parsen en archiveren, en enkel de geparste data in een database zetten geen efficientere manier?

[voodooless]

burne schreef op donderdag 26 juni 2008 @ 09:46:
Pardon my french, maar is een database dan wel de meest handige manier van opslaan? Is parsen en archiveren, en enkel de geparste data in een database zetten geen efficientere manier?

Nope, de data die in de tabel staat is al deels geparsed, en wordt ook daadwerkelijk gebruikt door eindgebruikers, samen met het resultaat van de bewerking van deze gegevens. Je hebt dus daadwerkelijk alle data nodig.

[djc]

Misschien moet je ietsje concreter zijn over de vorm van je data.

En ik heb nog geen antwoord gezien op mijn vraag of je überhaupt niet-relationele databases bekeken hebt. Weet je wel zeker dat een RDBMS de beste oplossing is voor jouw probleem?

[burne]

voodooless schreef op donderdag 26 juni 2008 @ 09:28:
Verder denk ik dat we moeten gaan gewoon een extra force machine met een berg disks, eventueel SSD's een berg memory, en voldoende cores, om zo de IO throughput te kunnen maximaliseren.

Van de andere kant: 800K inserts is 10 per seconde. Weet je hoeveel t.net er doet?

Ik lees verder zeer goede verhalen over ZFS. Enerzijds over de performance, en anderzijds over de schaalbaarheid van het fs.

Ik lees ook veel verhalen, maar die gaan over features voor een latere versie, over fouten, onverwacht gedrag en soms redelijk fundamentele problemen. Ik heb ergens het idee dat het nog niet helemaal af is. Ik wacht in ieder geval nog even.

[matthijsln]

voodooless schreef op donderdag 26 juni 2008 @ 09:56:
[...]
Nope, de data die in de tabel staat is al deels geparsed, en wordt ook daadwerkelijk gebruikt door eindgebruikers, samen met het resultaat van de bewerking van deze gegevens. Je hebt dus daadwerkelijk alle data nodig.

Kan je niet wat meer details geven van wat je data is en wat je ermee doet? Want identificeren van bottlenecks en optimaliseren van de applicatie lijkt me toch het eerste wat je gaat doen voordat je een dikke server of een cluster gaat aanschaffen (zeker als je toch alle software vanaf 0 gaat opbouwen(??))?

Tot nu toe weten we alleen dit:

Er staan verwerkte en onbewerkte routes(?) in met in de orde van 10.000 routepunten per route.

Vragen, vragen vragen

Wat houdt verwerken in, wat gebeurt er daarbij met andere routes (welke routes, bv alleen in de omgeving, alleen recent of ander criteria? alleen tekenen? ruimtelijke analyse? benodige precisie?) Hoe vaak gebeurt het verwerken, hoeveel tegelijkertijd, kunnen er bulk dingen via evt een queue en zijn er onderdelen die absoluut direct moeten wordt gedaan? Kan je de benodigde dataset verkleinen? Waar wordt de verwerkte en onverwerkte data voor gebruikt naast verwerken? Editen/tekenen van de routes?

Doe je met je db alleen insert en select met (custom??) index op woonplaats queries of zijn er meer soorten queries? Wat zegt explain voor trage queries?

Als je zoals ik eerder vroeg gebruik maakt van PostGIS/GIS tools, kan je door je applicatie vanuit een GIS oogpunt te bekijken allemaal leuke dingen doen qua performance zoals een spatial index gebruiken, spatial functies (voor verwerking, maar bv. ook oude routes simplify()'en), of werken met lagere precisie op hoger zoomniveau, snelle rendering met shapefiles/tilecaching, evt onderverdelen in aparte layers, etc...

Ik denk toch echt dat je met die route er sneller komt dan een boel servers met sexy specs of een ander bestandssysteem (heb je fsync dan aan??).

[Verwijderd]

EfBe schreef op dinsdag 24 juni 2008 @ 14:21:
800K inserts zeg je hierboven, op een gehele dag is dat wel veel, maar geen hoofdpijnhoeveelheid.

Dat gevoel heb ik ook. Bij 60Gb database en de load die je beschrijft, vind ik aan clustering en SSD denken al een stap te ver. Ik denk dat je echt eerst naar je architectuur en infrastructuur moet kijken, voordat je naar andere zaken gaat kijken, want 60Gb of 800.000 is niet extreem veel.

Ik ken je omgeving natuurlijk niet, maar uit je korte omschrijving, zou ik (met SQL Server) in eerste instantie denken aan een Staging server voor de ruwe data, dan verwerken met Integration Services naar de echte database. Maar het kan best dat dit helemaal niet voldoet in jouw geval, want wie doet er inserts? Is dat alleen tijdens het laden\verwerken van nieuwe data? Hoeveel (verwachte) gebruikers lezen (en schrijven?) de data tergelijkertijd?

voodooless schreef op dinsdag 24 juni 2008 @ 12:54:
Natuurlijk zegt dat niet zoveel. SSD zijn zeker nog best duur, maar als het echt lonend is, is het de investering waard.

Als dit kan, kan je volgens mij beter een expert voor één a twee dagen inhuren, om je bottlenecks te vinden en oplossingen aan te dragen. Is goedkoper dan nu code opnieuw te gaan schrijven en nieuwe hardware te gaan kopen zonder dat je weet of het je probleem gaat oplossen (of alleen uitstelt).

[voodooless]

burne schreef op donderdag 26 juni 2008 @ 12:07:
Van de andere kant: 800K inserts is 10 per seconde. Weet je hoeveel t.net er doet?

[afbeelding]

Het zijn er nog 800K per dag.. De verwachting is dat dat aantal significant gaat toenemen. En verder weten we ook de spreiding niet precies, omdat we dat nu nog moeilijk kunnen inschatten

Ik lees ook veel verhalen, maar die gaan over features voor een latere versie, over fouten, onverwacht gedrag en soms redelijk fundamentele problemen. Ik heb ergens het idee dat het nog niet helemaal af is. Ik wacht in ieder geval nog even.

Heb je links naar die verhalen? Ik lees eigenlijk vooral positieve dingen tot nu toe, in iedere geval zolang je op OpenSolaris blijft..

matthijsln schreef op donderdag 26 juni 2008 @ 15:15:Kan je niet wat meer details geven van wat je data is en wat je ermee doet? Want identificeren van bottlenecks en optimaliseren van de applicatie lijkt me toch het eerste wat je gaat doen voordat je een dikke server of een cluster gaat aanschaffen (zeker als je toch alle software vanaf 0 gaat opbouwen(??))?

De applicatie bestaat eigenlijk uit twee delen:
1. Ophalen van de logpunten. Hier zijn er 3 manieren: of ze worden door een applicatie de hele dag door actief uitgelezen. Of ze komen realtime binnen. En de laatste manier is via user upload. Deze 3 manieren schrijven sessies weg en signaleren 2. dat ze met verwerken kunnen beginnen
2. verwerken van routes: Opvragen van punten van voorgaande sessie, en eventueel ook nog enkele sessies eerder, en alle punten nalopen om er routes van te maken. Routes worden vervolgens terug gepushed naar de database (en eventueel andere db's). Dit proces dient behoorlijk snel te zijn aangezien klanten hun routes vrijwel direct willen zien zodra de punten binnen zijn. Dit proces kun je helaas niet in de database doen door middel van een simpele query.

Wat de spreiding precies gaat zijn kunnen we nu nog moeilijk zeggen, en de spreiding zal ook in de loop van de tijd veranderen door andere samenstelling van het productassortiment. We kunnen echter stellen dat het een proces is dat de hele dag door loopt, met rond de spitsuren en 's avonds na de spits piekuren.

Wat houdt verwerken in, wat gebeurt er daarbij met andere routes (welke routes, bv alleen in de omgeving, alleen recent of ander criteria? alleen tekenen? ruimtelijke analyse? benodige precisie?) Hoe vaak gebeurt het verwerken, hoeveel tegelijkertijd, kunnen er bulk dingen via evt een queue en zijn er onderdelen die absoluut direct moeten wordt gedaan? Kan je de benodigde dataset verkleinen? Waar wordt de verwerkte en onverwerkte data voor gebruikt naast verwerken? Editen/tekenen van de routes?

Momenteel is het nog zo simpel als het verwerken van punten naar routes. Later kunnen daar nog processen omheen komen.

Als je zoals ik eerder vroeg gebruik maakt van PostGIS/GIS tools, kan je door je applicatie vanuit een GIS oogpunt te bekijken allemaal leuke dingen doen qua performance zoals een spatial index gebruiken, spatial functies (voor verwerking, maar bv. ook oude routes simplify()'en), of werken met lagere precisie op hoger zoomniveau, snelle rendering met shapefiles/tilecaching, evt onderverdelen in aparte layers, etc...

Dat soort dingen hebben we niet nodig gelukkig. Daar hebben we 3rd party software voor.

Het gaat echt om platte data, met redelijk simpele selects en inserts die ik eigenlijk altijd wel hun werk via indexen doen. De ingewikkelde dingen gebeuren eigenlijk buiten de database om.

Het probleem is ook dat het nu wel min of meer loopt, maar dat wil niet zeggen dat dat zo gaat blijven, zeker niet met de verwachte groei en de veranderde structuur.

En nogmaals voor de duidelijkheid: zowel de ruwe als verwerkte data is voor de eindgebruiker van belang. Beiden dienen dus ten alle tijde beschikbaar te zijn.

Dat er iets nieuws moet komen is gewoon duidelijk, ook al gaan we dingen optimaliseren en finetunen. Een dergelijke database kunnen we gewoon niet runnen op een machine met maar 4 GB memory, zeker niet als daar ook nog andere dingen naast draaien (don't blame the messenger).

[djc]

Het klinkt heel erg als TomTom HD.

[voodooless]

Manuzhai schreef op vrijdag 27 juni 2008 @ 17:03:
Het klinkt heel erg als TomTom HD.

Nope, dat zijn we niet