Memorizzare un numero elevato di oggetti di dimensioni variabili sul disco

Question

Devo sviluppare un sistema per la memorizzazione di grandi numeri (da 10 a 100 di migliaia) di oggetti. Ogni oggetto è simile alla posta elettronica: è presente un corpo di testo principale e diversi campi di testo ausiliari di dimensioni limitate. Un corpo avrà una dimensione compresa tra pochi byte e diversi KB.

Ogni elemento avrà un singolo ID univoco (probabilmente un GUID) che lo identifica.

Il negozio verrà scritto solo quando un oggetto viene aggiunto ad esso. Sarà letto spesso. Le eliminazioni saranno rare. I dati sono quasi tutti testi leggibili dall'uomo, quindi saranno facilmente comprimibili.

Un sistema che mi consente di emettere gli I / O e di gestire la memoria e la memorizzazione nella cache sarebbe l'ideale.

Conserverò gli indici in memoria, usandoli per mappare gli indici sulla chiave singola (e primaria) per gli oggetti. Quando avrò la chiave, la caricherò dal disco o dalla cache.

Il sistema di gestione dei dati deve far parte della mia applicazione - Non voglio dipendere dai servizi del sistema operativo. O pacchetti installati separatamente. Il nativo (C ++) sarebbe il migliore, ma una cosa gestita (C #) sarebbe ok.

Credo che un database sia una scelta ovvia, ma deve essere superveloce per cercare e caricare nella memoria di un oggetto. Non ho esperienza con la tecnologia della base di dati e sono preoccupato che i sistemi relazionali generali non gestiranno tutti questi dati di dimensioni variabili in modo efficiente.

(Nota, questo non ha nulla a che fare con il mio lavoro - è un progetto personale.)

Nella tua esperienza, quali sono le alternative praticabili a un DB relazionale tradizionale? O un DB funzionerebbe bene per questo?

Answer 1

Guarda SQLite , ha collegamenti per molti linguaggi di programmazione e ambienti disponibili ed è, come il Berkeley DB , un database su disco senza la necessità di installare un motore di database.

Se aggiungi semplicemente gli indici giusti, le ricerche saranno molto veloci e poiché si tratta di un database basato su set, puoi comunque eseguire query in blocco e simili.

Answer 2

Proverei PFS: http://blog.sensenet.hu/post/2008/05/Portal-File-System- (PFS) -an-open-source-content-repository- per-Net.aspx

Peccato che tu sia su c / .Net, poiché Jackrabbit sarebbe stata una scelta perfetta.

Answer 3

Non indichi davvero come cercherai questi dati. Ho svolto un lavoro simile con alcune applicazioni di mining di testo in cui i dati principali sono archiviati in MySQL ma mantengo un indice di ricerca testuale in Ferret (il progetto è in Ruby) per trovare la riga appropriata nella tabella dei messaggi in base alla ricerca di parole chiave. Penso che questo approccio ibrido potrebbe funzionare anche per te. SQLServer e Lucene.Net potrebbero funzionare bene nell'ambiente C #. Sono sicuro che se ti guardi intorno puoi trovare soluzioni simili nello spazio C ++.

Non consiglio di utilizzare la ricerca full-text di SQL Server - Lucene e le sue derivazioni sembrano essere una scelta molto migliore.

Penso che avresti molta più fortuna con qualsiasi soluzione DB piuttosto che una soluzione basata su file. Quasi tutti i database moderni dovrebbero essere in grado di gestire i requisiti dei dati, almeno per quanto riguarda lo spazio. Costruire gli indici sul tuo campo di grandi dimensioni è una questione diversa ed è per questo che consiglierei un approccio di mining del testo se devi cercarlo.

Answer 4

Sembra proprio quello per cui Berkeley DB è stato progettato. Non l'ho usato, tuttavia.

Answer 5

Forse dovresti pensare a un WebDav-Server come Apache + mod-dav. Ciò memorizzerà il contenuto e i metadati sul disco. Per la ricerca è possibile posizionare un motore di ricerca esistente sopra questo server WebDav, ad es. Lucene.

In questo modo puoi mantenere il tuo sviluppo al minimo e iniziare con un potente gruppo di funzionalità.

Answer 6

Hai guardato db4o o Karvonite ?

Answer 7

Dai un'occhiata a Glimpse .