Berkeley DB med Perl: json_encode / json_decode vs att dela upp platt men stor grafstrukturer till ett index för varje båge

Jag representerar typiskt data jag lägger i BDB (flera BDB-inlägg hittas i taggen) som JSON därför att det nästan alltid är en graf-liknande struktur som slås upp från en nyckel av flera koncept. Grafer är mycket funktionellt att koda till JSON för att få som sträng i platt BDB (det BDB alternativ vettigt använda och tror jag normalt snabbare än att göra det via XML med stöd nere i BDB-stödjande bibliotek). Det JSON stöd jag använder (mycket kompetent bibliotek som klarar av all JSON som jag minns det oavsett vad jag skapat eller från nätet) finns diskuterat sist

Det håller tycker jag god prestanda för kodning båda riktningarna även för lite komplexa grafer föga platta.

Emellertid oavsett en helt plattstruktur märkte jag en fantastiskt svag prestation när antalet noder direkt under ett första lager börjar växa lite. Någonstans ovanför 7000 - 12000 märks det lätt medan när vi passerat en bit till att det ska behöva ha många sekunder på sig för att gå upp till på min dator flera månader när vi är på flera hundra tusen (de värsta exemplen var föga förvånande location och person: Av de jag lade märke till men de hör helt säkert till de tio största och kan troligt vara också de två största).

I kontrast som jag läste det här för mina databaser med similarity värden mellan en uppslagsnoden och ett antal för-beräknade värden för samtliga nycklar genom att lagra varje förberäknad relation med index-nyckel enligt:

concept_similarity_beräknas_från_som_utgångspunkt_perspektiv concept_similarity_beräknas_till alg_configuration_rörande_vikter_för_uttryck_likhet_och_skillnad prioritet_likhet_eller_olikhet_eller_samlat_standardmått

Istället för att som innan slöa ner en algoritm för att beräkna något annat som gick igenom samtliga relationer similarity fanns beräknat för via flera förfrågningar per relation med någon sekund emellan verkar nu anropen över åtminstone flera hundra tusen upp till kanske 1 miljon (innan jag gick till internet-datorn eftersom ännu inga fel hade rapporterats på de ny-byggda BDB när test-koden jämför slumpmässiga värden från text-filer med själva datat använt) inte mer än kanske 10 - 20 s (vi kan tänka oss en extra 30 s så jag är trygg i att jag inte bedömde det fel eftersom det var en sådan kontrast: Men jag tror nog 10 - 20 s är vad jag hade det i):

• Intern hårddisk.
• Kopierade till den med en stor mängd fritt utrymme nyligen formaterad men ej kopierade i sekventiell ordning under min direkta kontroll utan katalogen med BDB-filerna via Nautilus. Samt därefter enstaka kompletterande en del saknat första QA-kontrollen upptäckte (koncept i perspektiv börjande på ex. "a" och ett blanksteg eller annan bokstav innan: En liten miss för att minna om att man bäst testar databaser man bygger upp).
• En databas minst för resp. bokstav och ibland fler. Jag har förr alltid gjort så därför att det tog så lång tid annars att bygga dem. Men läser man instruktioner, manualer m.m. noggrant tänker jag eller som jag surfade runt på frågor och svar runt det kan man lära som jag senare kom att göra att om man ställer in parametriseringen rätt så slipper man att BDB-stödet sitter och expanderar ut filen på slöaste tänkbara sätt för nära nog varje nytt koncept när man är över en viss storlek (en storlek man ställer in när den ska göra sådant och ex. kan dra upp till att täcka några tio tals miljoner nycklar eller vad man har minne och egen förändrad Linux till att orka med).
• Föregående har jag fått för mig när man bygger en stor fil ej ger någon förlust i prestanda. Emellertid eftersom jag nu i versionen innan hade just en stor fil valde jag att istället göra tvärtom.
• Filsystem XFS.
• Linux ändrat - resp. en del små-saker runt i XFS-lagret - till att ej försöka göra något smart i hur skrivningar hanteras.
• Viss uppföljning och skattning av vad jag tror / fått för mig är hårddisk-nära komprimering av något slag (förr användes run-length-kodning vilket jag kan tänka mig att det är nu också men har ej försökt bedöma det: Endast beräknat entropin över det) för att se att det konvergerar i rätt riktning när en del annat material kopierats in.
• Sortering där det är prestanda-gynnsamt rörande nycklar i access såväl självklart när databaserna byggs.
• Självklart ingenting på hårddisken som Linux resp. Perl-biblioteken har att göra med.

Men kanske kan man få god prestanda också med SQL, XML eller något sådant? Dock betvivlar jag på en dator med min hårdvara varande en fyra år nu.

Hade prestandan varit kvar som innan vilket jag tror är inte mycket bättre än vad en typisk SQL-databas eller NOSQL lösning (NOSQL rörande påkostade lösningar med allt färdigt i logik snarare än man som jag gör med BDB - argumenterat också en NOSQL givetvis - behöver göra det själv: Ej för många andra tillämpningar en rättvis jämförelse) av dom vanligaste ger hade det jag gjorde med dom när problemet uppträdde aldrig under min livstid blivit klart. Nu är det när testningen är klar inte vad som kommer ta mer än maximalt en timme.

Tiny och JSON

Json-stöd jag använder:

• JSON.pm | CPAN.org

JSON-stödet antar jag har någon form av teoretiskt och i kanske i kod-mängd elegant liten rekursiv eller non-state-medveten algoritm för att vandra i graf-minnesstrukturerna (hasch-tabellerna som ju går att göra som godtyckliga träd i Perl) görande det väldigt svårt att hantera defekter i strukturen eller själva logiken där med annat än exceptions (utan en massa extra kod görande kod-elegansen "gömd"). Annars föredrar jag ju själv viss medvetenhet i logiken därför att jag för att klara prestanda regelmässigt undviker allt konceptuellt ens i närheten av rekursion eller tillståndslösa "algoritmer konvergernade lösning via enkla principer" som därför också får värdet av mycket exakt information om var felet uppstår i strukturerna (görande det möjligt som typiskt för fel JSON om det skulle inträffa motsvarande vad jag kan få i stora grafstrukturer: Genom att en liten defekt i en liten subgraf kan skäras bort utan just någon förlust alls). Men i JSON-kodningen är det verkligen inte på den exaktheten information ges. Det är fel och koden klagar via exceptions och jag kan inte föreställa mig att något där som man inte bör ha märkt redan innan kontrollerande parametrarna föregripande anrop går att få ut om vad som egentligen är fel.

En del exceptions (flera) tycks när jag läser dokumentationen vara vad som "hjälper" folk att missbruka Perls notation och flexibilitet till att skriva ganska sunkig kod med en massa sammanblandningar av "pekare", "implicita typ-konverteringar" m.m. Jag skriver Perl så att man kan konvertera det nära nog 1 till 1 till C och om jag någonsin behövt skriva Bless någon gång eller låtit kod göra det implicit kommer jag ej ihåg det. Många andra har en annan förväntan av vilka värden de vill få ut av Perl och gillar detta. Jag använder Perl mer därför att det har en svårslagen mängd färdigt stöd som samlats genom alla år fritt tillgängligt inte minst inom text mining, natural language processing, statistik m.m.

"If $enable is true (or missing), then the encode method will not barf when it encounters a blessed reference. Instead, the value of the convert_blessed option will decide whether null (convert_blessed disabled or no TO_JSON method found) or a representation of the object (convert_blessed enabled and TO_JSON method found) is being encoded. Has no effect on decode.

If $enable is false (the default), then encode will throw an exception when it encounters a blessed object."

JSON stödet kan jag inte minnas att jag någonsin haft problem att få att koda mina grafer som hasch-tabeller eller att den haft problem att göra grafer av JSON jag tagit ner från databaser eller webb-servrar på internet. När de är korrekta (och en hel del strukturer egentligen inkorrekta vet jag att den klarar av att koda som vettigt förväntat). Tämligen stabil med andra ord. "Perl-anpassad-Perl-kod" kan vi kanske kalla det med den positiva bieffekten att sunking JSON-strukturer på internet med alla möjliga underligheter också blir vettiga :-)

Vilket stöd exceptions jag använder minns jag ej namnet på (jag tror det ligger i Tiny) och hittade ingenting självklart direkt på CPAN. Jag hanterar inte själv fel med exceptions så jag är föga engagerad annat än för att fånga dem bäddande in en del externa moduler av och till.

NoSQL med Rebel-AS: Berkeley DB prestanda optimerat i två kraftfullt enkla steg

Sammanfattat: 1. För-sortera (design pattern sort) stora chunk och 2. Stoppa in. Men glöm inte att stoppa in det sista datat.

Tidigare har jag haft stora problem Berkeley DB i att skapande av databaserna vid resp. 80 MB mängd databas gjord kom en stor tidskostnad. Längre ut kunde det i princip gå hur länge som helst. Av den orsaken hade jag tänkt ersätta det med något färdigt mer paketerat inkluderande mer av färdiga funktioner för dimensioner m.m. Men standardprodukter kommer ju med viss kostnad inlärning, legacy och för ex. MongoDB jag lutade åt att jag ogärna just nu vill installera om utvecklings-server från 32-bitar Ubuntu till 64-bitar (med 32-bitar är MongoDB ej meningsfull relativt vanliga hash-tabeller inlästa från fil därför att datat är väldigt litet).

Varför brytpunkt ligger där vet jag inte. Ev. är det just relaterat 32-bitars adressering i OS (jag har fått för mig att både den Berkeley DB jag använder, MongoDB m.m. alla normalt ej gör något mer underliggande eller långt ner i OS nära disk eller adressering utan använder ett färdigt anrop för stora filer att adressera likt minne i Linux). Det stämmer i alla fall ungefär i magnitud:

2³² (82 * 1024 * 1024) ~ 49.951

Men har alltid prövat det på samma filsystem (ej prövat det på mitt Ext3 - eller om det är Ext4 - jag prövar eller formaterat för att pröva i alla fall som tänkbart just för disk där NoSQL databaserna ska ligga längre fram: givet bl.a. ingen checksum m.m. passande för databaser där ej tänkt att ändras kontinuerligt och i behov av god prestanda relativt begränsad hårdvara - osäker om det gör praktiskt kommer göra märkbar skillnad eftersom jag egentligen aldrig varit i närheten av storleks-magnitud totalt data som kommer behöva hämtas kontinuerligt men anar att det kanske gör skillnad).

I Rebel-AS jag döpte en fortsatt egen legacy NoSQL jag byggt ovanpå just Berkeley DB har jag samma fördröjning som funktion av cirka 80 MB nedsläppt. Men nu mycket snabbt skapande av databasen. Ett natal GB med inlägg från bloggar och sociala media för fortsatt analys handlar om ett fåtal timmar eller kortare tid (satt ej och tog tid på det framför datorn).

Berkeley DB snabbt: Sätt dig ner och sortera nycklarna åt datan (likt programmera: människa gör det kostsamma - datan gör egentligen föga)

Och hela skillnaden i prestanda ligger i vad jag trots av och till utdragna - säg fyra timmar totalt - försök att hitta en förklaring och lösning ej hittade alls. Förutom mer av slump slutligen i en kort kommentar till en fråga svår-hittad både nu och tidigare (möjlig utgångspunkt: Berkeley DB Slow via sajt-sökning med Google).

I övrigt läsande på Stack overflow fick jag ut föga värde. De flesta verkar heller inte göra särskilt stora databaser. Exakt vad orsaken är eller varför det ev. är god vana vet jag inte. Databaser har aldrig särskilt intresserat mig och ingenting jag direkt önskar att lära något mer än nödvändigt om. Jag hade snarare föreställt mig att det logiska vore att om distans eller skillnad mellan nycklar som går in pre-expanderar man motsvarande fil mycket mer för att slippa flytta om datat senare alt. slippa hantera kollisioner via redundant för träffar nycklar eller pekare vidare till annan position.

Hans reflekterar vad han redan lärt och slutade lära cirka 2003 rörande databaser och tyckte sig inse att det räckte bra nog ändå: Datan gör ungefär samma fel varje år även om skärmen blivit skarpare och hårddisken större

Det är när jag spekulerar kreativt utåt bra att komma ihåg att min vetskap databaser snarare än hash-funktioner, kataloger (typ Open LDAP) eller för evigheter sedan fil-databaser via radnummer respektive:

LIST RANDNUMMER

på Commodore 64 någon gång i årskurs fyra när datorernas sanna små-defekta natur inte doldes lika smygande riskfyllt som idag: Ex. databas genom att lista "programkod" - lika gärna text eller annat data så länge man inte kör koden som BASIC II. Istället listade man programmet - eller en del av programmet där datat fanns men som ej kördes just för dom raderna. Ex. LIST 3210 - 40000. LIST liknar hemvant trevliga goto men var sundare strukturerat genom att utnyttja entydiga nummer istället för dom kvalitetsprobglematiska labels vi säkert alla gärna förfaller till likt abc, donxt, do_next en bit nedanför med svårbegriplig beräkning mellan förändrande värde, odd_erorr, debug_but_do_not_remove_it m.m.) syntax för att ta ut en datapost från dess början på rad enligt första numret till dess slut på den andra siffran - plus så klart för stora databaser behov av att ladda in grupper av poster från olika delar på kassetband utiliserande s.k. "spolning" / "att spola fram eller bak bandet§" - eller rent av krävande många kassetband) är så begränsad men dessa tre tillsammans gav mig en känsla av att jag sådant som Berkeley DB borde vara begripligt för mig. LIST är heller inte olikt hur många idag gör lookup från indikation vi vill fråga med (ex. URL eller sökord) till radnummer i enorm fil där själva datat för sökord eller URL ligger lagrat (och så klart snabbare i absolut-mening idag jämfört med C64 men inte mycket högre relativ prestanda).

Stora nycklar en aning mer kostnad ibland för-sortera men ev. högre prestanda skapande databas

Något besläktat - kanske relaterat implementation på vad - ges här också StackOverflow: BerkeleyDB - implications of incorrect sorting order? (via cache-Google: ibland når jag ej StackOverflow vilket jag trodde berodde på att jag råkat spindla deras kategorier hårdare än korrekt programmerat för statitistiskt analys av inlägg men ganska ofta fungerar den så ev. relaterat någon defekt på Stackoverflow kanske relaterat last så jag länkar indirekt istället och tror ej det tolkas av spindlande entiteter som problem prestanda eller tillförlitlighet med sajt länkad). Om det egentligen stämmer som skrivet ofta eller alls vet jag inte.

Vad jag märkt är emellertid att ingen kostnad för mig existerar av att använda större nycklear (undantaget ev. ökad risk för kollisioner och hantering av det: men jag vågar gissa att vettig hash-funktion används och om så troligt föga problem). Och längre nycklar om en mappning mellan nyckel och position (snarare än jag hade föreställt mig motsvarande MD5 - jag vill gissa att föregripande lookup-up till värden från nyckel finns och att hasching kanske ej görs till en redundans-reducerad form som för MD5) finns motsvarande "komplexiteten summerad" nyckel innebär det ju mer exakt vetskap om relativ positionering. D.v.s. kommer fler entiteter gå in och vi tar in dem i chunk vettigt urtagna innan sorterade föreställer jag mig att det kanske tvingar upp lite vettigare initial hantering föreberedande för att mycket kommer in. Jämför att sortera:

AAAAAB AABAAA br/> resp br/> AAAAAABAAAABBBBAAAA AAABAAABAAAABBBBAAAA Eller motsvarande mina nycklar datum och tid publicering, länk indikerad övergripande RSS eller ATOM "sajt", domän uttagen över inläggen för resp. länk till inlägg (d.v.s. kan vara annan än sajt), titel på sajt indikerad, titel inlägg, resp. hela sökväg feed där data hämtades (ej exakt i samma ordning mot mitten ev. samt inkluderande en till indikation om källa i URL-mening). Poängen längd ligger i att gå över alla nycklar utan hänsyn dimensioner för annan lookup för enklare förändringar, kontroller m.m. där allt nödvändigt för mycket finns direkt för varje nyckel (ex. för en del underhåll kontrollera om ett datum finns eller ex. som nyligen defekt-data ej önskat som läckte in: <![ eller liknande ibland förekommande i RSS-strömmar ev. för "sekundärt" data-relaterat innehåll (just här för sajt-länken för ganska många vilket missades vid skapandet).

I en värld där resp. två nycklar för de två grupperna egentligen motsvarar samma nycklar men där de första kommer ge fler kollisioner tvingande fram att append görs för resp. om plats finns, och när plats lokalt i filen där lagring redan skett saknas tvinga fram en pekare till nytt data allokerat på disken eller värre (ej kanske otroligt givet prestanda kostnaden jag fick tidigare) att data flyttas om ständigt görande att en ny växande jätte-fil behöver lagras gång på gång för varje 80 MB med exponentiellt växande tid för det eftersom komplexiteten att göra det ökar när resp. omflyttning kan inverka på nästa omflyttning. Om nu den Berkeley DB implementation jag fick via Perl (eller om den ligger ovanpå något i Linux) är riktigt dum kodad (elegansen i Berkeley DB är ju att det är enklaste tänkbara så mycket möjligt förväntas förståelse och ansvar hantering liggan ovanpå).

Tänkbart faktiskt en tids-kulturell-atavistisk företeelse. Berkeley DB har ju funnits så pass länge att problemen och utmaningarna när etablerad var mycket annorlunda: RAM-minne relativt litet (men kanske problem-baserat jämförbart) men förr var hårddiskar som nu inte mer eller mindre kostnadsfria om man inte behöver lägga på mer än några tera byte. Ev. lite default optimerad för att ej börja med att skapa en rimligt tilltagen fil (kanske konfigurerbart men jag såg det ej via Perl gränssnitt i DB FILE och utan att kontrollera konfigurations-loggar vet jag ej om jag installerade på något kompletterande).

Appendix A: Design pattern sortera nycklar i två enkla steg

Pre Berkeley DB power sorting:

1. Ta ut nycklar från mellan-lagring i Perl's vanliga hash-tabell. Exempel:

my @keys = keys %ldb

2. Sortera nycklarna. Exempel:

@keys = sort @keys;

Och stoppa in i Berkeley DB via lämpligt för det. Glöm inte att synkronisera mellan-lagrat data i sista steget. Vi antar att vi stoppar när överskridande viss storlek med målsättning att söka göra det med så stora chunk i taget som möjligt för att inte Berkeley DB ska allokera onödigt små-utrymmen i varje steg givet att om inte allt data redan är sorterat gäller att en del omflyttningar eller vad Berkeley DB nu gör behöva ske. För mig cirka 900 000 blogginlägg med RSS-meta översatt till trevlig CSV-fil (som vi i en rimlig värld hade haft direkt på webbsidan istället för SGML-rekursionens onödiga komplexitet praktiskt oavsett hur elegant språkteoretiskt). EFtersom blogginlägg kan komma från entiteter vid en tidpunkt efterföljande vad vi stoppar in idag okänd gäller att inlägg vi ska stoppa in ofta nog i perioder när tidskostnaden kan ha betydelse (d.v.s. spindlande ifatt internet där jag just nu ett tag expanderar antalet entiteter publicerande med cirka 50 000 till 100 000 per 24 - 36 timmar men räknar med att stoppa det om en eller ett par veckor) vara äldre och ej följande logisk ordning i övrigt samtidigt som jag tyckte det mindre tilltalande att försöka lägga till en bokstavsräknare initialt eftersom jag gärna vill kunna ta ut alla nycklar optimerat i meningsfull ordning att se ungefär var saker befinner sig i tiden vid underhåll o.s.v. via snabbtitt skärm.

Betryggande nog när vi står kvar på en robust gammal välkänd komonent är den välanvänd av andra gamla lösningar man känner igenom sedan snart 20 år. Ett fåtal från Wikipedias längre lista:

"MySQL database system – Prior to v5.1, MySQL included a BDB data storage backend.
OpenLDAP – A free/open source implementation of the Lightweight Directory Access Protocol (LDAP)
Postfix – A fast, secure, easy-to-administer MTA for Linux/Unix systems"

Även om det får erkännas att min lilla praktiska erfarenhet av MySQL och Postfix var en brutalt plågsamt fascinerande verklighet: Så slött saker kan bli med eller utan på det Apache resp. karttjänster ovanför. Men OpenLDAP är ju bra även om det var ett antal år sedan jag gjorde något med den. Och menar - det kan kanske diskuteras - Wikipedia dessutom något färskare news-fresh:

"Bitcoin - A distributed peer-to-peer open source digital currency."

Fortfarande lite små-coolt att skapa stabila stengolv med Berkeley DB hellre än något vulgärt IKEA-färdigt golv som limmas eller nitas. Riktiga värden som håller många år byggs med stenhacka och förståelse av problemen man vill lösa med att bygga golv.

Tidigare från samma domän av stegvis kreativt skapande för undvikka samma välkända strunt-problem i datan nu som på 1980-talet

Som Rebel-AS levererar sin lösning till:

1. Steg I: Behovet av praktisk big-data utan mina enkla ganska brutala ta in och ut ur minnet läsande data uppdelat i mindre filer resp. den gamla Berkeley DB lösningen där ingen databas praktiskt gick att ta större än 80 MB (d.v.s. samma problem praktiskt ungefär: många fil-accesser, opraktiskt att strukturera, och ordentligt med extra-logik i koden). Men eftersom vi är i domän av databaser blir det ändå segt eftersom jag varken kan eller vill lära mig teorin för dem. Varande så inarbetat sedan år borde det tycker man bara fungera.... Likt hash-funktionen i Perl.

• NoSQL och Sun's och övriga hårdvaru-inriktades problem att orka med dom teoretiska utmaningarna vi alla behövt sedan år (2013-09-02)

Plattform jag reflekterade som tänkbar lösning: Mongodb.org. Huvudsakligen därför att den av flera indikerades snabb och endast i föga läsande dokumentationen verkade ha "överdrivna databas" relaterade funktioner: enkel och begriplig närmare hash-funktioner jag ju redan tycker mig kunna. Mindre risk onyttig inlärning. Och startade smidigt dessutom. Men hade fodrat ny installation Ubuntu om praktiskt funktionell vilket just nu ett tag är opraktiskt på utvecklingsservern.

Och diverse små-tester, läsande m.m. resulterar slutligen i att jag väljer samma teknik-plattform som tidigare förutom att skärande cash-logiken för parallell också utan Berkeley DB (användes uteslutande för similarity beräkningar mellan koncept där cirka 900 MB - 2 GB förberäknade värden fanns mellan koncept vars similarity oftare var efterfrågade eller förväntades vara det: dessa tar annars upp till för värsta tänkbara om gjord med hög exakthet närmare 20 minuter - och för aktuell version Blue light gällande i denna lösning fanns cirka om jag minns rätt 10 miljoner relationer bedömda troliga över cirka 140 000 existerande koncept jämfört med nu några miljoner koncept och ett okänt antal relationer troliga att återkommande behöva ta ut likhet m.fl. operationer applicerade för inkl. nu att fler resp. större andelar av vikter använda ska beräknas kontinuerligt uppdaterade vilket expanderar upp data tvingat via cash än mer så att det kan göras u bulk ett par gånger pe rdag - hence att databas-problem blev löst trots databas-fobi).

• Riktad sampling Blogger för ökad tillförlitlighet (och pågående unikt problematiskt internet från min accesspunkt) (2014-04-21) (och Google: Feedburner, Youtube och Feedproxy.)
• Resultat spindling efter RSS- och ATOM-strömmar (2014-04-27)

Mycket typisk mänsklig problemlösning i den ena av två grova grupper kreativitet vi kan se. Här stegvis-förändring sökande behålla värde vi har (eller ofta nog slippa lära något nytt). Äldre mer erfarna kan prestera väl i företagsutveckling i denna domän. Vanligt i antal nya företag ovanför detta är konsultverksamhet byggande på upparbetad vetskap om en form av problemlösning eller förståelse av en verksamhet. Den andra domänen är innovation i emergence skapande något radikalt nytt.

Säger vi att emergence är kontextuellt beroende utifrån ett perspektiv - här jag om tvingad att behöva lära något externt system nytt för mig resp. behöva plåga mig med att sätta upp nya version Ubuntu och ett ganska komplext legacy-system liggande ovanpå: ny kunskap, nya komponenter adderade och inte otroligt nya värden svåra att förstå från Berkeley DB perspektivet - har vi ex. när en metod från ett annat expertområde inses optimera i ett annat eller när en upplevt ny upptäckt kommer (för vilka ofta gäller att olika individer oberoende i vad ytligt uppenbart gör samma upptäckt ungefär samtidigt i tiden d.v.s. latenta faktorer existerar). Tidigare diskuterat många gånger även nyligen i år Emergence relationer - Emergence demokrati (2014-04-21). Innovation via emergence är ibland oftare lättare för yngre: de kan ju föga från början och har inte lärt sig hur det ska gå till att hämta upp data lagret (kanske inte ens hört talas om X.500, LDAP eller MD5).

Lite som att redan förstå varför allt i datat alltid ställer till med små-problem och hur vi ungefär löser det. Relativt att söka en ny givet viss tid mellan inlärt problemen och nutid möjligt bättre lösning kanske genom att elt undvika problemen.

• Minimalistiskt sido-algoritm-skiss beräknande läsare nyhetsmedier (2014-04-30)
• Minimalistiskt sido-algoritm-skiss beräknande läsare nyhetsmedier II: Algoritm omvandlande tidskostnad referera nyhet till förtroende publicist (2014-04-30)
(Och mer kompletterande de sista snarare än just relaterat lösning i problem-domänen för mig varande vad inarbetade algoritmer med föga behov förändring finns för: arbetet här och relaterat har mer att göra med att ta saker större i antal koncept vi förstår och ser, mängden statistik relationer, antalet publicister hanterade, antalet "skrivande läsare" analyserade o.s.v. för vikter diskuterande rörande ungefär emotionell intensitet: Att välja mellan kontext och känsla vid betraktande av "minnen" (2014-04-20) i mening att göra referensen begriplig ungefär vad avsett).

Frågor: MediaWiki, Perl och PHP resp. datalayers för tillstånd utanför MediaWiki's egna lösningar

Svära gärna där eller här:

• MediaWiki extensions with Perl (through Apache?), PHP - Parallell state in Secret database layer | Stackoverflow

Mashing the Stackoverflows for fun and profit through information mining.

Berkeley DB i Perl

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.