node.js redis key-value key-value-store leveldb

El almacén de valores clave de multiproceso más rápido, no basado en memoria, para Node.js



redis key-value (5)

¿Por qué no utilizas MySQL (o MariaDB) con la replicación Master-slave? Basado en sus requerimientos. La arquitectura maestro-esclavo de MySql es adecuada para ti.

Básicamente, NoSQL necesita mucho servidor. Por ejemplo, la configuración mínima de MongoDB necesita tres servidores, HBase necesita cuatro servidores.

En este punto de vista, si necesita más legibilidad, agregue un nuevo servidor esclavo en la arquitectura mysql.

Asumimos que el rendimiento de lectura de mysql es 2k tps. Entonces, cuatro nodos del rendimiento de lectura de mysql son 8k tps.

Depende del resultado de su prueba y del uso del servicio (proporción de lectura / escritura).

verifique el siguiente enlace, que es "Marco Cecconi - La arquitectura de StackOverflow". http://www.youtube.com/watch?v=t6kM2EM6so4

¿Cuál es el almacén de valor-clave sin memoria más rápido para Node.js que admite múltiples procesos?

Necesito almacenar pares de cadena / cadena clave-valor simples (no documentos o JSON, solo cadenas).
Aquí hay algunos ejemplos (habría millones de esos):

  • 12345678 - abcdefghijklmnopabcdefghijklmnop
  • 86358098 - ahijklmnopbcdefgahijklmnopbcdefg
  • abcdefghijklmnopabcdefghijklmnop - 12345678
  • ahijklmnopbcdefgahijklmnopbcdefg - 86358098

Yo he tratado:

  • Redis : es muy rápido y hace todo lo que necesito, pero consume demasiada RAM.
  • LevelDB : es rápido y no es demasiado pesado en RAM, sino solo en un solo proceso.

Una solución para LevelDB es multilevel , que expone un solo proceso de LevelDB a través de HTTP.
Pero eso, por supuesto, tiene un costo; Necesito algo rápido.

¿Hay algún almacén de valor-clave que:

  • soporta Node.js o tiene enlaces para ello;
  • almacena pares de cuerdas / cuerdas;
  • soporta múltiples procesos;
  • no reside enteramente en la memoria;
  • ¿es rápido?

Sólo me importa la lectura. La lectura rápida de multiprocesos es necesaria, pero no la escritura.
Estoy contento con la velocidad actual de LevelDB, pero no con el hecho de que sea de un solo proceso.

Detalles adicionales:

  • Estoy hablando de unos 50 millones de pares clave / valor, con claves y valores entre 8 y 500 caracteres.
  • El código se ejecutará en un servidor Linux normal.
  • El uso de la memoria debe limitarse a unos pocos gigabytes (4 GB está bien, 8 GB es aceptable)
  • La lectura pasará mucho más que la escritura; En realidad, podría hacerlo sin escribir.
  • La velocidad es más importante que cualquier otra cosa (dado que se respetan la memoria y la restricción de múltiples procesos).

El problema con el que se encontrará es que "a la velocidad del rayo" y el disco no se mezclan, especialmente si tiene lecturas de acceso aleatorio como lo hace en un sistema de valores clave. Necesita obtener la mayor cantidad posible de datos en la memoria, ya que leer desde la memoria es mucho más rápido que leer desde el disco.

¿Es la razón por la que desea minimizar la memoria porque esta será una base de datos integrada? Si es así, es posible que desee ver a Empress - http://www.empress.com . Lo he usado en un par de proyectos y puede configurar cuánto se carga. Sin embargo, tiene la sobrecarga de un RDBMS, por lo que no estoy seguro de que sea tan delgado como lo deseas.

También puede considerar MySQL con el complemento Memcache. Esto le permite utilizar MySQL como un almacén de valores clave. Mucho más rápido que MySQL normal, ya que omite el procesamiento de la capa SQL. Además, con MySQL, puede girar las perillas para jugar con la cantidad de memoria que se utiliza.

Firebird es otro db de bajo uso de memoria: http://www.firebirdnews.org/docs/fb2min.html .

De todos modos, espero que esto ayude. Sin una explicación más detallada de sus necesidades (¿está incorporada, por qué la necesidad de ahorrar memoria y si la memoria es valiosa? ¿Qué considera un bajo consumo de memoria, necesita ácido, redundancia, qué considera rápido como un rayo, etc.?) Difícil proporcionar más de un análisis.

Existe un RocksDB de FaceBook que se supone que es rápido (especialmente en el almacenamiento de SSD), y también hay otros como LMDB (ya mencionado) y WiredTiger

Mencionó Redis: si desea utilizar la API de Redis pero tiene una de las bases de datos de clave / valor anteriores como almacenamiento en lugar de su RAM, hay dos proyectos que conozco (aunque no los he probado): LedisDB ( escrito en Go) y ardb (escrito en C ++).

Recientemente comencé a probar lo que parece ser una biblioteca de base de datos de valores clave muy prometedora, aunque aún menos conocida (aunque estoy seguro de que eso cambiará) denominada CuttDB . Tiene un rendimiento muy rápido y está diseñado para manejar grandes cantidades de datos en el disco duro. Incluso incluye una interfaz de servidor Memcached.

Sugeriría echar un vistazo a LMDB (que es el motor más eficiente para OpenLDAP y que se utiliza en una serie de otros proyectos de código abierto).

LMDB es un almacén de valor / clave incorporado, con una API similar a Berkeley-DB o LevelDB, no tiene que almacenar todo en la memoria y puede admitir el acceso desde múltiples procesos. Hay enlaces Node.js:

Puede probar ssdb , una base de datos compatible con el protocolo redis construida en leveldb.

https://github.com/ideawu/ssdb

Puede utilizar el cliente existente de node-redis , aunque algunos de los comandos pueden variar.

benchmarks :

Redis (100.000x) 13,540 op/s ⨠ set small 13,289 op/s ⨠ set medium 13,279 op/s ⨠ set large 13,651 op/s ⨠ get large 13,681 op/s ⨠ get medium 14,428 op/s ⨠ get small SSDB (100.000x) 12,252 op/s ⨠ set small 11,824 op/s ⨠ set medium 11,720 op/s ⨠ set large 13,810 op/s ⨠ get large 13,593 op/s ⨠ get medium 12,696 op/s ⨠ get small lmdb (100.000x) 4,616 op/s ⨠ set small 11,104 op/s ⨠ set medium 17,283 op/s ⨠ set large 13,778 op/s ⨠ get large 16,002 op/s ⨠ get medium 50,562 op/s ⨠ get small multilevel (100.000x) 6,124 op/s ⨠ set small 5,900 op/s ⨠ set medium 5,944 op/s ⨠ set large 6,215 op/s ⨠ get large 6,125 op/s ⨠ get medium 6,310 op/s ⨠ get small

Como puede ver, ssdb es casi tan rápido como redis, y está diseñado para un almacenamiento persistente. lmdb @ didier-spezia mencionado es ultra rápido para obtener datos pequeños, pero establecer uno es lento.