Elegir un paradigma de implementación requiere considerar las necesidades de su aplicación en cuanto a disponibilidad (tanto general como en caso de interrupción), latencia, cumplimiento normativo y costo. No existe un paradigma "correcto" para la implementación. Esta sección explora las arquitecturas disponibles para ayudarle a satisfacer sus necesidades de implementación.
Al implementar su base de datos, primero debe elegir entre implementarla en una sola región o en varias. El siguiente diagrama muestra estas opciones, que se explican con más detalle a continuación:
Implementaciones de una sola región
A Laimplementación de una sola región es la opción más sencilla. En una implementación de una sola región, los datos se almacenan en una de las regiones de un proveedor (como la de AWS). us-west-2
o asia-northeast3 de Google). Para las regiones con varias zonas, Atlas siempre proporciona disponibilidad a nivel de zona; los nodos del clúster se distribuyen entre las zonas de disponibilidad de una misma región. Por lo tanto, si falla una zona, los datos siguen estando disponibles en las demás.
Nota
Las regiones recomendadas tienen tres zonas de disponibilidad y están marcadas con un ícono de estrella en la interfaz de usuario de Atlas.
Con la simplicidad y el menor costo de una implementación de una sola región viene el riesgo de una menor disponibilidad y una latencia potencialmente mayor, dependiendo de la distribución de los usuarios de su aplicación.
Implementaciones multirregionales
Una implementación multirregional es un paradigma de implementación más complejo que proporciona mayor disponibilidad y baja latencia en un rango geográfico mayor que una implementación monorregional. Existen varios tipos de implementaciones multirregionales:
Multirregión en una misma geografía: Implementa en múltiples regiones alojadas por un único proveedor de nube dentro de una misma geografía, definida como un área extensa como un país o un continente. Esto garantiza la disponibilidad si falla alguna región.
Por ejemplo, implementa clústeres en el Regiones deAWS
us-west-1us-east-1y, ambas en Estados Unidos. Sius-east-1deja de estar disponible,us-west-1seguirá aceptando lecturas y escrituras con un rendimiento cercano a la normalidad.Multirregión en múltiples geografías: Implementa en una o más regiones de dos o más geografías. Esto garantiza la disponibilidad si falla una región o si un área geográfica completa no está disponible.
Por ejemplo, implementa clústeres en las regiones de AWS
us-east-1us-east-2y, ambas en Estados Unidos, y un tercer clústereu-west-2en, que está en Europa.Multinube: Se implementa en una o más regiones alojadas por múltiples proveedores de nube. Esto proporciona el máximo nivel de disponibilidad, garantizando la disponibilidad de sus datos si falla una región o un proveedor de nube completo.
Por ejemplo, se despliegan clústeres en la región AWS
us-west-1y la región de Google Cloudus-east4.
Consideraciones de disponibilidad
La disponibilidad se suele considerar en términos de la resiliencia de los clústeres ante interrupciones, mientras que la recuperación ante desastres se refiere a la rapidez con la que el sistema se recupera de una interrupción (RTO) y la cantidad de datos que se pueden perder en una interrupción (RPO). Dado que todas las instancias de Atlas siempre tienen datos actualizados, las conmutaciones por error no requieren la restauración de copias de seguridad.
Atlas tiene la replicación integrada en tus implementaciones, lo que significa:
Las instancias de base de datos se mantienen estrechamente sincronizadas entre sí, generalmente en el rango de milisegundos.
En caso de interrupción, la conmutación por error entre instancias de base de datos es totalmente automática. No requiere intervención humana y solo toma unos segundos.
Al utilizar el valor predeterminado writeConcern de,
majorityno se produce pérdida de datos durante la conmutación por error, ya que todos los datos se escribieron en múltiples ubicaciones, lo que evita la pérdida de datos. Además, el controlador de la base de datos reintentará automáticamente cualquier operación en curso para garantizar su éxito.
Esto significa que el RTO, el RPO y la frecuencia de replicación de datos son efectivamente iguales y sus clústeres Atlas están completamente operativos siempre que la mayoría de los nodos estén en buen estado.
Nota
El RTO y el RPO máximos deben considerarse de forma integral, tanto para todo el clúster como para la implementación de la aplicación. Considere la carga de trabajo total del clúster para garantizar que cumpla con sus requisitos.
Comparación de paradigmas de implementación
Para determinar qué patrón de implementación es el adecuado para usted, desglose sus aplicaciones según su importancia para su negocio principal. Cuanto más importante sea la aplicación (es decir, cuanto mayor sea el impacto de una interrupción en su negocio), más debería considerar una arquitectura que gestione automáticamente cualquier interrupción.
La siguiente tabla proporciona una comparación de paradigmas de implementación para ayudarlo a determinar cuál se adapta mejor a sus necesidades:
Nivel de prioridad | Descripción | RTO | Modelo de implementación | Costo relativo |
|---|---|---|---|---|
Nivel 0 | Aplicaciones de máxima criticidad. Requiere conmutación por error totalmente automatizada, incluso en caso de interrupciones regionales. | 0 | $$$ | |
Nivel 1 | Aplicaciones de criticidad menor. Puede experimentar algunos periodos de inactividad o periodos de mantenimiento sin un impacto significativo en las ganancias. | > 1 hora y < 8 horas | $$ | |
Nivel 2 | Aplicaciones de menor criticidad. Pueden estar inactivas durante 24 horas sin afectar significativamente los ingresos. | > 8 horas | $+ | |
No producción | Aplicaciones no críticas. Entornos que no son directamente responsables de la ganancia ni están orientados al cliente. Normalmente entornos de desarrollo y prueba. | n/a | $0 y más |
Nota
El costo de cada tipo de implementación depende de varios factores, incluido el(los) proveedor(es) que selecciones, el número de regiones que necesites, la cantidad de almacenamiento y la potencia de procesamiento de los servidores. Para obtener la información de precios más reciente, consulta Precios de MongoDB.
Casos de uso
Al elegir su paradigma de implementación, comience por identificar la menor cantidad de regiones posibles para atender a la mayor distribución geográfica de sus usuarios. Luego, considere agregar regiones o proveedores de nube adicionales según sus requisitos de disponibilidad, rendimiento y soberanía de datos.
Considere los siguientes casos de uso para ayudar a decidir qué paradigma de implementación funciona para la distribución geográfica de los usuarios de su aplicación:
Usuarios mayoritariamente en una sola geografía
Si la mayoría de los usuarios de su aplicación se encuentran en una misma zona geográfica, le recomendamos implementarla en una o más regiones dentro de ella. Si bien una implementación en una sola región puede proteger contra interrupciones en una sola zona de disponibilidad, una implementación multirregional cubre un área geográfica más amplia y garantiza la disponibilidad durante interrupciones tanto zonales como regionales. Para una mayor disponibilidad, puede implementar en varias regiones. Todas estas opciones ofrecen baja latencia y simplifican el cumplimiento de los requisitos de soberanía de datos, ya que se accede a todos los datos de los usuarios y se almacenan en la misma zona geográfica.
Para obtener más información sobre estos paradigmas de implementación, consulte las siguientes páginas de paradigmas:
Usuarios distribuidos en múltiples geografías
Si los usuarios de su aplicación están distribuidos en varias zonas geográficas, como EE. UU. y Europa, le recomendamos implementarla en una o más regiones de cada zona. Implementar en una región de cada zona geográfica donde presta servicio a sus clientes proporciona baja latencia y disponibilidad en caso de una interrupción geográfica. También puede cumplir con los requisitos de soberanía de datos particionando sus datos para que los datos de los usuarios de cada zona geográfica se alojen en ella.
Para garantizar una alta disponibilidad en caso de interrupciones regionales sin aumentar la latencia ni infringir los requisitos de soberanía de datos, también puede implementar en varias regiones de cada geografía. Puede lograr la máxima disponibilidad en una implementación multirregional implementando clústeres en varias regiones y geografías.
Para obtener más información sobre estos paradigmas de implementación, consulte las siguientes páginas de paradigmas:
Usuarios distribuidos en todo el mundo
Si va a implementar una aplicación para un público mundial, le recomendamos implementar una implementación multirregional en varias zonas geográficas antes de considerar una implementación global. En casi todos los casos, una implementación multirregional en varias zonas geográficas puede satisfacer sus requisitos de alta disponibilidad, baja latencia y soberanía de datos. En casos excepcionales, podría necesitar implementaciones Atlas globales, que son los paradigmas de implementación multirregional más complejos y requieren una planificación muy minuciosa.
Para aprender más sobre estos paradigmas de implementación, consulta las siguientes páginas: