¿Cuál es el punto de múltiples bases de datos Redis?

Entonces, he llegado a un lugar donde quería segmentar los datos que almaceno en redis en bases de datos separadas, ya que a veces necesito usar el comando de teclas en un tipo específico de datos, y quería separarlos para hacerlo más rápido .

Si segmento en varias bases de datos, todo sigue siendo de un solo subproceso, y todavía solo puedo usar un núcleo. Si solo lanzo otra instancia de Redis en el mismo cuadro, puedo usar un núcleo adicional. Además de eso, no puedo nombrar las bases de datos de Redis ni darles ningún tipo de identificador más lógico. Entonces, con todo eso dicho, ¿por qué / cuándo querría usar múltiples bases de datos Redis en lugar de simplemente activar una instancia adicional de Redis para cada base de datos adicional que quiero? Y en relación, ¿por qué Redis no intenta utilizar un núcleo adicional para cada base de datos adicional que agrego? ¿Cuál es la ventaja de tener un solo subproceso en las bases de datos?

En principio, las bases de datos Redis en la misma instancia no son diferentes a los esquemas en las instancias de la base de datos RDBMS.

Entonces, con todo eso dicho, ¿por qué / cuándo querría usar múltiples bases de datos Redis en lugar de simplemente activar una instancia adicional de Redis para cada base de datos adicional que quiero?

Hay una clara ventaja de usar bases de datos redis en la misma instancia de redis, y es la administración. Si activa una instancia separada para cada aplicación, y digamos que tiene 3 aplicaciones, son 3 instancias de redis separadas, cada una de las cuales probablemente necesitará un esclavo para HA en producción, por lo que son 6 instancias totales. Desde el punto de vista de la administración, esto se vuelve muy rápido porque necesita monitorearlos a todos, hacer actualizaciones / parches, etc. Si no planea sobrecargar Redis con E / S alta, una sola instancia con un esclavo es más simple y más fácil de administrar siempre que cumpla con su SLA.

No desea utilizar varias bases de datos en una sola instancia de redis. Está en desuso y, como notó, varias instancias le permiten aprovechar múltiples núcleos. Si utiliza la selección de la base de datos, tendrá que refactorizar al actualizar. Monitorear y administrar múltiples instancias no es difícil ni doloroso.

De hecho, obtendría métricas mucho mejores en cada base de datos mediante la segregación basada en la instancia. Cada instancia tendrá estadísticas que reflejen ese segmento de datos, lo que puede permitir un mejor ajuste y un monitoreo más receptivo y preciso. Use una versión reciente y separe sus datos por instancia.

Como dijo Jonaton, no use el comando de teclas. Encontrará un rendimiento mucho mejor si simplemente crea un índice clave. Siempre que agregue una clave, agregue el nombre de la clave a un conjunto. El comando de teclas no es terriblemente útil una vez que se escala, ya que tomará mucho tiempo volver.

Deje que el patrón de acceso determine cómo estructurar sus datos en lugar de almacenarlos de la manera que usted cree que funcionan y luego trabajar sobre cómo acceder y picarlos más tarde. Verá un rendimiento mucho mejor y encontrará que el código que consume datos a menudo es mucho más limpio y simple.

Con respecto a un solo subproceso, tenga en cuenta que redis está diseñado para la velocidad y la atomicidad. Claro que las acciones que modifican datos en una base de datos no necesitan esperar en otra base de datos, pero ¿qué sucede si esa acción se guarda en el archivo de volcado o procesa transacciones en esclavos? En ese punto, comienza a meterse en la maleza de la programación de concurrencia.

Al usar varias instancias, convierte la complejidad de subprocesos múltiples en un sistema de estilo de paso de mensajes más simple.

Incluso Salvatore Sanfilippo (creador de Redis) cree que es una mala idea usar múltiples bases de datos en Redis. Vea su comentario aquí:

https://groups.google.com/d/topic/redis-db/vS5wX8X4Cjg/discussion

Entiendo cómo esto puede ser útil, pero desafortunadamente considero que los errores de múltiples bases de datos de Redis son mi peor decisión en el diseño de Redis ... sin ningún tipo de ganancia real, hace que las partes internas sean mucho más complejas. La realidad es que las bases de datos no se escalan bien por varias razones, como la caducidad activa de claves y VM. Si la selección de la base de datos se puede realizar con una cadena, puedo ver que esta característica se usa como una capa de diccionario O (1) escalable, eso no lo es.

Con los números de base de datos, con un valor predeterminado de algunas bases de datos, creo que estamos comunicando mejor qué es esta característica y cómo se puede usar. Espero que en algún momento podamos abandonar la compatibilidad con múltiples bases de datos, pero creo que probablemente sea demasiado tarde ya que hay varias personas que confían en esta función para su trabajo.

1. Realmente no conozco ningún beneficio de tener múltiples bases de datos en una sola instancia. Supongo que es útil si varios servicios usan los mismos servidores de bases de datos, por lo que puede evitar colisiones clave.

2. No recomendaría construir usando el KEYScomando, ya que es O (n) y eso no escala bien. ¿Para qué lo usas y que puedes lograr de otra manera? Quizás redis no sea la mejor opción para usted si la funcionalidad KEYSes vital.

3. Creo que mencionan los beneficios de un servidor único en sus preguntas frecuentes, pero lo principal es la simplicidad: no tiene que preocuparse por la concurrencia de ninguna manera real. Cada acción es un bloqueo, por lo que no hay dos cosas que puedan alterar la base de datos al mismo tiempo. Lo ideal sería tener una (o más) instancias por núcleo de cada servidor, y usar un algoritmo de hash consistente (o un proxy) para dividir las claves entre ellos. Por supuesto, perderá algunas funciones: las tuberías solo funcionarán para cosas en el mismo servidor, las clases se volverán más difíciles, etc.

Estoy usando redis para implementar una lista negra de direcciones de correo electrónico, y tengo diferentes valores TTL para diferentes niveles de listas negras, por lo que tener diferentes bases de datos en la misma instancia me ayuda mucho.

Las bases de datos Redis se pueden usar en los raros casos de implementación de una nueva versión de la aplicación, donde la nueva versión requiere trabajar con diferentes entidades.

El uso de múltiples bases de datos en una sola instancia puede ser útil en el siguiente escenario:

Se podrían usar diferentes copias de la misma base de datos para producción, desarrollo o pruebas utilizando datos en tiempo real. Las personas pueden usar la réplica para clonar una instancia de redis para lograr el mismo propósito. Sin embargo, el primer enfoque es más fácil para que los programas en ejecución existentes solo seleccionen la base de datos correcta para cambiar al modo deseado.

Sé que esta pregunta tiene años, pero hay otra razón por la que varias bases de datos pueden ser útiles.

Si utiliza un "redis en la nube" de su proveedor de nube favorito, probablemente tenga un tamaño de memoria mínimo y pagará lo que asigne. Sin embargo, si su conjunto de datos es más pequeño que eso, estará desperdiciando un poco de la asignación y, por lo tanto, desperdiciando un poco de dinero.

Al usar bases de datos, podría usar la misma instancia de Redis en la nube para proporcionar servicio para (por ejemplo) desarrollo, UAT y producción, o múltiples instancias de su aplicación, o cualquier otra cosa, por lo tanto, usar más de la memoria asignada y ser un poco más costoso. eficaz.

Un caso de uso que estoy viendo tiene varias instancias de una aplicación que usa 200-300K cada una, pero la asignación mínima en mi proveedor de la nube es de 1M. Podemos consolidar 10 instancias en un solo Redis sin realmente hacer mella en ningún límite, y así ahorrar alrededor del 90% del costo de alojamiento de Redis. Aprecio que haya limitaciones y problemas con este enfoque, pero pensé que vale la pena mencionarlo.