python - utilizar - ¿Una base de datos clave-valor confiable y eficiente para Linux?

resumen de la historia de mongodb (10)

Necesito una base de datos de valor-clave rápida, confiable y eficiente en memoria para Linux. Mis claves son aproximadamente 128 bytes, y el tamaño de valor máximo puede ser 128K o 256K. El subsistema de la base de datos no debe usar más de 1 MB de RAM. El tamaño total de la base de datos es 20G (!), Pero solo se accede a una pequeña fracción aleatoria de los datos a la vez. Si es necesario, puedo mover algunos blobs de datos fuera de la base de datos (a archivos normales), por lo que el tamaño se reduce a 2 GB como máximo. La base de datos debe sobrevivir a un bloqueo del sistema sin ninguna pérdida en los datos recientemente no modificados. Tendré unas 100 veces más lecturas que escrituras. Es una ventaja si puede usar un dispositivo de bloque (sin un sistema de archivos) como almacenamiento. No necesito la funcionalidad de servidor de cliente, solo una biblioteca. Necesito enlaces de Python (pero puedo implementarlos si no están disponibles).

¿Qué soluciones debería considerar y cuál recomiendan?

Candidatos que conozco que podrían funcionar:

Tokyo Cabinet (los enlaces de Python son pytc , vea también código de ejemplo pytc , soporta hashes y árboles B +, archivos de registro de transacciones y más, el tamaño de la matriz de cubetas se fija en el momento de creación de la base de datos; el escritor debe cerrar el archivo para dar a otros oportunidad, muchas pequeñas escrituras con la reapertura del archivo para cada uno de ellos son muy lentas, el servidor Tyrant puede ayudar con la cantidad de pequeñas escrituras, la comparación de velocidad entre el Tokyo Cabinet, Tokyo Tyrant y Berkeley DB )
VSDB (seguro incluso en NFS, sin bloqueo; ¿qué pasa con las barreras ?; las actualizaciones son muy lentas, pero no tan lentas como en cdb; la última versión en 2003)
BerkeleyDB (proporciona recuperación de bsddb ; proporciona transacciones; el módulo bsddb Python proporciona enlaces)
TDB de Samba (con transacciones y enlaces Python, algunos usuarios experimentaron corrupción , a veces mmap() s el archivo completo, la operación de repack veces duplica el tamaño del archivo, produce fallas misteriosas si la base de datos es mayor que 2G (incluso en sistemas de 64 bits) También está disponible la implementación de clúster ( CTDB ), el archivo crece demasiado grande después de muchas modificaciones, el archivo se vuelve demasiado lento después de mucha contención de hash, no hay forma integrada de reconstruir el archivo, actualizaciones paralelas muy rápidas mediante el bloqueo de cubos hash individuales.
aodbm (se aodbm solo para que sobreviva un bloqueo del sistema, con enlaces de Python)
hamsterdb (con enlaces de Python)
C-tree (solución comercial madura y versátil con alto rendimiento, tiene una edición gratuita con funcionalidad reducida)
el viejo TDB (desde 2001)
bitcask (estructura de registro, escrito en Erlang)
varias otras implementaciones de DBM (como GDBM, NDBM, QDBM, SDBM de Perl o Ruby, probablemente no tengan la recuperación de fallas adecuada)

No usaré estos:

MemcacheDB (cliente-servidor, utiliza BereleleyDB como back-end)
cdb (necesita regenerar toda la base de datos después de cada escritura)
http://www.wildsparx.com/apbcdb/ (ídem)
Redis (mantiene toda la base de datos en la memoria)
SQLite (se vuelve muy lento sin pasar la aspiradora periódicamente, vea la función de autocompletado en la barra de auto_vacuum de Firefox 3.0, aunque las versiones 3.1 y posteriores de sqlite permiten auto_vacuum ; cuidado: las pequeñas transacciones de escritura pueden ser muy lentas; cuidado: si un proceso es ocupado) está haciendo muchas transacciones, otros procesos se mueren de hambre, y nunca pueden obtener el bloqueo)
MongoDB (demasiado pesado, trata valores como objetos con estructura interna)
Firebird (RDBMS basado en SQL, demasiado pesado)

FYI, un artículo reciente sobre bases de datos de valores clave en la revista Linux.

FYI, una lista de software más antigua

FYI, una comparación de velocidad de MemcacheDB, Redis y Tokyo Cabinet Tyrant

Preguntas relacionadas sobre StackOverflow:

¿Qué tal el dbm.ndbm de Python 3.0?

¿Qué tal un SQLite?

En mi consulta para una base de datos multiplataforma de estilo ISAM (similar), también recibí sugerencias para la versión integrada de Firebird y GLib .

He tenido buena suerte con la solución Tokyo Cabinet / pytc. Es muy rápido (un poco más rápido que usar el módulo shelve usando anydbm en mi implementación), tanto para leer como para escribir (aunque también hago más lecturas). El problema para mí fue la espartana documentación sobre los enlaces de python, pero hay suficiente código de ejemplo para descubrir cómo hacer lo que tienes que hacer. Además, el gabinete de tokio es bastante fácil de instalar (como lo son los enlaces de python), no requiere un servidor (como usted menciona) ~~y parece ser compatible de manera activa~~ (estable pero ya no en desarrollo activo). Puede abrir archivos en modo de solo lectura, permitiendo el acceso simultáneo o el modo de lectura / escritura, evitando que otros procesos accedan a la base de datos.

Estaba buscando varias opciones durante el verano, y el consejo que obtuve entonces fue este: pruebe las diferentes opciones y vea qué funciona mejor para usted. Sería bueno si hubiera simplemente una "mejor" opción, pero todos buscan características ligeramente diferentes y están dispuestos a hacer diferentes intercambios. Tu sabes mejor.

(Dicho esto, sería útil para otros si compartieras lo que terminó siendo lo mejor para ti y por qué elegiste esa solución por sobre otras).

He usado bsddb.hashlib () con Python, funcionó bastante bien.

LMDB es la base de datos más eficiente en cuanto a la memoria en http://symas.com/mdb/inmem/

y también probado ser el más confiable - completamente a prueba de choques. http://wisdom.cs.wisc.edu/workshops/spring-14/talks/Thanu.pdf

De los que ha mencionado, el gabinete de Tokio ha documentado problemas de corrupción google.com/search?q=cfengine+tokyo+cabinet+corruption

BerkeleyDB también tiene problemas de corrupción bien documentados, al igual que Bitcask. (Y bitcask es una base de datos solo en memoria de todos modos, tan inútil para su requerimiento de RAM de 1MB).

LMDB también está bien soportado en Python, con un par de enlaces diferentes disponibles. https://github.com/dw/py-lmdb/ https://github.com/tspurway/pymdb-lightning

Descargo de responsabilidad: soy el autor de LMDB. Pero estos son hechos documentados: LMDB es la tienda clave / valor más pequeña, más eficiente y más confiable del mundo y nada más se acerca.

Otra sugerencia es TDB (una parte del proyecto Samba). Lo he usado a través del módulo tdb , sin embargo, no puedo decir que haya probado su confiabilidad en fallas; los proyectos en los que lo usé no tenían tales requisitos, y no puedo encontrar documentación relevante.

Puede que le guste el djb de cdb , que tiene las propiedades que menciona.

Riak se ejecuta en Linux y le permite agregar nodos dinámicamente

cdb puede manejar cualquier base de datos de hasta 4 GB, por lo que es demasiado pequeño para el material de 20 GB disponible.