database - what - redis introduction

¿Hay algo así como Redis DB, pero no está limitado con el tamaño de RAM?

Question

Estoy buscando una base de datos que coincida con estos criterios:

• Puede ser no persistente;
• Casi todas las claves de DB deben actualizarse una vez en 3-6 horas (100M + claves con un tamaño total de 100Gb)
• Posibilidad de seleccionar datos rápidamente por clave (o clave principal)
• Esto debe ser un DBMS (para que LevelDB no encaje)
• Cuando se escriben datos, el clúster de DB debe poder atender consultas (sin embargo, se pueden bloquear nodos individuales)
• No en memoria: nuestro conjunto de datos excederá los límites de RAM
• Escalado horizontal y replicación
• Soporta la reescritura completa de todos los datos (MongoDB no borra el espacio después de eliminar los datos)
• C # y soporte de Java

Este es mi proceso de trabajo con dicha base de datos: tenemos un clúster de análisis que produce 100M de registros (50GB) de datos cada 4-6 horas. Los datos son un "conjunto de claves [20]". Esta información debe distribuirse a los usuarios a través de un sistema front-end con una tasa de solicitudes de 1-10k por segundo. En promedio, solo se solicita ~ 15% de los datos, el resto se reescribirá en 4-6 horas cuando se genere el siguiente conjunto de datos.

Lo que intenté:

1. MongoDB. Gastos generales de almacenamiento de datos, altos costos de desfragmentación.
2. Redis. Parece perfecto, pero está limitado con RAM y nuestros datos lo excede.

Entonces la pregunta es: ¿hay algo así como Redis, pero no está limitado con el tamaño de RAM?

Answer 1

Actualmente, puede encontrar fácilmente servidores con más de 100 GB de RAM para alojar una única instancia, o puede fragmentar sus datos y usar varios servidores con menos RAM. Almacenar 100 GB con Redis (en RAM) no es realmente un problema.

Ahora, si realmente quieres probar un clon de última generación de Redis no limitado por el tamaño de la RAM, está NDS (por Matt Palmer):

• http://www.anchor.com.au/blog/2013/04/redis-rethought-exciting-extremes-with-larger-than-memory-datasets/

• https://github.com/mpalmer/redis/tree/nds-2.6

Tenga en cuenta que el backend de almacenamiento de NDS se ha movido de Kyoto Cabinet a LMDB (un paquete muy bueno, que también impulsa OpenLDAP), precisamente debido a problemas de recuperación de espacio después de las claves eliminadas.

Otras soluciones, no compatibles con Redis, también pueden satisfacer sus necesidades: Couchbase y Aerospike, por ejemplo, podrían respaldar fácilmente su rendimiento. Cassandra y Riak probablemente también trabajarían si tienes suficientes nodos.

Answer 2

Sí, SSDB ( https://github.com/ideawu/ssdb ), tiene API muy similares a Redis: http://www.ideawu.com/ssdb/docs/php/

SSDB es compatible con hash, zset. Utiliza leveldb como motor de almacenamiento, la mayoría de los datos se almacenan en el disco, la memoria RAM se utiliza para la caché. En nuestra instancia de SSDB con datos de 300 GB, solo utiliza 800 MB de RAM.

Answer 3

Sí, hay dos alternativas a Redis que no están limitadas por el tamaño de la RAM mientras permanecen compatibles con el protocolo de Redis:

Ardb (C ++), replicación (Maestro-Esclavo / Maestro-Maestro): https://github.com/yinqiwen/ardb

Un servidor de almacenamiento persistente compatible con el protocolo redis, admite LevelDB / KyotoCabinet / LMDB como motor de almacenamiento.

Edis (Erlang): http://inaka.github.io/edis/

Edis es un reemplazo de servidor compatible con protocolos para Redis, escrito en Erlang. El objetivo de Edis es ser un reemplazo inmediato para Redis cuando la persistencia es más importante que mantener el conjunto de datos en la memoria. Edis (actualmente) utiliza el nivelldb de Google como back-end.

Y para completar esto, hay otra base de datos de estructuras de datos:

Hyperdex (cadenas, enteros, flotantes, listas, conjuntos, mapas): http://hyperdex.org/doc/latest/DataTypes/#chap:data-types

HyperDex es:

• Rápido: HyperDex tiene una latencia más baja, mayor rendimiento y menor varianza que otras tiendas de valores-clave.
• Escalable: HyperDex escala a medida que se agregan más máquinas al sistema.
• Consistente: HyperDex garantiza linealizabilidad para operaciones basadas en claves. Por lo tanto, una lectura siempre devuelve el último valor insertado en el sistema. No solo "eventualmente", sino de inmediato y siempre.
• Tolerante a fallas: HyperDex replica automáticamente los datos en varias máquinas de modo que las fallas concurrentes, hasta un límite determinado por la aplicación, no causen la pérdida de datos. Buscable:
• HyperDex permite búsquedas eficientes de atributos de datos secundarios.
• Fácil de usar: HyperDex proporciona API para una variedad de scripting y lenguajes nativos.
• Autoconservación: HyperDex es autosuficiente y requiere poco mantenimiento por parte del usuario.