Este artigo foi escrito por Andrew Morgan de MongoDB. Andrew Morgan Páxina Andrew Morgan Páxina De cando en vez, fago unha para unha aplicación que se está a migrar dunha base de datos relacional a MongoDB, onde o cliente comparte un diagrama arquitectónico que mostra unha capa de caché (normalmente Redis) sentada entre o servidor de aplicacións e MongoDB. Deseño Revisión Deseño Revisión Gústame manter a arquitectura o máis simple posible - despois de todo, cada capa trae a súa propia complexidade e custos de xestión - así que preguntar por que a capa de caché está aí. Aínda non teño que rematar unha revisión de deseño sen recomendar que se elimine a capa de caché. Entón, para responder á pregunta no título deste artigo - cando debería usar unha caché con MongoDB? - a resposta probablemente nunca. Este artigo trata de explicar por que, pero se chegar ao final e aínda pensa que a súa aplicación necesita, entón eu querería discutir a súa aplicación con vostede. Por que se inventaron caches como Memcached & Redis, e por que prosperan? Introducíronse niveis de caché porque era demasiado lento para que as aplicacións lesen os datos necesarios directamente desde unha base de datos relacional. Significa isto que non hai desenvolvedores intelixentes que traballen en Oracle, DB2, Postgres, MySQL, etc.? Por que eses desenvolvedores non puideron facer bases de datos relacionais rápido?A resposta é que todas esas bases de datos foron escritas por grandes desenvolvedores que incluíron índices, caches de bases de datos internas e outras funcións para facer a lectura dun rexistro o máis rápido posible. O problema é que a aplicación raramente necesita ler só un único rexistro da base de datos relacional normalizada. En lugar diso, normalmente necesita realizar múltiples xuntas en moitas táboas para formar un único obxecto de negocio. Estas xuntas son caras (son lentas e consomen moitos recursos). Por esta razón, a aplicación non quere incorrer ese custo cada vez que lea o mesmo obxecto de negocio. É onde a capa de caché engade valor - xunta os datos normalizados, relacionais unha vez e, a continuación, caché os resultados para que a aplicación poida obter eficientemente os mesmos resultados moitas veces. Hai tamén o problema da distribución de datos. A maioría das bases de datos relacionais foron deseñadas hai 50 anos cando unha empresa ía executar a base de datos e calquera aplicación nun único centro de datos. Avance rápido ata hoxe, cando as empresas e os clientes están espallados por todo o mundo, con todos queren traballar cos mesmos datos. Non quere que os servidores de aplicacións distribuídos globalmente sofran a latencia e o custo de recuperar continuamente os mesmos datos dunha base de datos situada nun continente diferente. Quere unha copia dos datos localizados localmente preto de cada servidor de aplicacións que o necesita. As bases de datos relacionais non foron deseñadas con este requisito de distribución de datos en mente. os provedores de RDBMS tentaron desenvolver varias solucións para traballar en torno a isto, pero están lonxe de ser óptimas. Teña en conta que Redis e Memcached son amplamente utilizados para o manexo de sesións para aplicacións web onde a persistencia non é un requisito. nese caso, a caché é o único almacenamento de datos (é dicir, non unha capa de caché entre a aplicación e MongoDB). Entón, que está mal en ter un nivel de caché? A introdución dunha capa de caché é a miúdo unha gran solución cando a súa base de datos non pode ofrecer o rendemento e a latencia que necesita a súa aplicación. Non obstante, esta capa de datos adicional vén con custos.Os obvios son as licenzas de software e hardware necesarias para proporcionar o servizo de caché. Menos obvio é a carga extra sobre os desenvolvedores. É unha nova linguaxe de consulta (e posiblemente linguaxe de programación) para dominar. Que ocorre cando os datos no RDBMS cambian? Así, un nivel de caché ten que pagar o seu camiño ao ofrecer beneficios tangibles sobre ter a súa aplicación acceso á base de datos directamente. En que se diferencia MongoDB? A súa . MongoDB document model Modelo de documento MongoDB En MongoDB, queremos que almacenes os teus datos estruturados dun xeito que o faga eficiente para satisfacer rapidamente as consultas máis frecuentes da túa aplicación (ou as que teñen os SLAs máis duros). MongoDB reflicte a estrutura dos obxectos permitindo que un único rexistro (documento) conteña obxectos embutidos (nestes). En moitos casos, o obxecto empresarial requirido pola aplicación mapeará a un único documento MongoDB. MongoDB ten a súa propia LRU interna (o máis recente usado) caché, así que se o seu documento foi accedido recentemente, as posibilidades son que xa está en memoria. Ten en conta que MongoDB soporta , pero intentamos estruturar os seus datos para minimizar o seu uso. joins Xuntos O outro valor engadido dunha capa de caché é a localización de datos en arquitecturas distribuídas. Ten un só nodo primario que xestiona todos os escritos, xunto con ata 49 nodos secundarios, cada un con unha copia dos datos. Para as consultas de latencia máis baixas, pode colocar secundarios localmente en cada unha das localizacións do servidor da aplicación. MongoDB é responsable de manter os datos nos nodos secundarios actualizados co primario, polo que non necesita escribir e manter ningún código de sincronización adicional. MongoDB Replica conxunto MongoDB Replica conxunto ¿Que pensa AI? As respostas creadas pola IA xerativa están impulsadas pola información que foron publicadas por persoas reais, e polo tanto debería representar a opinión popular sobre un tema. Pregunteille a ChatGPT 4o esta pregunta: "Explique por que usaría unha capa de caché (como Redis) en lugar de que a miña aplicación lea datos directamente de MongoDB". Redis funciona enteiramente en memoria, o que o fai significativamente máis rápido que MongoDB, que depende de I/O de disco para a recuperación de datos. "Explique por que usaría unha capa de caché (como Redis) en lugar de que a miña aplicación lea datos directamente de MongoDB". Redis funciona enteiramente en memoria, o que o fai significativamente máis rápido que MongoDB, que depende de I/O de disco para a recuperación de datos. Como se describiu anteriormente, MongoDB ten a súa propia caché de memoria, polo que os documentos aos que accede con frecuencia estarán na memoria e non é necesario o acceso ao disco. O acceso frecuente a MongoDB directamente para os mesmos datos aumenta a carga de consultas, o que pode ralentizar a base de datos, especialmente baixo tráfico de lectura pesado. O acceso frecuente a MongoDB directamente para os mesmos datos aumenta a carga de consultas, o que pode ralentizar a base de datos, especialmente baixo tráfico de lectura pesado. MongoDB é escalable. pódense engadir nodos secundarios adicionais ao conxunto de réplica para engadir ancho de banda de consulta adicional. (particionamento) pode escalar a capacidade de datos ou escribir o rendemento horizontalmente. MongoDB Sharding Páxina MongoDB Sharding Páxina As aplicacións con altas relacións de lectura-escritura (por exemplo, aplicacións web, APIs) beneficianse da capacidade de Redis de servir datos en caché rapidamente. As aplicacións con altas relacións de lectura-escritura (por exemplo, aplicacións web, APIs) beneficianse da capacidade de Redis de servir datos en caché rapidamente. A caché de base de datos de MongoDB ofrece os mesmos beneficios sen o esforzo extra do desenvolvedor para sincronizar os cambios de datos. Redis é ideal para a caché de datos frecuentemente accesibles ou quentes (por exemplo, sesións de usuario, configuracións ou detalles do produto). Redis é ideal para a caché de datos frecuentemente accesibles ou quentes (por exemplo, sesións de usuario, configuracións ou detalles do produto). Os datos quentes que se acceden con frecuencia serán gardados na caché da base de datos in-memory de MongoDB. Replicando as caches de Redis máis preto dos usuarios finais, podes evitar unha alta latencia de rede cando consultas MongoDB desde lugares remotos. Replicando as caches de Redis máis preto dos usuarios finais, podes evitar unha alta latencia de rede cando consultas MongoDB desde lugares remotos. A localización de datos pódese resolver colocando réplicas preto dos sitios do servidor de aplicacións. "Support for Expiring Data (TTL). Redis ten unha característica de Time-to-Live (TTL) incorporada que elimina automaticamente os datos cached despois dunha duración especificada." "Support for Expiring Data (TTL). Redis ten unha característica de Time-to-Live (TTL) incorporada que elimina automaticamente os datos cached despois dunha duración especificada." MongoDB usa unha caché LRU, polo que os documentos que xa non están sendo consultados serán eliminados da memoria se o espazo é necesario para os datos máis recentemente consultados. se desexa eliminar os documentos da base de datos por completo ou se queres mover-los a almacenamento máis barato. Indicadores de TTL Atlas Arquivo en liña Indicadores de TTL Atlas Arquivo en liña Ler de MongoDB repetidamente pode ser intensivo en recursos, especialmente con consultas complexas, o que leva a custos de infraestrutura máis elevados. Ler de MongoDB repetidamente pode ser intensivo en recursos, especialmente con consultas complexas, o que leva a custos de infraestrutura máis elevados. O seu esquema MongoDB debe ser deseñado para que as súas consultas importantes non requiran consultas complexas. Redis soporta estruturas de datos avanzadas como listas, conxuntos, conxuntos ordenados, hashes e fluxos, que MongoDB non proporciona nativamente. Redis soporta estruturas de datos avanzadas como listas, conxuntos, conxuntos ordenados, hashes e fluxos, que MongoDB non proporciona nativamente. MongoDB soporta listas e conxuntos.Os hashes poden ser representados en MongoDB como unha matriz de documentos que conteñen pares de valores clave (o ) da para atender as mesmas necesidades que os fluxos de Redis. MongoDB atributos patróns Coleccións de series de tempo de MongoDB MongoDB atributos patróns Coleccións de series de tempo de MongoDB "Resiliencia e tolerancia de fallos.Unha capa de caché pode servir como un retroceso se MongoDB está temporalmente indispoñible ou baixo unha carga pesada." "Resiliencia e tolerancia de fallos.Unha capa de caché pode servir como un retroceso se MongoDB está temporalmente indispoñible ou baixo unha carga pesada." MongoDB pode escalar verticalmente ou horizontalmente para satisfacer calquera demanda de carga. Os conxuntos de réplica de MongoDB proporcionan tolerancia de fallos tanto para lectas como para escritas. Scaling can be automated when using MongoDB Atlas A escalación pódese automatizar cando se usa o Atlas de MongoDB MongoDB pode levar tempo para calcular consultas complexas (por exemplo, agregacións, conxuntos) para resultados frecuentemente solicitados. MongoDB pode levar tempo para calcular consultas complexas (por exemplo, agregacións, conxuntos) para resultados frecuentemente solicitados. O seu esquema MongoDB debe ser deseñado para evitar a necesidade de executar consultas complexas con frecuencia. , evitando a necesidade de executar repetidamente a mesma consulta / agregación complexa. MongoDB vista materializada MongoDB vista materializada Se modifico a miña solicitude a "Explicar por que non debería usar unha capa de caché (como Redis) en vez de ter a miña aplicación ler datos de MongoDB directamente", ChatGPT está feliz de disuadirme de engadir a capa de caché, citando cuestións como o aumento da complexidade do sistema, problemas de coherencia de datos, rendemento para cargas de traballo pesadas de escritura, custo, flexibilidade de consulta, mantemento e fiabilidade, pequenos conxuntos de datos (onde o conxunto de datos activos encaixa na caché de MongoDB), e informes en tempo real. Resumo Unha capa de caché pode engadir moito valor cando o seu RDBMS non pode ofrecer o rendemento de consulta que a aplicación require. Cando usa MongoDB, a base de datos de rexistro e funcionalidade de caché combínase nunha única capa, aforrando diñeiro e tempo do desenvolvedor. Unha caché distribuída pode mitigar as carencias no seu RDBMS, pero MongoDB ten unha distribución integrada. Responde a este artigo se aínda cre que a súa aplicación se beneficiaría dunha capa de caché entre a súa aplicación e MongoDB. Ler máis acerca de MongoDB design reviews son unha oportunidade para un experto de deseño de MongoDB para aconsellarlle sobre como mellor usar MongoDB para a súa aplicación. As revisións están enfocadas en facelo exitoso usando MongoDB. Nunca é demasiado pronto para solicitar unha revisión. Ao involucrarnos cedo (quizais antes de que mesmo decida usar MongoDB), podemos aconsellarlle cando ten a mellor oportunidade de actuar sobre el. Revisións de deseño Revisións de deseño Este artigo explicou como deseñar un esquema MongoDB que coincida coa forma en que a súa aplicación traballa cos datos pode satisfacer os seus requisitos de rendemento sen necesitar unha capa de caché. A túa solicitude beneficiaría dunha revisión? . Planifica a túa revisión de deseño Planifica a túa revisión de deseño
