Fiable et efficace, clé-valeur de la base de données pour Linux?[fermé]

Question

J'ai besoin d'un moyen rapide, fiable et efficace de la mémoire clé-valeur de la base de données pour Linux.Mes clés sont environ 128 octets, et la valeur maximale, la taille peut être 128K ou 256K.La base de données sous-système ne devriez pas utiliser plus que d'environ 1 MO de RAM.Le total 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 me déplacer certaines données blob dans la base de données (pour des fichiers normaux), de sorte que la taille descend à 2 GO maximum.La base de données doit survivre à un crash du système, sans aucune perte de récemment non modifiée de données.Je vais avoir environ 100 fois plus de lectures que de l'écrit.C'est un plus si on peut utiliser un périphérique bloc (sans un système de fichiers) comme espace de stockage.Je n'ai pas besoin client-serveur fonctionnalité, juste une bibliothèque.J'ai besoin de liaisons Python (mais je peux les mettre en œuvre si elles ne sont pas disponibles).

Les solutions qui dois-je considérer, et que l'on ne vous recommander?

Les candidats je sais de qui pourrait fonctionner:

• Tokyo Cabinet (Bindings Python sont pytc, voir aussi pytc exemple de code, prend en charge les hachages et B+, les arbres, les fichiers du journal des transactions et de plus, la taille de la benne tableau est fixe à la création de la base de temps;l'écrivain doit fermer le fichier pour donner aux autres une chance;beaucoup de petites écrit avec la réouverture du fichier pour chacun d'entre eux sont très lents;le Tyran serveur peut aider avec les lots de petites écrit; comparaison de la vitesse entre Tokyo Cabinet de, Tokyo Tyran et Berkeley DB)
• VSDB (sécurité, même sur NFS, sans verrouillage;quels obstacles?;les mises à jour sont très lents, mais pas aussi lent que dans la cdb;la dernière version de 2003)
• BerkeleyDB (fournit la récupération de l'incident;fournit des transactions;l' bsddb Module Python fournit les liaisons)
• Samba du TDB (avec les transactions et les bindings Python, certains utilisateurs connu la corruption, parfois mmap()s, l'ensemble du fichier, la repack opération double parfois la taille du fichier, produit des échecs mystérieux si la base de données de plus de 2G (même sur les systèmes 64 bits), cluster de mise en œuvre (CTDB) également disponible;fichier devient trop importante, après de nombreuses modifications;fichier devient trop lent, après beaucoup de hachage de contention;aucun moyen intégré pour reconstruire le fichier;très vite en parallèle des mises à jour de verrouillage de chaque hachage seaux)
• aodbm (append-only donc survit à un crash du système, avec des bindings Python)
• hamsterdb (avec des bindings Python)
• C-arbre (matures, polyvalent solution commerciale avec la haute performance, a une version gratuite avec des fonctionnalités réduites)
• le vieux TDB (à partir de 2001)
• bitcask (journal structuré, écrit en Erlang)
• divers autres DBM implémentations (comme GDBM, NDBM, QDBM,, Perl est choisi parmi sdbm ou de Rubis;probablement qu'ils n'ont pas la bonne récupération de l'incident)

Je ne vais pas utiliser ces:

• MemcacheDB (client-serveur, utilise BereleleyDB comme un backend)
• cdb (doit régénérer l'ensemble de la base de données lors de chaque écriture)
• http://www.wildsparx.com/apbcdb/ (idem)
• Redis (maintient l'ensemble de la base de données en mémoire)
• SQLite (il devient très lent sans effectuer de passer l'aspirateur, voir saisie semi-automatique dans la barre d'adresse de Firefox 3.0, même si les versions 3.1 et plus tard de sqlite permettre auto_vacuuming;méfiez-vous:petit écrit de transactions peuvent être très lente;méfiez-vous:si un occupé le processus est en train de faire de nombreuses transactions, d'autres processus de faim, et ils ne peuvent jamais obtenir la serrure)
• MongoDB (trop lourd le poids, la traite des valeurs comme des objets, avec structure interne)
• Firebird (SQL SGBD, trop lourd)

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

Pour info, un la liste des logiciels les plus âgés

Pour info, un comparaison de la vitesse de MemcacheDB, Redis et Tokyo Cabinet Tyran

Questions sur StackOverflow:

• Valeur De La Clé De Base De Données Pour Windows?
• Est-il un business cloud éprouvée store / Clé=>Valeur de la Base de données?(Open Source)

Answer 1

J'ai eu de la chance avec le Tokyo Armoire/pytc solution.Il est très rapide (un peu plus rapide que d'utiliser l'étagère module à l'aide de anydbm dans ma mise en œuvre), à la fois pour la lecture et l'écriture (même si je fais beaucoup plus de lecture).Le problème pour moi était le dépouillement de la documentation sur les liaisons python, mais il y a assez d'exemples de code autour de la figure comment faire ce que vous devez faire.En outre, tokyo cabinet est très facile à installer (comme le sont les bindings python), n'a pas besoin d'un serveur (comme vous le mentionnez) et semble être activement soutenu (stable, mais n'est plus en cours de développement).Vous pouvez ouvrir les fichiers en mode lecture seule, permettant l'accès simultané, ou en mode lecture/écriture, empêchant les autres processus d'accéder à la base de données.

J'étais en train de regarder les différentes options au cours de l'été, et les conseils que j'ai obtenu était alors à ceci:essayez les différentes options et voir ce qui fonctionne le mieux pour vous.Ce serait bien s'il y avait simplement une option "meilleure", mais tout le monde est à la recherche de fonctionnalités légèrement différentes et sont prêts à faire des compromis différents.Vous connaissez le mieux.

(Cela dit, il serait utile pour les autres si vous avez partagé ce qui a fini par travailler le mieux pour vous, et pourquoi vous avez choisi cette solution sur les autres!)

Answer 2

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

et aussi avéré être le plus fiable - complètement anti-crash. http://wisdom.cs.wisc.edu/workshops/spring -14 / discussions / Thanu.pdf

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

BerkeleyDB a bien documenté les problèmes de corruption, comme le fait Bitcask. (Et bitcask est en mémoire seule DB de toute façon, inutile pour vos besoins de RAM 1Mo.)

LMDB est aussi bien en Python, avec un couple de différentes fixations disponibles. https://github.com/dw/py-lmdb/ https://github.com/tspurway/pymdb-lightning

Disclaimer - Je suis l'auteur de LMDB. Mais ceux-ci sont faits documentés. LMDB est le plus petit, le plus efficace, et le plus fiable de stockage de clés / valeur dans le monde et rien d'autre ne importe où près

Answer 3

cdb peut gérer une base de données jusqu'à 4 Go, ce qui en fait trop petit pour la matière 20GB à portée de main.

Answer 4

Riak fonctionne sur Linux, et vous permet d'ajouter dynamiquement des noeuds

Answer 5

Que diriez-vous de dbm.ndbm Python 3.0?

Answer 6

Une autre suggestion est TDB (une partie du projet Samba). Je l'ai utilisé par le Module TDB , je ne peux pas dire que je » ai testé sa fiabilité sur les accidents; les projets je l'ai utilisé en ne disposaient pas de telles exigences, et je ne peux pas trouver de la documentation pertinente.

Answer 7

Que diriez-vous d'un SQLite?

Answer 8

Je l'ai utilisé bsddb.hashlib () avec Python, il fonctionnait assez bien.

Answer 9

Vous pourriez aimer djb 's cdb , qui a les propriétés que vous mentionnez.

Answer 10

Dans ma requête pour une base de données ISAM style multi-plateforme (similaire), j'ai aussi reçu des suggestions pour la version intégrée de Firebird et GLib .