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

Question

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 :

• Base de données de valeurs de clés pour Windows ?
• Existe-t-il un cloud store / base de données Key=>Value éprouvé par les entreprises ? (Open Source)

Answer 1

LMDB est la base de données la plus efficace en termes de mémoire. http://symas.com/mdb/inmem/

et s'est également avéré être le plus fiable - complètement à l'épreuve des accidents. http://wisdom.cs.wisc.edu/workshops/spring-14/talks/Thanu.pdf

Parmi ceux que vous avez mentionnés, le Cabinet de Tokyo a des problèmes de corruption documentés. https://www.google.com/search?q=cfengine+tokyo+cabinet+corruption

BerkeleyDB a également des problèmes de corruption bien documentés, tout comme Bitcask. (Et Bitcask est de toute façon une BD en mémoire uniquement, donc inutile pour votre exigence de 1 Mo de RAM).

LMDB est également bien supportée en Python, avec plusieurs liaisons différentes disponibles. https://github.com/dw/py-lmdb/ https://github.com/tspurway/pymdb-lightning

Avertissement - Je suis l'auteur de LMDB. Mais ce sont des faits documentés : LMDB est le magasin de clés/valeurs le plus petit, le plus efficace et le plus fiable au monde et rien d'autre ne s'en approche.

Answer 2

J'ai eu de la chance avec la solution Tokyo Cabinet/pytc. Elle est très rapide (un peu plus rapide que l'utilisation du module shelve utilisant anydbm dans mon implémentation), tant en lecture qu'en écriture (bien que je fasse aussi beaucoup plus de lecture). Le problème pour moi était la documentation spartiate sur les liaisons python, mais il y a suffisamment d'exemples de code pour comprendre comment faire ce que vous devez faire. De plus, tokyo cabinet est assez facile à installer (tout comme les liaisons python), ne nécessite pas de serveur (comme vous le mentionnez). et semble être activement soutenu (stable mais plus en développement actif). Vous pouvez ouvrir les fichiers en mode lecture seule, permettant un accès simultané, ou en mode lecture/écriture, empêchant les autres processus d'accéder à la base de données.

J'ai examiné différentes options au cours de l'été et le conseil que j'ai reçu à l'époque était le suivant : essayez les différentes options et voyez ce qui vous convient le mieux. Ce serait bien s'il y avait simplement une "meilleure" option, mais chacun recherche des caractéristiques légèrement différentes et est prêt à faire des compromis différents. Vous êtes le mieux placé pour le savoir.

(Ceci dit, il serait utile aux autres si vous partagiez ce qui a fini par fonctionner le mieux pour vous, et pourquoi vous avez choisi cette solution plutôt que d'autres !)

Answer 3

Riak fonctionne sous Linux, et vous permet d'ajouter dynamiquement des nœuds

Answer 4

Cdb peut gérer n'importe quelle base de données jusqu'à 4 Go, ce qui le rend trop petit pour l'affaire en cours de 20 Go.

Answer 5

Que pensez-vous de dbm.ndbm de Python 3.0 ?