javascript - ioredis - redis subscribe node

Redis como una base de datos (4)

Quiero usar Redis como una base de datos, no como un caché. Desde mi comprensión (limitada), Redis es un almacén de datos en memoria. ¿Cuáles son los riesgos de usar Redis y cómo puedo mitigarlos?

Como Redis es un almacenamiento en memoria, no puede almacenar datos grandes que no se ajusten al tamaño de la memoria de su máquina. Redis generalmente funciona muy mal cuando los datos que almacena son más grandes que 1/3 del tamaño de la RAM. Entonces, esta es la limitación fatal de usar Redis como base de datos.

Ciertamente, puede distribuir sus datos grandes en varias instancias de Redis, pero debe hacerlo todo por su cuenta de forma manual. La operación generalmente se realiza de esta manera (suponiendo que solo tiene 1 instancia desde el inicio):

Utilice su mecanismo maestro-esclavo para replicar datos en la segunda máquina, ahora tiene 2 copias de los mismos datos.
Corta la conexión entre el maestro y el esclavo.
Elimine la primera mitad (dividida por hash, etc.) de datos en la primera máquina y elimine la segunda mitad de datos en la segunda máquina.
Indique a todos los clientes (PHP, C, etc.) que operen en la primera máquina si las claves especificadas están en esa máquina, de lo contrario operarán en la segunda máquina.

¡Esta es la forma en que Redis escala! También debe detener su servicio para evitar cualquier escritura durante la migración.

Para la experiencia que encontramos, tenemos esta conclusión para Redis: Redis no es la opción correcta para almacenar más de 30G de datos, Redis no es escalable, Redis es bastante adecuado para el desarrollo de prototipos.

Más tarde encontramos una alternativa a Redis, que es SSDB ( https://github.com/ideawu/ssdb ), un servidor leveldb que admite casi todas las API de Redis, es adecuado para almacenar más de 1TB de datos, que solo Depende del tamaño de tu disco duro.

Me gustaría compartir algunas cosas que hemos aprendido al usar Redis como base de datos primaria en nuestro servicio. Elegimos Redis ya que teníamos datos que no podían ser particionados. Queríamos obtener el mejor rendimiento que pudiéramos obtener de una caja

Pros:

Redis era inmejorable en rendimiento bruto. Obtuvimos 10K transacciones por segundo desde la caja (Tenga en cuenta que una transacción involucraba múltiples comandos de Redis). Pudimos alcanzar una tasa de transacciones de 25K + por segundo después de unas pocas optimizaciones, junto con las secuencias de comandos LUA. Entonces, cuando se trata de rendimiento por caja, Redis no tiene comparación.
Redis es muy simple de configurar y tiene una curva de aprendizaje muy pequeña en comparación con otras áreas de almacenamiento de datos SQL y NoSQL.

Contras:

Redis admite solo algunas estructuras de datos primitivas como hash, conjuntos, listas, etc. y operaciones en estas estructuras de datos. Estos son más que suficientes cuando usa Redis como caché, pero si desea usar Redis como un almacén de datos principal completo, se sentirá limitado. Tuvimos dificultades para modelar nuestros requisitos de datos usando estos tipos simples.
El mayor problema que hemos visto con Redis fue la falta de flexibilidad. Una vez que haya solucionado la estructura de sus datos, cualquier modificación en los requisitos de almacenamiento o en los patrones de acceso requiere prácticamente volver a pensar en la solución completa. No estoy seguro de si este es el caso con todos los almacenes de datos NoSQL (he oído que MongoDB es más flexible, pero no lo he usado)
Como Redis tiene un solo hilo, la utilización de la CPU es muy baja. No puede poner varias instancias de Redis en la misma máquina para mejorar la utilización de la CPU ya que competirán por el mismo disco, lo que hace que el disco sea el cuello de botella.
La falta de escalabilidad horizontal es un problema como se menciona en otras respuestas.

Puede usar Redis como una tienda autoritativa de varias maneras diferentes:

Active AOF (Almacén de archivos adjuntos) vea documentos AOF . Esto mantendrá un registro de todos los comandos de Redis realizados contra su conjunto de datos en tiempo real.
Ejecute Redis utilizando la replicación Master-Slave, consulte los documentos de replicación . Esto le permitirá proporcionar alta disponibilidad si una de sus instancias falla.
Si está ejecutando algo así como EC2, puede hacer que EBS respalde su partición Redis para proporcionar otra capa de protección contra fallas de instancias.

En el horizonte está Redis Cluster : está diseñado específicamente como una forma de ejecutar Redis de una manera que debería ayudar con HA y la escalabilidad. Sin embargo, esto no aparecerá durante al menos otros seis meses más o menos.

Redis es una tienda en memoria que también puede escribir los datos en el disco. Puede especificar cuántas veces debe hacer una fsync para hacer que redis sea más seguro (pero también más lento => intercambio).

Pero aún no estoy seguro si redis está en el estado para almacenar realmente (misión) datos críticos en él (¿todavía?). Si, por ejemplo, no es un gran problema cuando pierden 1 tweets más (twitter.com) o algo similar, ciertamente usaría redis. También hay mucha información disponible sobre la persistencia en el propio sitio web de redis.

También debe conocer algunos problemas de persistencia que podrían ocurrir al leer el artículo de blog antirez (mantenedores de redis). Deberías leer su blog porque tiene algunos artículos interesantes.