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.

XFS: Ett problem i prestanda tänkbart orsakat av XFS

Det här kan bero av annat än just filsystemet XFS (men bättre sammanfattning av vad XFS är i Wikipedia). Även möjligen orsakad relaterat Linux stacken har utrymme för optimering av access till minne resp. kopiering av filer disk och mellan fysiskt olika diskar tvivlar jag på det.

• Disken har en mängd filer lagrade alla av samma syfte men varierande stora.
• De är ofta lagrade så att om vi sorterar dem efter filnamn (givet någon storlek eller blandat i storlek) kommer vi ha nästa fil i listan närmare föregående fil än typiskt någon av de senare filerna.

Lägger jag nu trådar som läser filer som filtrerar efter storlek på filerna i en mängd filnamn (första bokstaven alltid här) och har en mycket stor i antal filer och mycket låg i storlek (ex. 8 - 32 byte) medan denna konkurrerar kortare lista av utvalda filer större så kan de senare hamna i mycket märkbar periodvis starvation utan någon access till disken. Också att vi skriver "väldigt hårt" mot disken utan särskilt mycket i logiken eller OS i övrigt som bromsar.

Av och till när arbete gjorts för att kraftigt uttrycka detta med långa perioder av starvation hamnar tråden eller de två trådar som kraftigt läst i antar jag påtvingad tystnad utan att göra något alls för att antar jag ge annat möjlighet att komma åt disken. Men inte oftare än att beteendet kraftigt kan störa normal upplevelse av disken.

Jag tror att orsaken är att stödet till XFS tittar var det i disken som läser och skriver befinner sig och när den kan välja tenderar till att belö vad som kan befinna sig närmare det.

Det var (och är kanske fortfarande att visa sig igen) väldigt irriterande eftersom jag med ett ganska litet antal trådar behöver vänta på disken för att göra icke-relaterat arbete. Jag har inte alls van vid det här problemet med så få trådar som ett par tre stycken (jag kom fram till att för fil-listor att gå igenom enligt tidigare med åtminstone någon över några hundra tusen åtminstone är två trådar åtminstone inte sämre än fler trådar och troligen bättre medan frågan om det är bättre eller sämre än en lista mer bestäms av att personligt periodvist engagemang med två trådar blir väsentligt mer sällsynt och inkluderar tid där det naturligt faller ner till en tråd).

Men som sagt andra orsaker till det här kan finnas. Erfarenhet av själva hårdvarulösningen ger att den ibland när man gjort om filsystemet arbetar på sämre prestanda rörande en del en period (men jag minns inte om jag tidigare sett något liknande som detta: snarare tror jag konkret sämre mängd data per sekund vid tydligast kopiering av filer).

Jag kan tänka mig att det här är någon algoritm i XFS. Dels därför att jag kan se hur det vid annat arbete (och kanske detta tror jag också) kan förbättra prestanda. Samtidigt att antalet fall "arbets-profil" man tagit hänsyn är ganska begränsat vilket är vad jag sett för en del andra filsystem på Linux (inte minst NTFS varför jag ganska nyligen bestämt att inte ha några diskar alls med NTFS). D.v.s. bredare fall att hantera lämnande från Linux-samhällets-framtid och i det följande en mer långsam tid än områden kanske roligare och/eller mindre kompetenskrävande och/eller fodrande mindre insats i att lära sig tämligen komplex kod befintlig.

Men jag har väldigt vaga begrepp om hur man optimerar diskar nära hårdvaran. Jag tyckte dock att det här kanske kunde vara en förklaring av det som jag kunde föreställa mig är vad man laborerar med. Det är ju utan just någon kunskap alls om hårddiskar fungerar fysiskt ungefär vad jag kan föreställa mig att man kan optimera: Ett tänkt don (vem vet kanske finns det många sådana: Ingen aning) som rör sig över det som kallas disk och läser eller skriver med en kostnad beroende av hur långt den måste flytta sig mellan skrivningar.

Praktiskt har jag fått en naturlig lösning av det hela med var arbetet ligger från att resp. lista filer som arbetas sorteras är mycket mer varierat i storlek. D.v.s. viss motsvarande fragmentering ges samtidigt som att inte samma enorma antal filer öppnas och stängs per byte. Att det senare kan tänkas spela in ger antar jag en indikation om vad resp. prediktion påverkas av: Position från föregående fil vi befinner oss på snarare än någon statistisk centralitet från en grupp (eller åtminstone en ganska liten grupp: Lätt att ta fel när man läser sorterat för filer som ligger "bra lagrade" på disken).

Hade jag större hårdvarulösningar lagring kanske jag hade övervägt att försöka hitta eller göra en lösning där man enkelt kan koda eller konfigurera hur optimering sker (om vi antar optimering som tänkt här faktiskt är hur det sker med mätbart resultat) utifrån typen av filer som lagrade och hur arbetet ska ske. Det är ju trots allt när mycket data som här ganska tidsödande totalt så en del annars kanske ganska små skillnader lär väl kunna summera en he del tänker jag: Kanske rent av många dagar totalt. Men nu arbetar jag inte riktigt med hårdvaruplattformar för lagring där jag tror det har förutsättningar att vara värt besväret i att lära sig mjukvarustöd eller värre problemområdet för egen kod. Här kan jag se att andra typer av prediktioner kanske fungerar bättre i såväl prestanda som risk för att irritera mig när jag gör klart konfigurationen inför nästa tråd som ska startas.

PS

Förövrigt rörande:

"Linux kernel's support for XFS was originally available through patches from SGI. It was merged into the Linux kernel mainline for the 2.6 series, and separately merged in February 2004 into the 2.4 series in version 2.4.25,[4] making XFS almost universally available on Linux systems.[5] Gentoo Linux was the first Linux distribution to introduce an option for XFS to be used as the default filesystem in mid-2002.[6] Installation programs for the Arch, Debian, Fedora, openSUSE, Kate OS, Mandriva, Slackware, Ubuntu, VectorLinux and Zenwalk Linux distributions all offer XFS as a choice of filesystem, but few of these let the user create XFS for the /boot filesystems due to deficiencies and unpredictable behavior in GRUB, generally the default bootloader.[7]"

Från: XFS | Wikipedia

Bootar jag tre Linux-distributioner från USB-disk formaterad XFS med GRUB. Arch även om jag har den installerad som köpt på en nätdisk från Sygate har jag dock inte bootat från XFS (om det nu inte är vad den kör som köpt).

Linux: Ett enkelt abstrakt filsystem

Jag har full förståelse av att precis vad jag tänker mig att någon eller några borde komplettera Linux med som default långt ner finns för åtminstone bakåt i tiden mer påkostade lösningar (men idag säkert allt oftare i hemmen också). Men situationen är ju ändå att man har ett antal partitioner, diskar adderade m.m. introducerande kostnad i tid och slitage för att passa samman det hela när utrymme tenderar att gå scarce där den primära lösningen inte känns som ett helt nytt lagringssystem åtminstone mer omedelbart.

Samtidigt så länge man nöjer sig med att varje fil i sin helhet ligger på en partition eller rent av fysisk disk förstår jag inte varför ett enkelt abstrakt filsystem ovanpå allt i övrigt utan särskild inläsning, kunskap, annan kostnad associerad mig o.s.v. kunde införas (i mening utan att jag behöver göra det själv).

Och gärna störande om hela konceptet boot sektorer med något mer legacy mellan befintligt och OS då jag är upparbetat ganska skeptisk till en ev. mängd problem lite varstans i världen som funktion av hur väl de tas upp av normalt befintliga säkerhetslösningar eller förväntade problem. D.v.s. på flyttbara diskar förväntar sig folk vanligen inga problem så länge de ex. har lite bilder m.fl. filer man inte kör medan diskarna är allt oftare mer eller mindre små enkla datorer med saker som auto-startas vid mount eller för den delen mer uppenbart när hela datorn bootas upp.

Nu är jag inte 100% säker på hur allt kring open source projekt fungerar men antar att vem som helst kan ta en beställar-roll för att åtminstone som här mindre uttrycka just en färdig kravspecifikation och istället mer vad jag behöver för att förenkla min verksamhet nära hårddiskarna. Så kan sedan andra självorganisera tankarna vidare vad dom kan bättre än jag kan mina behov relaterat filsystem. Något av skönheten med hela konceptet. Vi skapar något tillsammans där man efter gjort sin del kan betrakta skapelsen av något större när andra gör sitt.

Känner jag kompetensen kring sådant här finns nog en fin och stabil lösning klar att ta ner om ett par månader lagom till det kanske inte otroligt blir dags till mer nöd-tvingad om-organisation av filer. Annars skulle det inte vara mycket alls med kunnandet om något relaterat detta. Mitt förtroende för självorganisationen av värde för mig och övriga världen är gott.