Nuvarande försök att skapa mitt P ( A | B ) nätverk via BDB (Berkeley DB) fick jag ge upp. Vid cirka 500 BDB-filer på vardera cirka 40 MB (som vi minns blev skapandet där efter långsamt på nivåer att jag ganska verklighets-nära upplevde att det aldrig skulle bli klart) uppstår problemet att addera in nya värden blir tämligen långsamt.
Med indata-filer med p-värden - men ej komprimerat så att varje p-värde förekommer unikt - på totalt cirka 20 - 30 GB (eventuellt det dubbla om jag tänker mer) och en fil på cirka 10 GB (verksamhetsdata relaterat NIH för att få hälsoperspektivet) gående flera dagar dödade jag ner hela denna väg.
Orsaken är jag helt övertygad om beror på att data skrivs rätt ner 1 - 1 utan att spara filhandels effektivt.
Lösningen jag startat upp istället är att processa alla filerna och dumpa ner resp. p-värde till fil motsvarande första två eller tre tecknen på A (där A och B alltid är sorterade redan i indata). Det tycks förvisso snabbt nog och förhoppningsvis (ganska troligt hoppas jag) blir ingen fil större i unika termer än vad jag klarar av att hålla i minnet.
Därefter helt klart så att säga tänker jag mig att bygga BDB-filerna.
Det är dock oavsett problemen här värt att inse att man alltid behöver mellan-lager i drift mot Perl's BDB-lager (och antagligen ganska allmänt) där man håller termer i minnet om de anropas igen, rensar det av och till på tröskelvärde antal termer (eller smartare och vad jag gör om jag hittar min färdiga kod för det från tidigare liknande svårighet relaterat similarity beräkningar: när mängden ledigt minne börjar närma sig OS-dödar processen snart).
Att inte göra den sista åtgärder reducerar hastigheten när först diskuterade sker riktigt ordentligt och åtminstone skattat utan klocka minst 10 ggr (och tror jag egentligen mycket mer än så).
Längre bakåt innan jag gjorde investeringar för ett par år sedan i färska datorer och körda allt på en riktigt gammalt kontors-pc såg jag förutom diverse vardags-problem också ett stort värde i begränsad hårdvara. Man tvingas till mycket effektiva åtgärder.
I varje begränsat projekt kan skillnaden mellan en sådan framtvingad effektiv åtgärd och antagligen flera timmar besparat i utvecklingstid upplevas som förlust. Men när alla del-lösningar tas samman till att processa dom störa mängderna data märker man skillnaden av att tvingas välja det brutalt optimerade i varje steg.
När vi här bygger P ( A | B ) nätet och ej från teoretisk princip gällande för nätet vill göra någon som helst dimensionsreduktion därför att dimensionsreduktioner är vad som sker löpande under drift utifrån faktiskt behov format från ex. resp. sökförfrågan eller jämförbart finner jag det svårare att upptäcka sådana värden när det egentligen fortfarande inte handlar om mer än att summera resp. P-värde (viktat med en funktion av type och token för resp. under corpus),
- Särskilt som jag ser P ( A | B ) nätet här som prel. och bygger fortlöpande för att nå up-to-current-day ungefär 30 - 40 dagars färska nyheter skattat för cirka 1000 - 10000 news providers (beroende av om vi endast låter direkta do-inverka i form av optimerat endast titel i vilket fall 10000 minst krävs eller om vi väljer färre news providers men av hög kvalitet där vi förstår hur de uttrycker nyheterna och kan låta motsvarande bilder, och teleprinter-rubriker eller verkliga underrubriker verka också där knappast mer än 3000 och gissar jag just 1000 räcker: men praktiskt antagligen att jag kör in 10000 för att vara säker).
, är det svårare att se detta värde.
Samtidigt vet jag med säkerhet att diverse ständigt återkommande i forskningsstudier relaterat detta område om att tidig dimensionsreduktion rent av värde hanterande obalanser i indata inte är annat än begränsning i mängden indata de jämför dimensionsreduktion för resp. tidpunkten dimensionsreduktionen sker (d.v.s. gör du den tidigt försökande skapa utvärden du kan använda alltid - visst du kan säkert behöva en massa smoothing för att det ska verka vettigt - men gör vi den senare mer direkt anpassat gäller inte det men kostnaden måste likväl betalas och det är här kostnaden ligger istället).
Jag får dock erkänna att jag mer och mer lutar åt att kasta ut hela BDB och skriva det själv riktat optimerat mot användningen. Det blir i så fall område nummer två där jag lovade mig själv att jag absolut inte skulle behöva implementera det själv därför att så mycket bra bevisligen fanns. Nummer ett var undersystem med logiken egen-utvecklad för Natural language processing och nummer två här är en databas. Och om något givet slö-införande problematik för alla databaser jag prövat (om något sämre för Mysql väldigt förvånande såväl Postgres) är närmast argumenten större än för nivån där jag valde att utveckla NLP-stödet själv (där istället emellertid givetvis andra argument fanns som talade för det från hela området vi rör oss i även om det personliga motståndet för att någonsin igen bedömt från några kommersiella konsult-projekt långt tillbaka var enormt).
Erfarenheten att ta med sig är att databaser normalt inte är skapade för att hantera big data på small computer men att det som alltid löser sig därför att om det här projektet om något format mig till något är det just att hantera sådant.
