Komplettering: Det är tror jag bättre (men inte helt säkert) att läsa detta innan man bygger BDB-filer enligt nedan under ett antal timmar: Berkeley DB: Bygga db-filerna snabbt.
Första större omgång jag byggde filer (från perl interface) kunde jag konstatera att de regelmässigt efter ett tag började ta evigheter på sig att komma någonstans. Jag antog att det hade att göra med hash-funktionen relativt den aktuella storleken på filen och hur delar av datat lagrades där.
Praktiskt den gången var det praktiskt enkelt löst genom att använda en mängd enskilda DB-filer var och en aldrig större än cirka 80 - 140 MB.
Denna gång visade sig den metoden addera noll och ingenting. Men däremot en annan praktiskt efterföljande på alla sätt också mycket enklare metod. Medan den första metoden adderande kanske 800 - 1400 MB data över ca 30 filer arbetat ungefär tre dagar utan att hunnit klart klarade den andra filen av det på cirka en timme.
Jag antog som föregående att lokal fragmentering som funktion av indexering var problemet men också att min hårddisk kanske bitvis var fragmenterad även om stora chunk av ej fragmenterat data med säkerhet fanns (därför att jag tog och flyttade några riktigt stora filer som varit där länge ut från den).
Initialt när resp. DB-fil skapades adderade jag nu del-steget att addera en enormt stor sträng tilldelat ett värde vilket gav DB-filer initialt på ungefär 1/2 GB eller större beroende på exakt situation jag gjorde dem för. Sättande värdet till den tomma strängen eller avdefinierande den fick ej Berkeley DB att reducera fildatabasen.
Därefter adderades data in med prestanda funktionell.
Ett fint exempel på den form av praktiskt användbara handgrepps-kunskap jag är trygg i att internet-världen har mycket större nytta av än om jag ex. istället delat den P ( A | B ) data från bl.a. nyhetstitlar jag adderar samman här.
