39 votes

Une base de données clé-valeur fiable et efficace pour Linux ?

J'ai besoin d'une base de données clé-valeur rapide, fiable et efficace en termes de mémoire pour Linux. Mes clés font environ 128 octets, et la taille maximale de la valeur peut être de 128K ou 256K. Le sous-système de la base de données ne doit pas utiliser plus de 1 Mo de RAM environ. La taille totale de la base de données est de 20G ( !), mais seule une petite fraction aléatoire des données est accessible à la fois. Si nécessaire, je peux déplacer certains blocs de données hors de la base de données (vers des fichiers ordinaires), afin de réduire la taille à 2 Go maximum. La base de données doit survivre à un crash du système sans aucune perte de données récemment non modifiées. Il y aura environ 100 fois plus de lectures que d'écritures. C'est un plus si elle peut utiliser un périphérique bloc (sans système de fichiers) comme stockage. Je n'ai pas besoin de fonctionnalité client-serveur, juste d'une bibliothèque. J'ai besoin de liaisons Python (mais je peux les implémenter si elles ne sont pas disponibles).

Quelles solutions dois-je envisager, et laquelle recommandez-vous ?

Les candidats que je connais qui pourraient fonctionner :

  • Cabinet de Tokyo (Les liaisons Python sont pytc voir aussi code d'exemple pytc La taille du tableau de seaux est fixée au moment de la création de la base de données ; le rédacteur doit fermer le fichier pour donner une chance aux autres ; de nombreuses petites écritures avec réouverture du fichier pour chacune d'entre elles sont très lentes ; le serveur Tyrant peut aider avec les nombreuses petites écritures ; comparaison de la vitesse entre Tokyo Cabinet, Tokyo Tyrant et Berkeley DB )
  • VSDB (sûr même sur NFS, sans verrouillage ; qu'en est-il des barrières? ; les mises à jour sont très lentes, mais pas autant que dans cdb ; dernière version en 2003)
  • BerkeleyDB (fournit une récupération en cas de crash ; fournit des transactions ; le bsddb Le module Python fournit des liaisons)
  • TDB de Samba (avec les transactions et les liaisons Python, certains utilisateurs a connu la corruption parfois mmap() s l'ensemble du fichier, le repack double parfois la taille du fichier, produit des échecs mystérieux si la base de données est plus grande que 2G (même sur les systèmes 64-bit), l'implémentation de cluster ( CTDB ) également disponible ; le fichier devient trop gros après beaucoup de modifications ; le fichier devient trop lent après beaucoup de contention de hachage ; pas de moyen intégré pour reconstruire le fichier ; mises à jour parallèles très rapides en verrouillant les seaux de hachage individuels)
  • aodbm (append-only donc survit à un crash système, avec des liens Python)
  • hamsterdb (avec des liaisons Python)
  • Arbre C (solution commerciale mature, polyvalente et performante, dispose d'une édition gratuite aux fonctionnalités réduites)
  • l'ancien TDB (à partir de 2001)
  • masque binaire (log-structuré, écrit en Erlang)
  • diverses autres implémentations de DBM (telles que GDBM, NDBM, QDBM, SDBM de Perl ou Ruby ; elles ne disposent probablement pas d'un système de récupération en cas de panne).

Je ne les utiliserai pas :

  • MemcacheDB (client-serveur, utilise BereleleyDB comme backend)
  • cdb (doit régénérer toute la base de données à chaque écriture)
  • http://www.wildsparx.com/apbcdb/ (idem)
  • Redis (garde toute la base de données en mémoire)
  • SQLite (il devient très lent sans aspiration périodique, voir l'autocomplétion dans la barre d'emplacement dans Firefox 3.0, même si les versions 3.1 et ultérieures de sqlite autorisent auto_vacuum attention : les petites transactions d'écriture peuvent être très lentes ; attention : si un processus occupé effectue de nombreuses transactions, les autres processus sont affamés et ne peuvent jamais obtenir le verrou)
  • MongoDB (trop lourd, traite les valeurs comme des objets avec une structure interne)
  • Oiseau de feu (SGBDR basé sur SQL, trop lourd)

Pour info, un article récent sur les bases de données clés-valeurs dans le magazine Linux.

Pour info, un liste des anciens logiciels

Pour info, un Comparaison de la vitesse de MemcacheDB, Redis et Tokyo Cabinet Tyrant

Questions connexes sur StackOverflow :

1voto

tzot Points 32224

Une autre suggestion est TDB (qui fait partie du projet Samba). Je l'ai utilisé par le biais du tdb Cependant, je ne peux pas dire que j'ai testé sa fiabilité en cas de plantage ; les projets dans lesquels je l'ai utilisé n'avaient pas de telles exigences, et je ne peux pas trouver de documentation pertinente.

0voto

Nick Gorbikoff Points 3144

Que diriez-vous d'un SQLite ?

0voto

Wim Points 7248

J'ai utilisé bsddb.hashlib() avec Python, cela a plutôt bien fonctionné.

0voto

Jonathan Feinberg Points 24791

Vous pourriez aimer djb 's cdb qui possède les propriétés que vous mentionnez.

0voto

Andy Dent Points 9852

Sur ma requête pour une base de données multiplateforme de type ISAM (similaire), j'ai également reçu des suggestions pour la version embarquée de Oiseau de feu y GLib .

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X