Unidad 5.4: Bases de datos NoSQL (Managed MongoDB)

Introducción

El clúster relacional de la Unidad 5.3 constituye la base de los sistemas de registro de FinCorp: saldos de cuentas, libros contables y transacciones, donde un esquema fijo y una consistencia fuerte son el objetivo central. Sin embargo, no todas las cargas de trabajo de FinCorp requieren un esquema fijo. El servicio de puntuación de fraude ingiere documentos de eventos heterogéneos cuyos campos varían según el canal y evolucionan en cada sprint, y el servicio customer-360 integra datos de perfil, consentimiento e interacción anidados que, de otro modo, se dispersarían por una docena de tablas unidas mediante uniones. Estas son cargas de trabajo de documentos, y en IONOS CLOUD se implementan en Managed MongoDB.

Esta unidad comienza con la decisión de modelo (cuándo el modelo de documentos supera al relacional) y la decisión de edición (que es permanente de una manera que importa), y luego construye un clúster en el Data Center Designer y se conecta a él. Dos límites de IONOS CLOUD determinan cada decisión de diseño aquí, por lo que se enuncian de manera clara y se diseña en torno a ellos: Managed MongoDB no ofrece replicación administrada de flujos de cambios a un segundo clúster, y el Backup Service basado en Acronis no realiza copias de seguridad de bases de datos administradas en absoluto.

1. El modelo de documentos y cuándo es adecuado frente al relacional

MongoDB almacena datos como documentos BSON agrupados en colecciones, sin un esquema de tabla obligatorio. Esa es la razón fundamental para elegirlo. Una carga de trabajo de documentos es adecuada cuando los registros son agregados autocontenidos cuya estructura varía o evoluciona, cuando la mayoría de las lecturas recuperan un único objeto anidado rico en lugar de unir muchas filas normalizadas, y cuando el esquema debe cambiar sin una migración coordinada. La capa relacional sigue siendo la respuesta correcta cuando se necesitan transacciones ACID multi-fila entre tablas normalizadas, integridad referencial aplicada por el motor, o análisis SQL ad hoc sobre un esquema estable. Para FinCorp, el libro mayor permanece en Managed PostgreSQL; el almacén 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 Database Manager de IONOS CLOUD admite las versiones 6.0 y 7.0 de MongoDB, completamente gestionadas (la aprovisionamiento, la aplicación de parches, las actualizaciones y la monitorización las gestiona la plataforma). El control de acceso dentro de la base de datos utiliza los roles integrados de MongoDB (read, readWrite, readAnyDatabase, readWriteAnyDatabase, dbAdmin, dbAdminAnyDatabase, y clusterMonitor); esta es una asignación de roles a nivel de base de datos, distinta del modelo de grupos y concesiones de IONOS CLOUD, donde el privilegio "Access and manage DBaaS" controla quién puede abrir el Database Manager.

1.1 Ediciones y topología

La decisión de la edición es la más importante en esta unidad, porque es prácticamente permanente. Pasar de Business a Enterprise es una migración de plataforma (un traslado manual de datos a un clúster recién aprovisionado), no un redimensionamiento in situ, y no se admiten degradaciones. Elija la edición para donde estará la carga de trabajo en un año, no para donde comienza.

La siguiente tabla es la comparación de ediciones de IONOS CLOUD; utilícela para ubicar una carga de trabajo antes de aprovisionar nada.

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

La topología sigue a la edición. Business es siempre un único conjunto de réplicas con un número de nodos de 1 o 3 (utilice 3 en producción para alta disponibilidad). Los conjuntos de réplicas de Enterprise admiten 1, 3, 5 o 7 nodos, extendiéndose a 5 o 7 para la distribución de lecturas y la resiliencia, y solo Enterprise puede fragmentar. La fragmentación es escalado horizontal: las colecciones se particionan entre fragmentos mediante una clave de fragmentación, con un mínimo de 2 fragmentos (el número puede aumentarse pero no disminuirse). Cada clúster fragmentado también aprovisiona automáticamente tres instancias de servidor de configuración (2 núcleos / 4 GB / 40 GB de almacenamiento cada una) que están excluidas de sus recursos facturados; los recursos facturados totales son los recursos por nodo multiplicados por el número de instancias y el número de fragmentos. Habilitar la fragmentación en una colección requiere el rol enableSharding.

Recurre a la fragmentación solo cuando una instancia única alcance un límite vertical. Una instancia única de Enterprise escala hasta 31 vCPU y 230 GB de RAM, admite aproximadamente 114.000 conexiones y se limita a 30.000 IOPS de escritura (alcanzados alrededor de un volumen de 600 GB) y un rendimiento secuencial de unos 600 MB/s. Supere esos umbrales (conjunto de trabajo superior a 230 GB, demanda de conexiones superior a ~114.000, o IOPS de escritura superior a 30.000) y fragmente para agregar capacidad entre fragmentos; por debajo de ellos, un conjunto de réplicas escalado verticalmente es más simple y económico. Para FinCorp, el almacén de eventos de fraude comienza como un conjunto de réplicas Business de 3 nodos, con un camino documentado hacia Enterprise si el volumen de eventos obliga a que el conjunto de trabajo supere el límite de RAM de un solo nodo. Tenga en cuenta una consecuencia de la gestión de conexiones: IONOS CLOUD no proporciona un gestor de conexiones administrado para MongoDB, por lo que el límite de conexiones es un presupuesto fijo a nivel de aplicación. Los controladores deben gestionar el agrupamiento de conexiones por sí mismos.

1.2 Diseño alrededor de los dos límites

Sin réplica de flujos de cambios administrada. IONOS CLOUD no ofrece réplica interclúster administrada para MongoDB: no puede apuntar un clúster administrado a otro y esperar que la plataforma transmita cambios entre ellos. 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 flujos de cambios de MongoDB que ejecute) publica eventos de cambios en Managed Kafka (Unidad 5.6), y los consumidores aguas abajo proyectan esos eventos donde sean necesarios. Para FinCorp, los resultados de la puntuación de fraude se publican como eventos en lugar de replicarse a nivel de base de datos, lo que también proporciona a la capa analítica una fuente de eventos limpia sin acoplarla al almacén operativo.

El Backup Service no cubre las bases de datos administradas. El Backup Service basado en Acronis (Unidad 5.7) protege solo VMs y Block Storage; no realiza copias de seguridad de Managed MongoDB. La continuidad de la base de datos se entrega enteramente mediante el propio modelo de copias de seguridad del clúster. La plataforma realiza un Snapshot base cuando se crea el clúster (sincronización inicial, generalmente en menos de 24 horas), después de cada restauración, cada 24 horas, y un Snapshot completo cada domingo. Los Snapshots se retienen durante siete días, y puede restaurar desde cualquier Snapshot tomado con la misma versión de parche de MongoDB o una anterior. La recuperación en un punto en el tiempo, que permite restaurar a un momento elegido entre 1 y 24 horas en el pasado (24 horas por defecto), es exclusiva de Enterprise. Las restauraciones son in situ en el mismo clúster y solo pueden utilizar los propios Snapshots de ese clúster; solo se ejecuta una tarea de restauración a la vez, y el clúster está ocupado durante una restauración y no debe recibir conexiones. Para retención de largo plazo superior a siete días, o para migrar datos hacia dentro o hacia fuera, el camino es mongodump / mongorestore, la misma disciplina de volcado/restauración que la capa relacional. El Oplog sustenta la réplica y la recuperación en un punto en el tiempo: dimensionelo para contener al menos 24 horas de historial; puede redimensionarse 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 clúster (de, eu-south-2, eu-central-3), que es la forma en que FinCorp mantiene una copia geográficamente separada bajo la residencia de datos alemana.

Managed MongoDB hereda la estructura estándar de SLA de DBaaS: una configuración HA de 3 o más nodos tiene un compromiso de disponibilidad del 99,95% por servicio, un clúster de uno o dos nodos tiene un 99,9%, y Playground no tiene SLA. Esta es una razón más por la que el almacén de fraude de producción de FinCorp funciona con 3 nodos desde el primer día.

2. Guía de implementación de DCD

Provisionaremos el almacén de eventos de fraude de FinCorp: un conjunto de réplicas de 3 nodos de MongoDB Business en la LAN privada de datos del VDC existente de FinCorp, y luego nos conectaremos a él desde un cliente dentro del VDC. Esto materializa la capa de documentos de la arquitectura por capas, situándose únicamente en modo privado detrás de la capa de aplicaciones, exactamente igual que lo hace el clúster relacional. MongoDB no tiene gestión automática de direcciones IP y la única subred admitida es /24, por lo que la red debe prepararse primero.

Requisitos previos: el VDC de FinCorp con una LAN privada dedicada; al menos un servidor cliente conectado a esa LAN que pueda resolver DNS público (la base de datos se alcanza mediante un nombre mongodb+srv); el privilegio "Access and manage DBaaS" en su grupo; y una IP privada libre por instancia (tres IPs para un clúster de 3 nodos), elegidas de modo que no colisionen con el rango de DHCP. En un /24 de DHCP de IONOS CLOUD, seleccione direcciones entre x.x.x.3/24 y x.x.x.10/24, que DHCP nunca asigna.

Objetivo de construcción: Provisionar un clúster y conectarse a él.

Pasos (en Data Center Designer):

1. Abra Database Manager para MongoDB y haga clic en Create cluster. El panel de asignación de recursos muestra la cuota del contrato utilizada y no utilizada; el clúster se cuenta contra ella.
2. En Properties, establezca un Cluster Name significativo, elija la Location (el centro de datos / región que contiene los datos; seleccione una región alemana para la residencia de FinCorp) y seleccione la MongoDB Version (6.0 o 7.0).
3. Elija la Edition. Seleccione Business y luego elija una Template que dimensione la RAM / vCPU / almacenamiento desde la lista predefinida. (Enterprise, en cambio, expone los deslizadores de recursos flexibles y la elección entre conjunto de réplicas y clúster particionado, además del interruptor de BI Connector; Playground es el sandbox gratuito fijo.)
4. Establezca el número de nodos en 3 instances para el conjunto de réplicas de producción (Business admite 1 o 3).
5. En Network configuration, seleccione el Datacenter y la Datacenter LAN privada desde el menú desplegable, y luego ingrese una IP/Subnet por instancia. Use las IPs privadas libres reservadas en los requisitos previos; esto es lo que mantiene el clúster únicamente en modo privado.
6. Establezca la Maintenance window: elija un Day y una Start Time (UTC). El mantenimiento se ejecuta en una ventana fija de 4 horas, por lo que elija un intervalo real de bajo tráfico en lugar de dejarlo arbitrario.
7. Revise el precio estimado y luego haga clic en Save para provisionar. El clúster entra en un estado de creación y se vuelve disponible poco después.
8. Para conectarse, abra la pestaña Cluster details del clúster y copie la Connection URI (tiene la forma mongodb+srv://m-<id>.mongodb.<region>.ionos.com). Desde un cliente en la misma LAN privada, ejecute mongosh contra esa URI con su nombre de usuario y contraseña de la base de datos. La conexión debe provenir de un cliente dentro del VDC, porque el punto de acceso es solo privado.

Errores comunes:

• No elija la edición de forma casual. De Business a Enterprise es una migración manual de plataforma, no un redimensionamiento, y las degradaciones no están admitidas. Dimensione la edición para el futuro de la carga de trabajo, no para su primera semana.
• Reserve y registre sus IPs privadas antes de comenzar, una por instancia, dentro de la banda segura de x.x.x.3 a x.x.x.10 en un /24 de DHCP de IONOS CLOUD. La única subred admitida es /24, y el clúster no realiza ninguna gestión de IP por usted, por lo que una colisión con el rango de DHCP o con otro servidor rompe la construcción.
• No intente alcanzar el clúster desde fuera del VDC ni espere un punto de acceso público; la conexión debe originarse desde un cliente en la misma LAN privada. El cliente aún debe resolver DNS público para buscar el nombre mongodb+srv.
• No asuma que Backup Service protege esta base de datos. No lo hace. La continuidad depende de las propias instantáneas del clúster (retención de 7 días), PITR solo de Enterprise (de 1 a 24 horas) y mongodump / mongorestore para algo de vida más larga o para migración.
• Establezca una ventana de mantenimiento real. Es un intervalo fijo de 4 horas durante el cual se ejecutan operaciones gestionadas, por lo que colóquela en un período de bajo tráfico.
• Planifique los recuentos de conexiones contra el límite por instancia (aproximadamente 114.000 en un nodo Enterprise de 230 GB) y use un pool en el controlador. No hay un pooler de conexiones gestionado para absorber una tormenta de conexiones.

Resumen

Managed MongoDB es la capa de documentos de FinCorp: el lugar donde residen agregados irregulares y de rápida evolución, como el almacén de eventos de fraude y customer-360, mientras que el clúster relacional conserva el libro mayor. La elección de edición es prácticamente permanente (de Business a Enterprise es una migración manual), por lo que se dimensiona para el futuro, y la topología se deriva de ella: Business es un único conjunto de réplicas, mientras que Enterprise agrega conjuntos de réplicas más grandes y fragmentación para cargas de trabajo que superan los límites de una sola instancia. El clúster se construye solo en modo privado en una LAN /24 con una IP reservada por nodo y se accede a él mediante una URI mongodb+srv desde un cliente dentro del VDC. Dos límites dan forma al diseño: no hay replicación administrada de flujos de cambios, por lo que los cambios se propagan mediante eventos a nivel de aplicación hacia Kafka, y no hay cobertura de Backup Service para bases de datos, por lo que la continuidad depende de las instantáneas propias del clúster, PITR de Enterprise y volcado/restauración.

Puntos clave:

• Elija documentos sobre relacional cuando los registros sean agregados autónomos y flexibles en esquema, leídos como objetos completos; mantenga el ACID multi-fila y el análisis SQL en la capa relacional.
• La edición es casi permanente: Business (único conjunto de réplicas, 1 o 3 nodos) frente a Enterprise (conjuntos de réplicas de 1/3/5/7 nodos, fragmentación, BI Connector, PITR); de Business a Enterprise es una migración manual de plataforma, no un redimensionamiento.
• Framente solo más allá de los límites de una sola instancia de Enterprise (230 GB de RAM, ~114.000 conexiones, 30.000 IOPS de escritura); mínimo 2 fragmentos, más tres servidores de configuración no facturados.
• Provisione solo en modo privado en una LAN /24 con una IP libre por instancia en el rango seguro de DHCP; conéctese con mongosh mediante la URI mongodb+srv desde un cliente dentro del VDC.
• No hay replicación administrada de flujos de cambios; propague los cambios mediante publicación de eventos a nivel de aplicación hacia Managed Kafka.
• El Backup Service no cubre bases de datos administradas; la continuidad son las instantáneas de 7 días del clúster, PITR exclusivo de Enterprise (1 a 24 horas) y mongodump / mongorestore.

Terminología importante:

• Conjunto de réplicas: un grupo de instancias de MongoDB que mantiene copias de los mismos datos para redundancia y alta disponibilidad; la única topología de Business y la topología más simple de Enterprise.
• Clúster fragmentado: una topología de escalado horizontal exclusiva de Enterprise que particiona colecciones entre fragmentos por clave de fragmento (mínimo 2 fragmentos) más tres servidores de configuración no facturados.
• Oplog: el registro de operaciones que sustenta la replicación y la recuperación en un punto en el tiempo; dimensionelo para al menos 24 horas de historial y redimensione en línea con replSetResizeOplog.
• PITR (recuperación en un punto en el tiempo): restaurar a un momento elegido entre 1 y 24 horas en el pasado; exclusivo de Enterprise y en el mismo clúster.