mongodb - Cursores disponibles de Mongo vs Redis pub/sub
publish-subscribe (1)
Estoy respaldando una aplicación de servidor websocket en tiempo real con MongoDB.
La base de clientes está creciendo y el rendimiento de un único subproceso ya no es suficiente. Necesito un pub / sub capa para distribuir mensajes entre hilos.
Normalmente usaría Redis, pero como la aplicación ya usa MongoDB, podría evitar la dependencia utilizando cursores disponibles. Sin embargo, me preocupa el rendimiento.
¿Cómo se compara el rendimiento de cursor de MongoDB con el de Redis para una arquitectura de pub / sub?
En realidad, son bestias muy diferentes.
Un cursor disponible de MongoDB funcionaría como una cola. Puede funcionar con una colección limitada, por lo que no tiene que eliminar explícitamente elementos en la colección. Es bastante eficiente, pero tenga en cuenta que MongoDB bloqueará toda la colección (la base de datos en realidad) en cada operación de escritura, por lo que limita la escalabilidad. Otra limitación de escalabilidad es la cantidad de conexiones. Cada conexión de cliente agregará un hilo de conexión en los servidores de mongod (o mongos).
Aún así, puede esperar decenas de miles de artículos por segundo sin mayores problemas, lo cual puede ser suficiente para una variedad de aplicaciones.
Por otro lado, Redis generalmente puede manejar muchas más conexiones simultáneamente, porque cada conexión no crea un hilo (Redis es un bucle de evento de una sola pista). También es extremadamente eficiente con la CPU, ya que no hace cola en todos los elementos. Con Redis pub / sub, los elementos se propagan a los suscriptores en la misma iteración de bucle de evento que la publicación. Los elementos ni siquiera están almacenados en la memoria, Redis ni siquiera tiene un único índice para mantener. Solo se recuperan de un búfer de socket para que se inserten en otro búfer de sockets.
Sin embargo, como no hay cola, no se garantiza en absoluto la entrega de los mensajes pub / sub de Redis. Si un suscriptor está inactivo cuando se publica un mensaje, el mensaje se perderá para este suscriptor.
Con Redis, puede esperar cientos de miles de artículos por segundo en un único núcleo, especialmente si usa el pipeline y múltiples clientes de publicación.