Este artículo fue escrito por Andrew Morgan de MongoDB.
De vez en cuando, correré a
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?
Modelo de documento MongoDB
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 soporta
El otro valor añadido de una capa de caché es la localización de los datos en las arquitecturas distribuidas.
¿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.
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.
“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 (el
“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.
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.
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
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?