Det här Berkeley DB: Bygga db-filerna snabbt var mycket möjligt felaktigt (nyckeln använd var inte riktigt korrekt så allt adderades till en motsvarande tom-sträng).
Men efter lite prövande gavs väl en förklaring mindre till den för mig i alla fall exponentiella kostnaden men väl för varför förra omgången storleksordningen 80 MB var ungefär funktionellt. Resp. vid cirka 42 resp. ca 80 + något tycks den lägga på chunk och kanske räkna om hash-tabells-adresseringen till filerna.
Vid ungefär 650 000 st instoppade av typen:
- Nyckel säkert unik: ngram \t ngram Värde: "Double" decimal
Har man ganska precs under fått vad man får av första 42 - 44 MB chunk:et och kan börja på nästa BDB-fil (om man tillsvidare inte är överdrivet engagerat av ev. tids-kostnad längre fram av att kontrollera över ett tusentals BDB-filer var ett koncept är lagrat vilket vi nog inte är här eftersom BDB-filerna komma anropas innifrån Apache vilket jag tror gör sådana skillnader försumbara alt. får man väl räkna om filerna eller kanske hellre göra något mer problematiskt och smalare över-tiden men snabbare själv eller ev. smart kan härleda det).
Verkligen att det är tråkigt att i alla fall Perl gränssnittet jag använder inte ger möjligt att direkt ge den en enorm rymd at addressera. Ex. några Gig. Man betraktar som trovärdig rymd och när kollissioner är problem börjar man på nästa och tar hårddisk-kostnaden för det som ju ändå är det billigaste per krona man har i datorn.
Grundprobemet tror jag hur som helst är att allt för mycket av subkulturer kring slöare områden får fokus på nätet. Internet-populationerna behöver känner jag starkt börja självorganisera mycket mer på temat big-data på begränsad hårdvara.
Rörande mitt design pattern i Berkeley DB: Bygga db-filerna snabbt var intrycket efter att defekten korrigeras att själva fil-rymden skapas direkt beroende hash-värdet d.v.s. med en nyckel _DEBUG man sedan tar bort kommer BDB ändå ungefär eller exakt fortsätta att expandera filen enligt där man var. Av samma anledning att man här verkligen mycket säkert skulle vinna så mycket i mötet genererings- resp. hämta-data-tid på att kunna dra upp hela resp. under-rum för adresseringen. 1 GB snarare än 40 MB gör nog gigantisk skillnad (en liten misstanke här är att BDB kanske hanterar adressering och kollisioner genom att addera resp. under-rym som hash-utvärdesstyrande parameter? Men tror jag över-smart för att det inte ska svälla iväg i datafilen medan jag känner mer som att jag kan ta en helt osannolik kollision på nivån rent av en per 1 million kombinationer NGRAM vilket i sig helt säkert är en enorm överskattning var man skulle hamna. Likväl fungerar det görligt nu genererat avstår jag att koda det själv).
