Hier heb ik het inderdaad al eens met Wessel over gehad. Wessel had de source en jij niet, dus ik vermeld er nog even bij dat Foondump momenteel al batched inserts in blokken van 1000 gebruikt. Dat neemt de meeste pijn mbt het bijwerken van de indices weg.
Even in mijn Sent Items gespit:
Wel heb ik al eerder wat metingen gedaan na diverse opmerkingen over het
traag gaan van het rippen, om na te gaan of dat nu in de KPN/Telemedia/CMG
code zit of in mijn eigen export functies. Als test heb ik de gids tot en
met ‘Aalsmeer’ gedumpt en gekeken hoe lang e.e.a. duurt. (En ja, meerdere
malen gedaan en gemiddeld, gezorgd dat e.e.a. in hard disk cache zat en meer
van dat soort details)
- helemaal geen output code : 0:45
- output naar CSV bestand: 0:46
- output naar MySQL: 1:02
- output naar MySQL zonder indices: 1:00
Ik besef dat hoe groter de database (dus daar is t/m Aalsmeer rippen niet
echt representatief) hoe meer tijd het bijwerken van de index kost maar als
je het achteraf moet doen kost het ook tijd. Weliswaar gaat het dan iets
efficienter maar ik denk dat de meting aantoont dat het verschil marginaal
is. Daarentegen wordt de code weer complexer doordat je achteraf indexen
moet aanmaken. En ik zie de forum berichten al van al die mensen die het
vergeten en waarbij de database niet meer performt.
Waarom gaat het dan zo langzaam? De gids wordt nu alfabetisch doorlopen, en
dat is (dus) niet sequentieel. Daar zit dus een hoop IO wait. Onder water
worden er blokken van disk gelezen, die worden in geheugen gedecomprimeerd
en vervolgens worden de records eruit gehaald. De laatste keer dat ik de
code goed bekeken heb werden er wel blokken gecached maar alleen in
gecomprimeerde vorm. Daar zit dus relatief veel processor overhead, omdat
als ik tien records opvraag in blokken A, B, A, B, A, B, A, B, A, B er dus
10 x een blok geladen en gedecompressed wordt. Het is echter de enige manier
waarop ik de gids kan doorlopen op het niveau van de Java JNI API.
Mijns inziens valt er met de huidige aanpak dus niet echt veel performance
winst te halen, hooguit 20% maar zeker geen factor. Die verhoudt zich slecht
tot de moeite die je ervoor moet doen tijdens het ontwikkelen.