SQLite / Firebird embedded per i dati numerici

Question

Ho un esperimento in streaming fino a 1Mb/s di dati numerici che devono essere conservati per una successiva elaborazione.Sembra facile scrivere direttamente in un database o in un file CSV e mi avrebbe poi la possibilità di recuperare facilmente i sottoinsiemi o intervalli.

Ho esperienza di sqlite2 (quando aveva solo i campi di testo) e sembrava abbastanza molto veloce come materie prime per l'accesso al disco.Le opinioni sui migliori correnti di in-processo DBMS per questa applicazione?

Scusate, dovrebbe avere aggiunto questo è il C++ inizialmente su windows, ma il cross-platform è bello.Idealmente, il DB in formato di file binario dovrebbe essere cross-platform.

Answer 1

Se avete solo bisogno di leggere/scrivere i dati, senza alcun controllo o manipolazione effettuata nel database, quindi entrambi dovrebbero fare bene.Firebird database di file può essere copiato, come lungo come il sistema ha lo stesso endianess (es.non è possibile copiare i file tra sistemi con processori Intel e PPC, ma Intel-Intel va bene).

Tuttavia, se avete bisogno di fare qualcosa con i dati, che è al di là della semplice lettura/scrittura, quindi vai con Firebird, in quanto è una versione completa di SQL server con tutti i 'enterprise' caratteristiche come trigger, viste, stored procedure, tabelle temporanee, etc.

BTW, se si decide di dare Firebird una prova, vi consiglio vivamente di usare IBPP libreria per l'accesso.Si tratta di un molto sottile wrapper C++ intorno Firebird C API.Io ha circa 10 classi che incapsulano tutto ed è morto facile da usare.

Answer 2

Se tutti si desidera fare è memorizzare i numeri e di essere in grado di facilmente le query di gamma, si può semplicemente prendere qualsiasi standard albero struttura di dati che si hanno a disposizione in STL e registrarlo su disco.Questo può mordere in un ambiente cross-platform, soprattutto se si sta cercando di andare croce-architettura.

Quanto più flessibili/persone-friendly soluzioni, sqlite3 è ampiamente utilizzato, solido, stabile,molto bello tutto intorno.

BerkeleyDB ha un certo numero di buone caratteristiche per cui uno dovrebbe utilizzare, ma nessuno di loro si applica in questo scenario, imho.

Io direi di andare con sqlite3 se si può accettare il contratto di licenza.

-D

Answer 3

Dipende da che lingua che si sta utilizzando.Se si tratta di C/C++, TCL, o PHP, SQLite è ancora tra i migliori del singolo scrittore scenario.Se non avete bisogno di accesso a SQL, berkeley DB-libreria di stili potrebbe essere leggermente più veloce, come Sleepycat o gdbm.Con più scrittori che si potrebbe prendere in considerazione un separato soluzione client/server, ma non suona come avete bisogno.Se si utilizza Java, hdqldb o derby (fornito con il JVM di Sun sotto il "JavaDB" branding) sembrano essere le soluzioni di scelta.

Answer 4

Si potrebbe anche voler prendere in considerazione una numerico formato di file di dati che è specificamente orientata verso l'archiviazione di questi tipi di grandi insiemi di dati.Per esempio:

• HDF -- il più comune e ben supportato in molte lingue, con librerie libero.Consiglio vivamente questo.
• CDF -- un formato simile a quello utilizzato dalla NASA (ma utilizzabile da chiunque).
• NetCDF -- un altro formato simile (l'ultima versione è in realtà un stripped-down HDF5).

Questo link ha qualche info sulle differenze tra i tipi di set di dati di cui sopra:http://nssdc.gsfc.nasa.gov/cdf/html/FAQ.html

Answer 5

Ho il sospetto che nessuno di database consente di scrivere dati ad alta velocità.Si può controllare voi stessi per essere sicuri.Nella mia esperienza - SQLite non è riuscito a INSERIRE più di 1000 righe al secondo, per una semplice tabella con una sola integer primary key.

In caso di un problema di prestazioni - vorrei utilizzare il formato CSV per scrivere il file, e poi vorrei caricare i dati nel database (SQLite o Firebird) per l'ulteriore elaborazione.