Este artículo fue escrito por Andrew Morgan de MongoDB.

De vez en cuando, correré aDiseño Revisiónpara una aplicación que se está migrando de una base de datos relacional a MongoDB, donde el cliente comparte un diagrama arquitectónico que muestra una capa de caché (normalmente Redis) sentada entre el servidor de la aplicación y MongoDB.

Me gusta mantener la arquitectura lo más simple posible - después de todo, cada capa trae su propia complejidad y costes de gestión - así que me pregunto por qué la capa de caché está ahí.

Todavía no he terminado una revisión de diseño sin recomendar que se elimine la capa de caché.

Así que para responder a la pregunta en el título de este artículo - ¿cuándo debe usar una caché con MongoDB? - la respuesta probablemente nunca. Este artículo intenta explicar por qué, pero si llega al final y todavía piensa que su aplicación lo necesita, entonces me encantaría discutir su aplicación con usted.

¿Por qué se inventaron cachés como Memcached & Redis, y por qué prosperan?

Los niveles de caché se introdujeron porque era demasiado lento para que las aplicaciones leyeran los datos requeridos directamente de una base de datos relacional.

¿Significa esto que no hay desarrolladores inteligentes que trabajen en Oracle, DB2, Postgres, MySQL, etc.? ¿Por qué esos desarrolladores no podían hacer bases de datos relacionales rápidamente?La respuesta es que todas esas bases de datos fueron escritas por grandes desarrolladores que incluyeron índices, cachés de base de datos internos y otras características para hacer que la lectura de un registro sea lo más rápida posible.

El problema es que la aplicación rara vez necesita leer solo un solo registro de la base de datos relacional normalizada. En cambio, suele necesitar realizar múltiples conjugaciones en muchas tablas para formar un único objeto de negocio. Estas conjugaciones son caras (son lentas y consumen muchos recursos). Por esta razón, la aplicación no quiere incurrir en ese coste cada vez que lee el mismo objeto de negocio.

Hay también el problema de la distribución de datos. La mayoría de las bases de datos relacionales fueron diseñadas hace 50 años cuando una empresa ejecutaría la base de datos y cualquier aplicación en un único centro de datos. Avanza rápidamente a hoy, cuando las empresas y los clientes están dispersos en todo el mundo, con todo el mundo queriendo trabajar con los mismos datos. No quieres que los servidores de aplicaciones distribuidos a nivel mundial sufran la latencia y el costo de recuperar continuamente los mismos datos de una base de datos ubicada en un continente diferente.

Las bases de datos relacionales no fueron diseñadas con este requisito de distribución de datos en mente. los proveedores de RDBMS han intentado crear diferentes soluciones para trabajar en torno a esto, pero están lejos de ser óptimas.

Tenga en cuenta que Redis y Memcached se utilizan ampliamente para el manejo de sesiones para aplicaciones web donde la persistencia no es un requisito. En ese caso, la caché es el único almacenamiento de datos (es decir, no una capa de caché entre la aplicación y MongoDB).

Entonces, ¿qué hay de malo en tener un nivel de cache?

La introducción de una capa de caché a menudo es una gran solución cuando su base de datos no puede proporcionar el rendimiento y la latencia que necesita su aplicación.

Sin embargo, esta capa de datos adicional viene con costes.Los obvios son las licencias de software y hardware necesarias para proporcionar el servicio de caché.

Menos obvia es la carga adicional sobre los desarrolladores. Es un nuevo lenguaje de consulta (y posiblemente lenguaje de programación) para dominar. ¿Qué sucede cuando los datos en el RDBMS cambian? ¿Cómo se propagan esos cambios a su nivel de caché?

Por lo tanto, un nivel de caché tiene que pagar su camino ofreciendo beneficios tangibles sobre tener su aplicación acceso a la base de datos directamente.

¿Cuál es la diferencia con MongoDB?

ElMongoDB document model.

En MongoDB, queremos que almacene sus datos estructurados de una manera que lo haga eficiente para satisfacer rápidamente las consultas más frecuentes de su aplicación (o aquellas con los SLAs más duros). MongoDB refleja la estructura de los objetos al permitir que un solo registro (documento) contenga objetos incrustados (nestos).

En muchos casos, el objeto de negocio requerido por la aplicación se mapeará a un solo documento MongoDB. En otros casos, puede requerir varios documentos que se pueden recoger con una única búsqueda indexada.

MongoDB tiene su propia LRU interna (más recientemente utilizada) caché, por lo que si su documento ha sido accedido recientemente, las posibilidades son que ya está en la memoria.

Tenga en cuenta que MongoDB soportaJuntos, pero tratamos de estructurar sus datos para minimizar su uso.

El otro valor añadido de una capa de caché es la localización de los datos en las arquitecturas distribuidas.MongoDB Replicatiene un nodo primario único que maneja todos los escritos, junto con hasta 49 nodos secundarios, cada uno con una copia de los datos. Para las consultas de latencia más baja, puede colocar secundarios localmente en cada una de sus ubicaciones de servidor de aplicaciones. MongoDB es responsable de mantener los datos en los nodos secundarios actualizados con el primario, por lo que no necesita escribir y mantener ningún código de sincronización adicional.

¿Qué piensa AI?

Las respuestas creadas por la IA generativa están impulsadas por la información que ha sido publicada por personas reales, y por lo tanto debería representar la opinión popular sobre un tema. pensé que sería interesante ver lo que una IA ha llegado a entender como sabiduría convencional sobre por qué la gente coloca una caché delante de MongoDB.

Yo le hice a ChatGPT 4o esta pregunta:

"Explica por qué usaría una capa de caché (como Redis) en lugar de que mi aplicación lea datos directamente de MongoDB".

Redis funciona completamente en la memoria, lo que lo hace significativamente más rápido que MongoDB, que depende de I/O de disco para la recuperación de datos.

"Explica por qué usaría una capa de caché (como Redis) en lugar de que mi aplicación lea datos directamente de MongoDB".

Redis funciona completamente en la memoria, lo que lo hace significativamente más rápido que MongoDB, que depende de I/O de disco para la recuperación de datos.

Como se describió anteriormente, MongoDB tiene su propia caché de memoria, por lo que los documentos a los que accede con frecuencia estarán en la memoria, y no se requiere acceso a disco.

Reducir la carga en MongoDB. Acceso frecuente a MongoDB directamente para los mismos datos aumenta la carga de consultas, lo que puede ralentizar la base de datos, especialmente bajo tráfico de lectura pesada.

Reducir la carga en MongoDB. Acceso frecuente a MongoDB directamente para los mismos datos aumenta la carga de consultas, lo que puede ralentizar la base de datos, especialmente bajo tráfico de lectura pesada.

MongoDB es escalable. Se pueden añadir nodos secundarios adicionales al conjunto de réplica para agregar ancho de banda de consulta adicional.MongoDB en Sharding(Partitioning) puede escalar la capacidad de datos o escribir el rendimiento horizontalmente.

Las aplicaciones con altas tasas de lectura a escritura (por ejemplo, aplicaciones web, APIs) se benefician de la capacidad de Redis de servir datos en caché rápidamente.

Las aplicaciones con altas tasas de lectura a escritura (por ejemplo, aplicaciones web, APIs) se benefician de la capacidad de Redis de servir datos en caché rápidamente.

El cache de la base de datos de MongoDB ofrece las mismas ventajas sin el esfuerzo adicional del desarrollador para sincronizar los cambios de datos.

Redis es ideal para el almacenamiento en caché de datos frecuentes o calientes (por ejemplo, sesiones de usuario, configuraciones o detalles del producto).

Redis es ideal para el almacenamiento en caché de datos frecuentes o calientes (por ejemplo, sesiones de usuario, configuraciones o detalles del producto).

Frecuentemente accesados, los datos calientes se almacenarán en el cache de la base de datos en memoria de MongoDB.

Al replicar las cachés de Redis más cerca de los usuarios finales, puede evitar una alta latencia de red cuando consulta MongoDB desde ubicaciones remotas.

Al replicar las cachés de Redis más cerca de los usuarios finales, puede evitar una alta latencia de red cuando consulta MongoDB desde ubicaciones remotas.

La localización de datos se puede resolver colocando réplicas cerca de los sitios de servidores de aplicaciones.

Redis cuenta con una característica de Time-to-Live (TTL) integrada que elimina automáticamente los datos en caché después de una duración especificada.

Redis cuenta con una característica de Time-to-Live (TTL) integrada que elimina automáticamente los datos en caché después de una duración especificada.

MongoDB utiliza una caché LRU, por lo que los documentos que ya no están siendo consultados serán eliminados de la memoria si el espacio es necesario para los datos más recientemente consultados.Índices de TTLsi desea eliminar los documentos de la base de datos por completo oArchivo Atlas OnlineSi quieres trasladarlos a un almacenamiento más barato.

“La lectura de MongoDB repetidamente puede ser intensiva en recursos, especialmente con consultas complejas, lo que conduce a un aumento de los costos de infraestructura”.

“La lectura de MongoDB repetidamente puede ser intensiva en recursos, especialmente con consultas complejas, lo que conduce a un aumento de los costos de infraestructura”.

Su esquema de MongoDB debe ser diseñado para que sus consultas importantes no requieran consultas complejas.

Redis soporta estructuras de datos avanzadas como listas, conjuntos, conjuntos ordenados, hashes y flujos, que MongoDB no proporciona nativamente.

Redis soporta estructuras de datos avanzadas como listas, conjuntos, conjuntos ordenados, hashes y flujos, que MongoDB no proporciona nativamente.

MongoDB admite listas y conjuntos.Los hashes pueden ser representados en MongoDB como un conjunto de documentos que contienen pares de valores clave (elMongoDB patrón de atributos) deColecciones de series de tiempo de MongoDBsatisfacer las mismas necesidades que los flujos de Redis.

“Resiliencia y tolerancia a fallos.Una capa de caché puede servir como un retroceso si MongoDB está temporalmente indisponible o bajo una carga pesada.”

“Resiliencia y tolerancia a fallos.Una capa de caché puede servir como un retroceso si MongoDB está temporalmente indisponible o bajo una carga pesada.”

MongoDB puede escalar verticalmente o horizontalmente para satisfacer cualquier demanda de carga.El escalado se puede automatizar cuando se utiliza MongoDB AtlasLos conjuntos de réplica de MongoDB proporcionan tolerancia de error tanto para las lecturas como para las escrituras.

MongoDB puede tomar tiempo para calcular consultas complejas (por ejemplo, agregaciones, juntas) para los resultados que se solicitan con frecuencia.

MongoDB puede tomar tiempo para calcular consultas complejas (por ejemplo, agregaciones, juntas) para los resultados que se solicitan con frecuencia.

Su esquema MongoDB debe ser diseñado para evitar la necesidad de ejecutar consultas complejas con frecuencia.MongoDB vista materializada, evitando la necesidad de ejecutar repetidamente la misma consulta / agregación compleja.

Si cambio mi prompt a “Explicar por qué no debería usar una capa de caché (como Redis) en lugar de que mi aplicación lea datos directamente de MongoDB”, ChatGPT está feliz de disuadirme de añadir la capa de caché, citando cuestiones como el aumento de la complejidad del sistema, problemas de consistencia de datos, rendimiento para cargas de trabajo pesadas de escritura, costo, flexibilidad de consulta, mantenimiento y fiabilidad, pequeños conjuntos de datos (donde el conjunto de datos activo se ajusta a la caché de MongoDB), y informe en tiempo real.

Resumen

Una capa de caché puede agregar mucho valor cuando su RDBMS no puede proporcionar el rendimiento de la consulta que su aplicación requiere. Cuando se utiliza MongoDB, la base de datos de funciones de registro y caché se combina en una sola capa, ahorrando dinero y tiempo de desarrollador.

Un cache distribuido puede mitigar las deficiencias en su RDBMS, pero MongoDB tiene una distribución integrada.

Responda a este artículo si todavía crees que tu aplicación se beneficiaría de una capa de caché entre tu aplicación y MongoDB.

Más información sobre MongoDB Design Reviews

Design reviewsson una oportunidad para que un experto en diseño de MongoDB le aconseje cómo usar mejor MongoDB para su aplicación. Las revisiones se centran en hacerle exitoso con MongoDB. Nunca es demasiado pronto para solicitar una revisión. Al involucrarnos temprano (tal vez antes de que haya decidido incluso usar MongoDB), podemos aconsejarle cuando tenga la mejor oportunidad de actuar sobre él.

Este artículo explicó cómo diseñar un esquema MongoDB que coincida con la forma en que su aplicación trabaja con los datos puede satisfacer sus requisitos de rendimiento sin necesidad de una capa de caché.

¿Su solicitud se beneficiaría de una revisión?Planifica tu revisión de diseño.