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

2014-04-30

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:


232 (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:
    2. my @keys = keys %ldb
  2. Sortera nycklarna. Exempel:
    3. @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.



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).



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.


kl. 4/30/2014 02:39:00 em
. . , , , , , , ,