Piccolo datastore più veloce su Windows

Question

La mia app tiene traccia dello stato di circa 1000 oggetti. Tali oggetti vengono letti e scritti in un archivio persistente (serializzato) in nessun ordine particolare.

Al momento l'app utilizza il registro per memorizzare lo stato di ogni oggetto. Questo è carino perché:

• È semplice

• È molto veloce

• Lo stato di un singolo oggetto può essere letto / scritto senza la necessità di leggere un'entità più grande (come estrarre uno snippet da un file XML di grandi dimensioni)

• Esiste un editor decente (RegEdit) che consente di manipolare facilmente singoli elementi

Detto questo, mi chiedo se esiste un modo migliore. SQLite sembra una possibilità, ma non hai lo stesso livello di lettore multiplo / scrittore multiplo ottenuto con il registro e non esiste un modo semplice per modificare le voci esistenti.

Qualche suggerimento migliore? Un mucchio di file flat?

Answer 1

Se inizi a sperimentare SQLite, dovresti sapere che " out of the box " potrebbe non sembrare veloce come vorresti, ma può essere rapidamente reso molto più veloce applicando alcuni suggerimenti di ottimizzazione consolidati:

Ottimizzazione SQLite

A seconda della dimensione dei dati e della quantità di RAM disponibile, si otterrà uno dei migliori miglioramenti delle prestazioni impostando sqlite per utilizzare un database all-in-memory anziché scrivere su disco.

Per i database in memoria, passare NULL come argomento del nome file a sqlite3_open e assicurati che TEMP_STORE sia definito in modo appropriato

D'altra parte , se dici a sqlite di usare il disco rigido, otterrai un vantaggio simile al tuo attuale utilizzo di RegEdit per manipolare i dati del programma " al volo. "

Il modo in cui è possibile simulare l'attuale tecnica RegEdit con sqlite sarebbe utilizzare lo strumento da riga di comando sqlite per connettersi al database su disco. È possibile eseguire istruzioni UPDATE sui dati sql dalla riga di comando mentre il programma principale è in esecuzione (e / o mentre è in pausa in modalità di interruzione).

Answer 2

Se ciò che intendi per "lettore multiplo / scrittore multiplo" è che mantieni molti thread che scrivono nello store contemporaneamente, SQLite è thread-safe (puoi avere SELECT simultanei e le scritture simultanee sono gestite in modo trasparente). Consulta le [FAQ [1]] e grep per "threadsafe"

[1]: http://www.sqlite.org/faq.html/ FAQ

Answer 3

Dubito che qualsiasi persona sana di mente seguirà questa strada in questi giorni, tuttavia parte di ciò che descrivi potrebbe essere fatto con Window's Archiviazione strutturata / composta . Ne parlo solo perché mi stai chiedendo di Windows - e questo è / era un modo ufficiale di Windows per farlo.

Ecco come sono stati messi insieme i file DOC (ma non il nuovo formato DOCX). Da MSDN sembrerà davvero complicato, ma l'ho usato, non è l'API peggiore in Win32.

• è non semplice
• è veloce, indovino è più veloce del registro.
• Lo stato di un singolo oggetto può essere letto / scritto senza la necessità di leggere qualche entità più grande.
• Non esiste un editor decente, tuttavia ci sono alcune cose di base reali (VC ++ 6.0 aveva il "Visualizzatore DocFile" sotto Strumenti. (Sì, è quello che ha fatto quella cosa) Ho trovato un pochi altro online.
• Ottieni un file invece delle chiavi di registro.
• Ottieni qualche geek-cred di sviluppatori Windows di vecchia scuola.

Altri pensieri casuali: Penso che XML sia la strada da percorrere (nonostante il problema di accesso casuale). Diamine, i file INI potrebbero funzionare. Il registro ti offre una sicurezza molto precisa se ne hai bisogno: le persone sembrano dimenticarlo quando il reclamo che utilizza i file è migliore. Un DB incorporato sembra eccessivo se sto capendo cosa stai facendo.

Answer 4

È necessario mantenere gli oggetti su ogni evento di modifica o semplicemente in memoria e archiviarli allo spegnimento? In tal caso, caricali e serializzali alla fine, supponendo che la tua app venga eseguita a lungo (e non condividi tale stato con un altro programma), quindi in memoria sarà un vincitore.

Se hai strutture di dimensioni fisse, potresti prendere in considerazione l'utilizzo di un file mappato in memoria e allocare memoria da quello?

Answer 5

Se l'unica cosa che fai è serializzare / deserializzare singoli oggetti (nessuna query elaborata), utilizza un database btree, ad esempio Berkeley DB . È molto veloce nell'archiviazione e nel recupero di blocchi di dati per chiave (suppongo che i tuoi oggetti abbiano un ID che può essere usato come chiave) e l'accesso è supportato da più processi.