Mycket tilltalande att se att konceptet av hash-tabeller jag alltid använt vid sidan om kataloger växt till NoSQL med starka lösningar. MonggoDb känns som det starkare alternativet för mig och vad jag tänker pröva när jag kastar ut en del enkla ad-hoc-lösningar (inte minst för att ge bättre administration såväl som bättre prestanda).
Av allt att döma redan utvecklad med brett stöd för enterprise indikerar att den troligt lever kvar utvecklande framåt. Flera större entiteter som använder den såväl som många mindre indikerar det samma såväl som värden. Bland dessa ex. New York Times, SourceForge och eBay (fler exempel: MongoDB - Production deployments | Wikipedia).
Tidigare prövade jag en lösning för att fil-databas som fungerande tillräckligt och acceptabelt när filerna är byggda. Men oerhört långsam att skapa (användande färdiga api:er snarare än att skriva filen åt det). Kom ganska snart någonstans vid säg 60 till 80 MB. orsaken känner jag ej men den var konfigurerad som hash-tabeller så ev. något där (möjligen relaterat att jag dumt nog byggde min Linux till utvecklingsdatorn 32-bitar. Och relaterat MongoDB och 32-bitar noterar vi Criticisms). Men egentligen helt orimligt slött från allt jag lärt om hash-tabeller resp. indexad access hoppande i filer genom åren. En ganska snabb variant jag gjorde för många år sedan för att slå upp om jag kommer ihåg rätt hash-värden från MD5 var med en för-4enklad variant av MD5 med reducerad säkerhet givetvis men istället för snabbare och hade få kollisioner (över en större mängd hash av MD5 givetvis relativt MD5 märkbart men här var mängden relativt liten och knappt någon alls).
Och också om den kostnaden ev. finns här tror jag knappast den är väsentligt större med klient på samma dator och där kan man lika gärna givet en så väsentlig kostnad se till att få fullt stöd i övrigt för allt som kan underlätta resp. behövas för framtida anpassningar eller utvecklingar.
Mer MongoDB:
Perl client-driver: metacpan.org/pod/MongoDB.
