Unidad 5.4: NoSQL Bases de datos (Managed MongoDB)

Introducción

La base de datos relacional Cluster de la Unidad 5.3 es la base de los sistemas de registro de FinCorp: saldos de cuenta, libros y transacciones donde un esquema fijo y una fuerte consistencia son el objetivo. Pero no todos los Workload de FinCorp quieren un esquema fijo. El servicio de puntuación de fraude ingiere documentos de eventos heterogéneos cuyos campos difieren por canal y evolucionan cada sprint, y el servicio de cliente-360 une datos de perfil, consentimiento e interacción anidados que de otro modo se dispersarían en una docena de tablas unidas. Estas son cargas de trabajo de documentos, y en IONOS aterrizan en Managed MongoDB.

Esta unidad comienza con la decisión del modelo (cuándo el documento supera a lo relacional) y la decisión de edición (que es permanente de una manera que importa), luego construye un Cluster en el Data Center Designer y se conecta a él. Dos límites de IONOS dan forma a cada elección de diseño aquí, así que los expresamos claramente y diseñamos alrededor de ellos: Managed MongoDB no tiene una replicación de flujo de cambios administrada a una segunda Cluster, y el Backup Service basado en Acronis no respalda las bases de datos administradas en absoluto.

1. El modelo de documento y cuándo se ajusta sobre relacional

El MongoDB almacena datos como documentos BSON agrupados en colecciones, sin un esquema de tabla obligatorio. Esa es la razón principal para utilizarlo. Un documento Workload se ajusta cuando los registros son agregados autocontenidos cuya forma varía o evoluciona, cuando la mayoría de las lecturas extraen un objeto anidado rico en lugar de unir muchas filas normalizadas, y cuando el esquema debe cambiar sin una migración coordinada. El nivel relacional sigue siendo la respuesta correcta cuando se necesitan transacciones ACID de varias filas en tablas normalizadas, integridad referencial impuesta por el motor, o análisis SQL ad-hoc en un esquema estable. Para FinCorp, el libro mayor permanece en el Managed PostgreSQL; el almacenamiento de eventos de fraude y el agregado de cliente-360 se trasladan a Managed MongoDB porque sus documentos son irregulares y su esquema cambia constantemente.

El Administrador de bases de datos de IONOS admite versiones 6.0 y 7.0 de MongoDB, completamente administradas (aprovisionamiento, actualizaciones, parches y monitorización son manejados por la plataforma). El control de acceso dentro de la base de datos utiliza los roles integrados de MongoDB (lectura, lecturaEscritura, lecturaCualquierBaseDeDatos, lecturaEscrituraCualquierBaseDeDatos, administradorDeBaseDeDatos, administradorDeBaseDeDatosCualquierBaseDeDatos y monitorDeCluster); esto es asignación de roles a nivel de base de datos, distinta del modelo de grupos y concesiones de IONOS, donde el privilegio "Acceder y administrar DBaaS" controla quién puede abrir el Administrador de bases de datos en absoluto.

1.1 Ediciones y topología

La decisión de edición es la más importante en esta unidad, porque es efectivamente permanente. Pasar de Business a Enterprise es una migración de plataforma (un movimiento de datos manual a una nueva instancia de Cluster provisionada), no un cambio de tamaño en el lugar, y no se admiten degradaciones. Elija la edición para donde estará el Workload dentro de un año, no donde comienza.

La siguiente tabla es la comparación de ediciones de IONOS; úsela para colocar un Workload antes de aprovisionar cualquier cosa.

Capacidad	MongoDB Business	MongoDB Enterprise
Aprovisionamiento	Disponible en diferentes tamaños enumerados en la sección de configuración de plantillas.	Modelo flexible de RAM, CPU y almacenamiento basado en las necesidades del flujo de trabajo. Puede crear su propia configuración dentro de los límites de asignación de recursos y conexión aplicables.
Tipo de implementación	Conjunto de réplicas.	Conjunto de réplicas o conjunto de réplicas particionadas Cluster.
Particionamiento	No disponible.	Disponible. Puede crear y aumentar el recuento de particiones a través de API.
Conector de inteligencia empresarial	No disponible.	Disponible. Se admite por Cluster. Para obtener más información, consulte API.
Envoltura de escalado	Diseñado para cargas de trabajo de producción en un conjunto de réplicas único; adecuado para aplicaciones que no requieren alta concurrencia o grandes volúmenes de conexión.	Admite asignaciones de recursos más grandes y escalado horizontal, lo que lo hace ideal para cargas de trabajo con requisitos de rendimiento muy altos o para administrar grandes conjuntos de datos en varios nodos.

Por encima de las dos ediciones de producción se encuentra Playground: una instancia fija de 1 vCPU / 2 GB RAM / 50 GB, destinada a pruebas y explícitamente excluida de cualquier SLA. Trátelo como un entorno de pruebas, nunca como un sustituto de una instancia de producción Cluster.

La topología sigue la edición. Business es siempre un conjunto de réplicas único con un recuento de Node de 1 o 3 (use 3 en producción para alta disponibilidad). Los conjuntos de réplicas de Enterprise se extienden a 5 o 7 nodos para distribución de lectura y resiliencia, y solo Enterprise puede particionar. La particionamiento es escalado horizontal: las colecciones se dividen en particiones por una clave de particionamiento, con un mínimo de 2 particiones (el recuento se puede aumentar pero no disminuir). Cada conjunto de réplicas particionadas Cluster también aprovisiona automáticamente tres instancias de servidor de configuración (2 núcleos / 4 GB / 40 GB de almacenamiento cada una) que se excluyen de los recursos facturados; los recursos facturados totales son los recursos por Node multiplicados por el número de instancias y el número de particiones. Habilitar la particionamiento en una colección requiere el rol enableSharding.

Alcanzar la particionamiento solo cuando una instancia única alcanza un muro vertical. Una instancia única de Enterprise se escala hasta 31 vCPU y 230 GB RAM, admite aproximadamente 114,000 conexiones y tiene un límite de 30,000 escrituras IOPS (alcanzado alrededor de un Volume de 600 GB) y alrededor de 600 MB/s de rendimiento de secuencia. Cruce estos umbrales (conjunto de trabajo por encima de 230 GB, demanda de conexión por encima de ~114,000 o escrituras IOPS por encima de 30,000) y particione para agregar capacidad en particiones; por debajo de ellos, un conjunto de réplicas escalado verticalmente es más simple y económico. Para FinCorp, el almacenamiento de eventos de fraude comienza como un conjunto de réplicas de 3-Node Business, con un camino documentado a Enterprise si el Volume de eventos fuerza un conjunto de trabajo más allá del muro de RAM de una sola instancia Node. Tenga en cuenta una consecuencia de gestión de conexiones: IONOS no proporciona un grupo de conexiones administrado para MongoDB, por lo que el techo de conexión es un presupuesto de aplicación duro. Los controladores deben agrupar conexiones ellos mismos.

1.2 Diseñar alrededor de los dos límites

No hay replicación de flujo de cambios administrada. IONOS no ofrece replicación de flujo de cambios administrada entre Cluster para MongoDB: no puede apuntar una instancia administrada Cluster a otra y tener la plataforma transmitir cambios entre ellas. El patrón nativo es la captura de cambios a nivel de aplicación, exactamente el sustituto introducido en la Unidad 1.3. La aplicación (o un consumidor de flujo de cambios MongoDB que ejecuta) publica eventos de cambios en Managed Kafka (Unidad 5.6), y los consumidores posteriores proyectan esos eventos dondequiera que sean necesarios. Para FinCorp, los resultados de puntuación de fraude se publican como eventos en lugar de replicarse a nivel de base de datos, lo que también da a la capa de análisis una fuente de eventos limpia sin acoplarla al almacenamiento operativo.

Backup Service no cubre bases de datos administradas. El Backup Service basado en Acronis (Unidad 5.7) protege solo máquinas virtuales y Block Storage; no respalda Managed MongoDB. La continuidad de la base de datos se entrega por completo por el modelo de copia de seguridad propio de Cluster. La plataforma toma una copia de seguridad base Snapshot cuando se crea el Cluster (sincronización inicial, generalmente en menos de 24 horas), después de cada restauración, cada 24 horas y una copia de seguridad completa cada domingo. Las instantáneas se retienen durante siete días, y puede restaurar desde cualquier Snapshot tomada con la misma o una versión de parche de MongoDB anterior. La recuperación en un momento del tiempo, que le permite restaurar a un momento elegido entre 1 y 24 horas en el pasado (24 horas por defecto), es solo para Enterprise. Las restauraciones se realizan en el mismo Cluster y solo pueden usar las propias instantáneas de ese Cluster; solo se ejecuta un trabajo de restauración a la vez, y el Cluster está ocupado durante una restauración y no debe recibir conexiones. Para la retención a largo plazo más allá de los siete días, o para migrar datos dentro o fuera, el camino es mongodump / mongorestore, la misma disciplina de volcado/restauración que el nivel relacional. El Oplog subyace a la replicación y PITR: tamaño para que contenga al menos 24 horas de historia; se puede cambiar de tamaño más tarde sin tiempo de inactividad utilizando replSetResizeOplog. Los clústeres de Enterprise también pueden colocar copias de seguridad fuera del sitio en una región diferente a la del propio Cluster (de, eu-south-2, eu-central-3), que es cómo FinCorp mantiene una copia geográficamente separada bajo la residencia de datos alemana.

El Managed MongoDB hereda la estructura de SLA estándar de DBaaS: una configuración de alta disponibilidad de 3 o más Node conlleva un compromiso de tiempo de actividad del 99,95% por servicio, una instancia de Cluster única o dual Node conlleva un 99,9%, y Playground no conlleva ningún SLA. Esta es otra razón por la cual el almacenamiento de fraude de producción de FinCorp se ejecuta con 3 nodos desde el primer día.

2. Implementación de DCD paso a paso

Provisionaremos el almacenamiento de eventos de fraude de FinCorp: un conjunto de réplica de negocio de 3-Node MongoDB en el centro de datos privado existente de FinCorp VDC, y luego nos conectaremos a él desde un cliente dentro del VDC. Esto realiza la capa de documento de la arquitectura en capas, sentada detrás de la capa de aplicación de forma privada, exactamente como la base de datos relacional Cluster lo hace. MongoDB no tiene gestión automática de direcciones IP y la única subred compatible es /24, por lo que la red debe prepararse primero.

Requisitos previos: el VDC de FinCorp con un centro de datos privado dedicado LAN; al menos un servidor cliente conectado a ese LAN que pueda resolver direcciones DNS públicas (la base de datos se alcanza a través de un nombre mongodb+srv); el privilegio "Acceso y gestión de DBaaS" en su grupo; y una dirección IP privada libre por instancia (tres direcciones IP para un conjunto de réplica de 3-Node Cluster), elegidas de manera que no entren en conflicto con el rango DHCP. En un rango /24 de IONOS-DHCP, elija direcciones entre x.x.x.3/24 y x.x.x.10/24, que DHCP nunca asigna.

Objetivo de creación: Provisionar una Cluster y conectarse.

Pasos (en el Data Center Designer):

Abra el Administrador de bases de datos para MongoDB y haga clic en Crear Cluster. El panel de asignación de recursos muestra el contrato de cuota utilizado y no utilizado; el Cluster cuenta en contra de él.
En Propiedades, establezca un nombre de Cluster significativo, elija la Ubicación (el centro de datos / región que contiene los datos; elija una región alemana para la residencia de FinCorp) y seleccione la Versión de MongoDB (6.0 o 7.0).
Elija la Edición. Seleccione Business, luego elija un Modelo que dimensione el RAM / vCPU / almacenamiento de la lista predefinida. (Enterprise expone los controladores de recursos flexibles y la elección de conjunto de réplica versus base de datos fragmentada, además del conmutador de conector BI; Playground es el área de juego fija y gratuita.)
Establezca el recuento de Node en 3 instancias para el conjunto de réplica de producción (Business admite 1 o 3).
En Configuración de red, seleccione el Centro de datos y la red privada Centro de datos LAN en el menú desplegable, luego ingrese una dirección IP/Subred por instancia. Utilice las direcciones IP privadas libres reservadas en los requisitos previos; esto es lo que mantiene la Cluster de forma privada.
Establezca la Ventana de mantenimiento: elija un Día y una Hora de inicio (UTC). El mantenimiento se ejecuta en una ventana fija de 4 horas, así que elija un espacio de baja actividad en lugar de dejarlo arbitrario.
Revise el precio estimado, luego haga clic en Guardar para provisionar. La Cluster entra en un estado de creación y estará disponible poco después.
Para conectarse, abra la pestaña Detalles de Cluster y copie la URI de conexión (tiene la forma mongodb+srv://m-<id>.mongodb.<region>.ionos.com). Desde un cliente en la misma red privada LAN, ejecute mongosh contra esa URI con su nombre de usuario y contraseña de base de datos. La conexión debe provenir de un cliente dentro del VDC, porque el punto de conexión es privado solo.

Errores comunes:

No elija la edición de forma casual. De Business a Enterprise es una migración de plataforma manual, no un cambio de tamaño, y las actualizaciones hacia abajo no son compatibles. Dimensione la edición para el futuro de la Workload, no para su primera semana.
Reserve y registre sus direcciones IP privadas antes de comenzar, una por instancia, dentro de la banda segura x.x.x.3 a x.x.x.10 en un rango /24 de IONOS-DHCP. La única subred compatible es /24, y la Cluster no realiza gestión de direcciones IP para usted, por lo que una colisión con el rango DHCP o con otro servidor rompe la creación.
No intente alcanzar la Cluster desde fuera del VDC o espere un punto de conexión público; la conexión debe originarse desde un cliente en la misma red privada LAN. El cliente aún debe resolver direcciones DNS públicas para buscar el nombre mongodb+srv.
No suponga que la Backup Service protege esta base de datos. No lo hace. La continuidad es la instantánea propia de la Cluster (retención de 7 días), la recuperación ante desastres PITR solo para Enterprise (de 1 a 24 horas) y mongodump / mongorestore para cualquier cosa de mayor duración o para migración.
Establezca una ventana de mantenimiento real. Es un espacio fijo de 4 horas durante el cual se ejecutan operaciones administradas, así que colóquelo en un período de baja actividad.
Planifique los recuentos de conexión contra el límite por instancia (alrededor de 114.000 en un Node de Enterprise de 230 GB) y agrupe en el controlador. No hay un conector de conexión administrado para absorber una tormenta de conexiones.

Resumen

Managed MongoDB es el nivel de documento de FinCorp: el hogar para agregados irregulares y de rápida evolución como el almacenamiento de eventos de fraude y customer-360, mientras que el relacional Cluster mantiene el libro de cuentas. La elección de edición es efectivamente permanente (la migración de Business a Enterprise es manual), por lo que se dimensiona para el futuro, y la topología se deriva de ella: Business es un conjunto de réplicas único, Enterprise agrega conjuntos de réplicas más grandes y particionamiento para cargas de trabajo que superan los límites de una sola instancia. El Cluster se construye de forma privada en un /24 LAN con un IP reservado por Node y se accede a través de un mongodb+srv URI desde un cliente dentro del centro de datos virtual. Dos límites dan forma al diseño: no hay replicación de flujo de cambios administrada, por lo que los cambios se propagan a través de eventos a nivel de aplicación en Kafka, y no hay cobertura de Backup Service para bases de datos, por lo que la continuidad depende de las instantáneas propias del Cluster, la recuperación ante desastres de Enterprise y el volcado/restauración.

Puntos clave:

Elija el documento sobre el relacional cuando los registros son agregados autocontenidos, flexibles en esquema y se leen como objetos completos; mantenga la integridad ACID de varias filas y el análisis SQL en el nivel relacional.
La edición es casi permanente: Business (conjunto de réplicas único, 1 o 3 nodos) vs Enterprise (conjuntos de réplicas de 5/7-Node, particionamiento, conector de inteligencia empresarial, recuperación ante desastres); la migración de Business a Enterprise es una migración de plataforma manual, no un redimensionamiento.
Particione solo más allá de los límites de una sola instancia de Enterprise (230 GB RAM, ~114,000 conexiones, 30,000 escrituras IOPS); mínimo 2 particiones, más tres servidores de configuración no facturados.
Proporcione de forma privada en un /24 LAN con un IP gratuito por instancia en el rango seguro de DHCP; conecte con mongosh a través del mongodb+srv URI desde un cliente dentro del centro de datos virtual.
No hay replicación de flujo de cambios administrada; propague los cambios con la publicación de eventos a nivel de aplicación en Managed Kafka.
El Backup Service no cubre las bases de datos administradas; la continuidad es la instantánea de 7 días del Cluster, la recuperación ante desastres solo de Enterprise (de 1 a 24 horas), y mongodump / mongorestore.

Terminología importante:

Conjunto de réplicas: un grupo de instancias de MongoDB que contienen copias de los mismos datos para redundancia y alta disponibilidad; la única topología de Business y la topología de Enterprise más simple.
Cluster particionado: una topología de escalado horizontal solo para Enterprise que divide las colecciones en particiones por clave de partición (mínimo 2 particiones) más tres servidores de configuración no facturados.
Registro de operaciones: el registro de operaciones que subyace a la replicación y la recuperación en un momento dado; tamaño para al menos 24 horas de historia y redimensione en línea con replSetResizeOplog.
Recuperación en un momento dado (PITR): restaurar a un momento elegido entre 1 y 24 horas en el pasado; solo para Enterprise y en el mismo lugar en el Cluster.