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: <














