SQLite / Firebird intégré pour les données numériques

Question

J'ai une expérience qui diffuse 1 Mo / s de données numériques et doit être stockée pour un traitement ultérieur. Il semble aussi facile d'écrire directement dans une base de données que dans un fichier CSV et j'aurais alors la possibilité de récupérer facilement des sous-ensembles ou des plages.

J'ai une expérience de sqlite2 (quand il n’avait que des champs de texte) et cela me paraissait à peu près aussi rapide que l’accès au disque brut. Des opinions sur le meilleur SGBD en cours de processus pour cette application?

Désolé, j'aurais dû ajouter que c'est C ++ initialement sur Windows, mais il est agréable d'utiliser plusieurs plates-formes. Idéalement, le format de fichier binaire de la base de données devrait être multiplate-forme.

Answer 1

Si vous avez seulement besoin de lire / écrire les données, sans aucune vérification ni manipulation dans la base de données, alors les deux devraient fonctionner correctement. Le fichier de base de données de Firebird peut être copié, à condition que le système ait la même finalité (c'est-à-dire que vous ne pouvez pas copier le fichier entre des systèmes dotés de processeurs Intel et PPC, mais Intel-Intel va bien).

Toutefois, si vous devez faire quoi que ce soit avec des données, qui vont au-delà de la simple lecture / écriture, utilisez alors Firebird, car il s’agit d’un serveur SQL complet avec toutes les fonctionnalités «entreprise» telles que les déclencheurs, les vues, les procédures stockées, etc. tables temporaires, etc.

BTW, si vous décidez d’essayer Firebird, je vous recommande vivement d’utiliser la bibliothèque IBPP pour y accéder. C'est un très mince wrapper C ++ autour de l'API C de Firebird. J'ai environ 10 classes qui encapsulent tout et c'est extrêmement facile à utiliser.

Answer 2

Si vous souhaitez simplement stocker les numéros et pouvoir facilement classer les requêtes, vous pouvez simplement prendre n'importe quelle structure de données arborescente standard disponible dans STL et la sérialiser sur disque. Cela peut vous piquer dans un environnement multiplate-forme, surtout si vous essayez de passer à une architecture croisée.

En ce qui concerne les solutions plus flexibles / conviviales, sqlite3 est largement utilisé, solide, stable, très agréable tout autour.

BerkeleyDB possède un certain nombre de fonctionnalités intéressantes pour lesquelles on pourrait l’utiliser, mais aucune d’entre elles ne s’applique dans ce scénario, à mon humble avis.

Je dirais aller avec sqlite3 si vous pouvez accepter le contrat de licence.

-D

Answer 3

Dépend de la langue que vous utilisez. Si c'est C / C ++, TCL ou PHP, SQLite est toujours parmi les meilleurs dans le scénario à un seul auteur. Si vous n'avez pas besoin d'un accès SQL, une bibliothèque de style base de données berkeley peut être légèrement plus rapide, comme Sleepycat ou gdbm. Avec plusieurs rédacteurs, vous pouvez envisager une solution client / serveur distincte, mais cela ne semble pas en avoir besoin. Si vous utilisez Java, hdqldb ou derby (fourni avec la machine virtuelle Java de Sun sous la marque "JavaDB") semble être la solution de choix.

Answer 4

Vous pouvez également envisager un format de fichier de données numérique spécialement conçu pour stocker ces types de grands ensembles de données. Par exemple:

• HDF - le plus courant et bien pris en charge dans de nombreuses langues avec des bibliothèques gratuites. Je le recommande vivement.
• CDF - un format similaire utilisé par la NASA (mais utilisable par quiconque).
• NetCDF - un autre format similaire (la dernière version est en réalité un HDF5 simplifié) .

Ce lien contient des informations sur les différences entre les types de fichiers ci-dessus: http://nssdc.gsfc.nasa.gov/cdf/html/FAQ.html

Answer 5

Je pense qu'aucune des bases de données ne vous permettra d'écrire des données à une vitesse aussi rapide. Vous pouvez vérifier vous-même pour être sûr. D'après mon expérience, SQLite n'a pas réussi à INSÉRER plus de 1000 lignes par seconde pour une table très simple avec une clé primaire entière.

En cas de problème de performances, j’utiliserais le format CSV pour écrire les fichiers, puis chargerais leurs données dans la base de données (SQLite ou Firebird) pour un traitement ultérieur.