SQLite/Firebird integrado para datos numéricos

Question

Tengo un experimento que transmite 1 Mb/s de datos numéricos que deben almacenarse para su posterior procesamiento.Parece tan fácil escribir directamente en una base de datos como en un archivo CSV y luego tendría la capacidad de recuperar fácilmente subconjuntos o rangos.

Tengo experiencia con sqlite2 (cuando solo tenía campos de texto) y parecía casi tan rápido como el acceso al disco sin formato.¿Alguna opinión sobre el mejor DBMS en proceso actual para esta aplicación?

Lo siento, debería haber agregado esto en C++ inicialmente en Windows, pero la plataforma cruzada es buena.Idealmente, el formato del archivo binario DB debería ser multiplataforma.

Answer 1

Si solo necesita leer/escribir los datos, sin realizar ninguna verificación o manipulación en la base de datos, entonces ambos deberían hacerlo bien.El archivo de base de datos de Firebird se puede copiar, siempre y cuando el sistema tenga la misma endianidad (es decir,no se puede copiar el archivo entre sistemas con procesadores Intel y PPC, pero Intel-Intel está bien).

Sin embargo, si alguna vez necesita hacer algo con datos, que va más allá de la simple lectura/escritura, entonces elija Firebird, ya que es un servidor SQL completo con todas las características "empresariales" como activadores, vistas, procedimientos almacenados, tablas temporales, etc.

Por cierto, si decides probar Firebird, te recomiendo que utilices la biblioteca IBPP para acceder a él.Es un contenedor C++ muy delgado para la API C de Firebird.Tengo alrededor de 10 clases que resumen todo y es muy fácil de usar.

Answer 2

Si todo lo que desea hacer es almacenar los números y poder realizar consultas de rango fácilmente, puede tomar cualquier estructura de datos de árbol estándar que tenga disponible en STL y serializarla en el disco.Esto puede afectarle en un entorno multiplataforma, especialmente si está intentando utilizar varias arquitecturas.

En cuanto a soluciones más flexibles y amigables para las personas, sqlite3 es ampliamente utilizado, sólido, estable y muy agradable en todos lados.

BerkeleyDB tiene una serie de buenas características para las cuales uno lo usaría, pero ninguna de ellas se aplica en este escenario, en mi humilde opinión.

Yo diría que opte por sqlite3 si puede aceptar el acuerdo de licencia.

-D

Answer 3

Depende del idioma que estés usando.Si se trata de C/C++, TCL o PHP, SQLite sigue estando entre los mejores en el escenario de un solo escritor.Si no necesita acceso a SQL, una biblioteca estilo DB de Berkeley puede ser un poco más rápida, como Sleepycat o gdbm.Con varios escritores, podría considerar una solución cliente/servidor separada, pero no parece que la necesite.Si está utilizando Java, hdqldb o derby (incluido con la JVM de Sun bajo la marca "JavaDB") parecen ser las soluciones preferidas.

Answer 4

También es posible que desees considerar un formato de archivo de datos numéricos que esté específicamente diseñado para almacenar este tipo de conjuntos de datos de gran tamaño.Por ejemplo:

• HDF -- el más común y bien soportado en muchos idiomas con bibliotecas gratuitas.Recomiendo esto altamente.
• CDF -- un formato similar utilizado por la NASA (pero utilizable por cualquiera).
• NetCDF -- otro formato similar (la última versión es en realidad un HDF5 simplificado).

Este enlace tiene información sobre las diferencias entre los tipos de conjuntos de datos anteriores:http://nssdc.gsfc.nasa.gov/cdf/html/FAQ.html

Answer 5

Sospecho que ninguna de las bases de datos te permitirá escribir datos a tan alta velocidad.Puedes comprobarlo tú mismo para estar seguro.En mi experiencia, SQLite no pudo INSERTAR más de 1000 filas por segundo para una tabla muy simple con una única clave primaria entera.

En caso de un problema de rendimiento, usaría el formato CSV para escribir los archivos y luego cargaría sus datos en la base de datos (SQLite o Firebird) para su posterior procesamiento.