Väldigt nöjd med hur Berkeley DB när byggd fungerat via DB FILE i Perl. En verklig välsignelse att inte behöva sitta och vänta för varje debug-körning flera minuter och indirekt p.g.a. ibland skjutande på integration av delar.
Vad som förvånande och oroar mig lätt var att bygga DB-filen för inte mer än cirka 350 - 450 MB common sense jag lät den referera på enklaste möjliga sätt som sträng utifrån första CSV-fältet (och sätter resp. struktur korrekt under körning första gången efterfrågad) tog flera timmar. Överdrivet duktig på att frysa via file access övriga processer att komma åt aktuella partitioner och föga påverkad av nice-level på det.
Det oroande är att jag vill ha samma lösning för allt sådant här där den största datastrukturen är för similarity-operationer. Där är det även för få entiteter efterfrågade tydligt långsamt att göra operationer så datarepresentation av färdig-beräknade värden är mycket trevligt oavsett situation. Samtidigt tror jag att den totala mängden färdigberäknade värden ligger på över 100 GB. Lösningen har redan idag en handbyggd lösning som läser en in uppdelade "mindre" filer och vid behov enligt konfiguration också avlägsnar dem hur minnet för att hindra hela datorn att kräva kallstart.
Egentligen tycker jag att det är underligt att den behöver så pass enorm tid för att bygga databas-filerna. Jag spekulerar att diverse databas-optimeringar relativt anrop hanteras jag egentligen saknar behov av och inte brytt mig om att notera.
Det blir gissar jag nödvändigt att sätta något meta ovanpå Berkeley DB i sig för similarity om det alls ska klara att ta sig igenom similarity datat på mindre tid än normala boot-perioder på några veckor. Uppdelat per första tre bokstäver (varande minsta orden jag accepterad utanför den semantiska parsern d.v.s. avseende koncept i Blue light eller common sense) bör kanske ge rimligt stora filer. Eller förhoppningsvis over-kill jag inte behöver göra (varande något jag önskade slippa med Berkeley DB för att slippa lära mig något färdigt och när det fungerar sunkigt skriva det själv) hasha begreppen ovanpå och reducera till mindre underrum - ett par fil med koncept (krävs det är man ju i princip upplever jag där man lika gärna kan koda det hela själv eller använda den befintliga similarity-cashe-lösningen).
Ett mer generellt tänk jag med mer faktisk erfarenhet i LDAP och X.500 än i SQL (jag kan oerhört lite SQL) är att låta naming motsvara hur vi adresserar koncepten där ett mellan-lager kan hantera vad som är aspekter av koncept resp. är ett koncept adresserat strukturerat enligt en ordning. Men praktiskt tror jag väldigt opraktiskt med mindre än att 99.99% av allt är fryst.
Rörande det licens-tekniska ska noteras att man åtminstone utanför debug-användning troligt bäst licenser kommersiellt från Oracle.
