Tablas activas globales en NDCS
Oracle NoSQL Database Cloud Service soporta una arquitectura de tabla activa global en la que puede crear tablas, replicarlas en varias regiones y mantener los datos sincronizados en las réplicas regionales.
Las empresas actuales necesitan proporcionar servicios más rápidos y mejores a sus clientes. La latencia de red es un parámetro crucial para evaluar el rendimiento de cualquier aplicación. La latencia de red es el tiempo mínimo que tarda un paquete de datos en viajar por la red. Los usuarios esperan completar sus actividades en línea sin problemas y rápidamente desde cualquier lugar. Para satisfacer estas expectativas, las empresas necesitan alojar aplicaciones y datos en regiones distribuidas más cercanas a sus usuarios.
Oracle NoSQL Database Cloud Service proporciona una solución a estos requisitos mediante tablas activas globales. Esta función permite que los datos de aplicación escritos en una región se replicen de forma transparente en varias regiones.
- Leer y escribir de forma local y acceder a los datos de forma global: una configuración activa-activa de tablas activas globales en varias regiones garantiza que una actualización realizada en una tabla de una región se replique automáticamente en las réplicas de la tabla en otras regiones de replicación. Se puede acceder a los datos desde cualquier región replicada.
- Rendimiento: las tablas activas globales permiten leer y escribir los datos localmente, proporcionando una latencia de milisegundos de un solo dígito, que es característica del acceso local para la aplicación distribuida globalmente a cualquier escala. Esto puede aumentar el rendimiento de las aplicaciones globales escaladas de forma masiva y reducir la latencia de las solicitudes de aplicación.
- Fácil de configurar y gestionar: Oracle NoSQL Database Cloud Service elimina la complejidad del despliegue y la gestión de la replicación entre varias regiones mediante tablas activas globales. Agregar réplicas de tablas regionales es sencillo y se puede realizar mediante API, Terraform o la consola de OCI.
- Resiliencia de varias regiones: las tablas activas globales también permiten la tolerancia a fallos en el raro caso de un fallo de región. Si una sola región deja de estar disponible o está fuera de línea, las solicitudes de la aplicación se pueden redirigir a una región en la que se replica la tabla y se pueden realizar lecturas y escrituras en esta tabla.
¿Cómo elegir una configuración activa global en NDCS?
La función de tablas activas globales permite que los datos de aplicación escritos en una región se replicen de forma transparente en varias regiones.
Un evento raro de un fallo de una sola región no debe afectar a la experiencia de los usuarios. Por ejemplo, si una única región pasa a estar fuera de línea, aislada o degradada, la aplicación se debe redirigir a una región diferente y seguir realizando lecturas y escrituras como antes. En resumen, la base de datos debe proporcionar recuperación ante desastres incluso cuando falla una región. Puede utilizar una tabla Global Active en Oracle NoSQL Database Cloud Service (NDCS) para proporcionar recuperación ante desastres mediante una configuración activa-activa o para replicar activamente los datos en varias regiones para lograr una baja latencia mediante el acceso a datos local.
Considere las necesidades de un usuario que viaja que compra desde un sitio web popular. Pueden acceder al mismo sitio web de compras desde diferentes partes del mundo el mismo día. Debe asegurarse de que el usuario tenga una latencia mínima y una interacción perfecta sin importar dónde se encuentren.
La función de tabla Global Active en NDCS proporciona una solución a ambos escenarios descritos anteriormente. Exploremos cada uno de los dos escenarios y veamos cómo una tabla Global Active será la mejor solución para proporcionar alta disponibilidad, baja latencia y recuperación ante desastres.
En el primer escenario, supongamos que su compañía utiliza NDCS en Phoenix (EE. UU. - Oeste), Fráncfort (Alemania) y Tokio (Japón) y que tiene una tabla denominada ShoppingCart, que almacena la información de compras de clientes que compran en diferentes regiones del mundo. En este ejemplo, su compañía presta servicio a sus clientes a través de centros de datos geográficamente más cercanos a ellos. Esta configuración implica la existencia de varias ubicaciones geográficas en las que Oracle NoSQL Database Cloud Service está disponible. Una arquitectura que tiene dos o más regiones distribuidas geográficamente y el servicio NoSQL Database Cloud disponibles en cada una de estas regiones se conoce como una arquitectura de tabla activa global. La tabla ShoppingCart es una tabla activa global y se replica en varias regiones.
En una configuración activa-activa, tiene NDCS disponible en varias regiones y los datos de todas las regiones están sincronizados. Cuando una región falla, las tablas activas globales de las otras regiones de réplica seguirán funcionando como de costumbre y no se verán afectadas por la región fallida. Cuando la región fallida vuelva, su réplica de tabla regional se sincronizará con las otras regiones. La tabla Global Active proporciona recuperación ante desastres en la que cuando una región está caída, la aplicación está conectada a otra réplica.
En el segundo escenario, asuma el usuario en Phoenix, tiendas en línea y agregue un teléfono móvil a su carro de compra. La región NDCS de la costa oeste sirve a esta sesión y el usuario experimenta una latencia mínima de solicitud de lectura y escritura del almacén de datos local de la región. Este usuario se sube a un avión a Alemania, aterriza 13 horas después, llega al hotel, se conecta a la red Wi-Fi, va a la tienda en línea de la compañía móvil y encuentra que hay otro modelo del teléfono que parece más atractivo. Así que el usuario decide actualizar el carrito de compras con este nuevo modelo del teléfono y continúa navegando por la tienda de comercio electrónico móvil. El almacén de datos regional de Frankfurt, que es el almacén de datos más próximo, sirve a esta sesión y proporciona al usuario la misma experiencia de lectura y escritura de baja latencia que la de EE. UU. El usuario viaja a Japón y decide visitar una tienda móvil local para obtener más información sobre los últimos modelos móviles. A continuación, el usuario actualiza el carrito de compras con el último modelo del teléfono que está presente en la tienda móvil. Como NoSQL Database Cloud Service está disponible en tres regiones, una en Phoenix, la segunda en Alemania y la tercera en Japón, y hay más de una réplica de tabla regional, cada vez que el usuario actualiza el carro de compra o navega por la tienda de comercio electrónico móvil, los resultados de búsqueda personalizados y otros datos se recuperan de una región local más cercana al usuario. Este tipo de procesamiento local ofrece las latencias más bajas, el mejor rendimiento y elimina el acceso a la red de área amplia.
Conceptos Básicos
Terminología utilizada en tablas activas globales:
- Región: región de Oracle Cloud Infrastructure (OCI). Es un área geográfica localizada donde los clientes pueden desplegar sus aplicaciones.
- Región de remitente: región desde la que se replica una actualización de tabla a otras regiones.
- Región de receptor: región que recibe la actualización de tabla de otra región.
- Tabla única: tabla que no se replica regionalmente.
- Réplica de tabla regional: réplica de una tabla creada en otra región.
- Tabla activa global: tabla que tiene una o más réplicas de tablas regionales.
Reglas básicas para crear y gestionar tablas activas globales:
- La tabla singleton debe tener al menos una columna JSON.
- El estado del esquema de la tabla debe ser FROZEN.
- En la región del receptor, no debe existir una tabla con el mismo nombre.
- En la región del receptor, el compartimento (con el mismo nombre que el de la región del remitente) ya debe existir.
- Antes de borrar una tabla, se deben eliminar todas las réplicas de tablas regionales de la tabla.
Note:
En NDCS, la replicación de tablas regionales se realiza de forma asíncrona en segundo plano.Puede crear tablas secundarias en una tabla activa global. Una tabla secundaria de una tabla activa global puede ser una tabla única o una tabla activa global. Para convertir la tabla secundaria en una tabla activa global, debe congelar el esquema de la tabla secundaria y agregar una réplica regional. Puede seleccionar una de las réplicas regionales de la tabla principal.
Flujo de trabajo de tabla activa global
¿Qué se replica en una tabla activa global?
- Definición/esquema de la tabla
- Índice de la tabla - Número y definiciones de los índices secundarios.
- Datos de la tabla.
- Capacidad de lectura y capacidad de escritura: por defecto, el límite de lectura de una réplica regional es el mismo que el de cualquier otra réplica regional de la tabla activa global. Sin embargo, las operaciones de lectura son puramente locales, por lo que puede definir opcionalmente los límites de lectura propios de cada región. Por defecto, el límite de escritura de una réplica regional es el mismo que el de cualquier otra réplica regional de la tabla Global Active. Sin embargo, los límites de escritura se pueden definir en diferentes valores en cada región.
- Capacidad de almacenamiento: dado que todas las réplicas regionales de la tabla Global Active almacenan los mismos datos de tabla, el límite de almacenamiento de una réplica regional se copia en todas las demás réplicas regionales de la tabla Global Active.
- Tiempo de Actividad de Tabla por Defecto (TTL)
Adición de una réplica de tabla regional
Note:
Al agregar una réplica de tabla regional, la tabla de la región del receptor se coloca en el mismo compartimento con el mismo nombre de tabla que la tabla de la región del remitente. A lo largo de la vida útil de la tabla activa global, puede moverla a otro compartimento en cualquier momento.Capacidad (unidades de lectura, unidades de escritura y almacenamiento) para réplicas de tablas regionales
Al agregar una réplica regional de una tabla, los campos capacidad de lectura, capacidad de escritura y capacidad de almacenamiento se definen por defecto automáticamente en los valores correspondientes de la tabla en la región del remitente. Sin embargo, puede editar y cambiar los valores de la capacidad de lectura y escritura de la tabla en la región del receptor. No se puede cambiar la capacidad de almacenamiento de la tabla. La tabla de la región del receptor tiene la misma capacidad de almacenamiento que la tabla de la región del remitente. El modo de capacidad de una tabla activa global puede ser bajo demanda o aprovisionado. También puede cambiar el modo de capacidad de cualquier réplica regional para una tabla activa global después de crearla. El cambio en el modo de capacidad es local para esa réplica regional y no afecta a ninguna otra réplica regional de la tabla Global Active.
TTL de registros en réplicas de tablas regionales
El Tiempo de Actividad de la Tabla (TTL) se expresa como la cantidad de tiempo (número de horas o días) que los datos pueden vivir en la tabla. Oracle NoSQL Database Cloud Service permite a los desarrolladores definir el tiempo de caducidad en las filas de la tabla para que estas caduquen automáticamente y ya no estén disponibles. Después de la duración especificada, las filas caducan automáticamente y ya no están disponibles. El TTL de la réplica de tabla regional es el mismo valor que el TTL de la tabla en la región del remitente. Cuando una fila se replica en otras regiones, su hora de caducidad se replica como un registro de hora absoluto. Por lo tanto, esta fila caducará al mismo tiempo, independientemente de cuándo se haya replicado.
Una vez creada una réplica de tabla regional, se inicializa con los datos de la tabla de la región del remitente. Durante esta inicialización de datos de tabla, si se alcanza el valor TTL, estas filas caducarán y una operación de lectura no verá estos registros.
Ámbito de las operaciones DDL después de crear réplicas de tablas regionales:
- Agregar Índice
- Borrar Índice
- Cambio en la capacidad de almacenamiento de la tabla
- Cambio en TTL de tabla
- Cambio en unidades de lectura
- Cambio en unidades de escritura
- Cambio en el modo de capacidad de bajo demanda a aprovisionado o viceversa
Consideraciones sobre el modelado de datos para tablas activas globales
¿Por qué debe congelar el esquema de una tabla?
En una configuración de tabla activa global, tiene tablas en NDCS desplegadas en varias regiones y todas las regiones sirven simultáneamente solicitudes de lectura y escritura. La aplicación que se conecta a NDCS se debe diseñar para conectarse a la región de replicación más cercana. La clave primaria, la clave de partición horizontal y los datos de la tabla deben ser idénticos en todas las regiones de replicación, ya que estas tres son una parte intrínseca de cómo la aplicación utiliza la tabla y cómo se ejecutan las consultas. En una tabla activa global, ya que los registros de tabla se pueden escribir simultáneamente en la tabla en varias regiones, se hace necesario llegar a un consenso sobre el esquema de la tabla. Para ello, evite que el esquema cambie y obligue a todas las regiones a un consenso inmediato sobre el esquema de una tabla. Para lograr una mayor simplicidad, rendimiento y previsibilidad, Oracle NoSQL Cloud Service necesita congelar un esquema para cualquier tabla que participe en la replicación regional. Por lo tanto, antes de convertir una tabla singleton en una tabla activa global, el esquema de tabla se debe congelar y no se permiten más cambios de esquema. Si necesita cambiar el esquema de una tabla activa global después de crear réplicas regionales, primero debe borrar todas las réplicas regionales, modificar el esquema de la tabla y, a continuación, volver a agregar las réplicas regionales. El servicio NoSQL en la nube de Oracle volverá a rellenar todas las réplicas regionales con los datos más actuales de la región del remitente.
¿Por qué se necesita al menos una columna JSON en una tabla al congelar su esquema?
Coordinar una alteración del esquema en réplicas de tablas regionales es difícil y conduce a posibles casos de error. Proporcionar una columna JSON proporciona más flexibilidad en el esquema y evita la necesidad de una modificación del esquema.
Definición de Identidad en una Tabla Activa Global
-
La identidad de un registro en una réplica de tabla regional debe ser única en todas las réplicas regionales de la tabla. Las claves naturales (identificadores únicos globales que identifican cada registro de una tabla) se pueden utilizar como identidad en tablas activas globales solo si pueden garantizar la unicidad en todas las réplicas de tablas regionales.
- Al utilizar la identidad generada por el sistema en una tabla activa global, se debe utilizar UUID. En la mayoría de los casos, no se debe utilizar la columna de identidad porque no se garantiza que sea única en las réplicas de tablas regionales.
Políticas y permisos de usuario
Las políticas de IAM de una tabla son específicas de la región del remitente.
Cuando un usuario agrega una réplica de una tabla única o una tabla activa global, no se agrega ninguna política ni permiso de usuario en la región del receptor. El usuario de la región de origen que desea crear y gestionar réplicas también debe tener los privilegios necesarios en la región del receptor. De lo contrario, aparece un error cuando el usuario agrega una réplica de tabla regional.
Una vez creadas las réplicas de tablas regionales, la replicación de cualquier modificación de datos de una región de remitente a la región de receptor no requiere ningún permiso de usuario. Esto significa que el cambio de datos en una tabla de réplicas se replicará en todas las demás réplicas de tablas independientemente del permiso del usuario. A continuación, se muestran los permisos necesarios para crear y gestionar las réplicas de tablas regionales.
Agregar réplica:
Los usuarios que desean gestionar réplicas de una tabla deben tener NOSQL_TABLE_ALTER permiso en la región del remitente y en todas las regiones del receptor existentes. Los usuarios que desean crear una nueva réplica deben tener NOSQL_TABLE_CREATE permiso en la región del receptor (donde se debe crear una réplica). Al crear una réplica de tabla regional, el permiso de lectura y escritura existente de la tabla en la región del remitente no se crea en la región del receptor. Los usuarios que desean crear una nueva réplica en la región del receptor son responsables de crear los permisos de lectura y escritura de la tabla para cada réplica de tabla regional que creen.
Soltar réplica:
Los usuarios que desean gestionar réplicas de una tabla deben tener el permiso NOSQL_TABLE_ALTER en la región del remitente y en todas las regiones del receptor existentes. Los usuarios que desean borrar una réplica deben tener el permiso NOSQL_TABLE_DROP en la región del receptor (donde se debe borrar una réplica).
Recuadro de Diálogo Crear Índice:
Los usuarios que desean crear índices en réplicas de tablas regionales deben tener el permiso NOSQL_INDEX_CREATE.
Borrar Índice:
Los usuarios que desean borrar índices en las réplicas de tablas regionales deben tener el permiso NOSQL_INDEX_DROP.
Actualizar límites de tabla/TTL/:
Los usuarios que desean gestionar réplicas de una tabla deben tener el permiso NOSQL_TABLE_ALTER en todas las réplicas de tablas regionales.
Lecturas, escrituras y transacciones ACID
Después de crear una tabla activa global, puede realizar operaciones de lectura o escritura en la tabla mediante las API de acceso a datos o sentencias DML existentes.
Para obtener la mejor latencia, la aplicación normalmente leerá de una réplica regional local. Los datos de la réplica regional local también incluirán las actualizaciones de datos replicadas de otras réplicas de tablas regionales. Cada vez que ejecute una operación de escritura (INSERT, UPDATE o DELETE) en una tabla Global Active, los cambios se replicarán en varias regiones de forma asíncrona. Es decir, cuando escribe una fila en la región del remitente, la operación de escritura se ejecuta por completo en la región del remitente sin esperar a que se actualicen las regiones de réplica. Si varias regiones actualizan una fila con la misma clave primaria, se aplica una regla para decidir qué actualización de la región se considera final. En todos estos casos, esta regla de resolución de conflictos incorporada hará que la actualización con el último registro de hora gane y se confirme en la base de datos. Esta regla también se aplica al actualizar el valor de TTL de varias regiones simultáneamente.
Las transacciones ACID son locales para una región. Cuando una transacción se confirma, solo se garantiza que sea atómica, consistente, aislada y duradera en la región en la que se ha producido la escritura. La semántica del modelo de consistencia de una réplica de tabla regional es la misma que la de una tabla no replicada. La consistencia de las réplicas de tablas regionales no es absoluta. La consistencia absoluta es local en una única región en la que se realiza la operación de lectura. Las lecturas de los datos que se replican desde la región remitente a las regiones receptoras siempre son consistentes en última instancia.
Las escrituras de una región de remitente se replican en todas las regiones de receptor en un lapso de tiempo. Este retraso para replicar los cambios en varias regiones incluye el tiempo que se tarda en recibir los datos de la réplica de tabla regional en la región del remitente y el tiempo que se tarda en completar las operaciones de escritura en la región del receptor. Con el tiempo, la región receptora obtiene la actualización de la región remitente y la región receptora nunca pierde una actualización de transacción que se ha producido en la región remitente. Todas las réplicas de tablas regionales recibirán finalmente la escritura y se convertirán en duraderas.
Visión general de la demora de réplica
Cada vez que ejecute una operación de escritura (INSERT, UPDATE o DELETE) en una tabla Global Active, los cambios se replicarán en varias regiones de forma asíncrona.
Es decir, cuando escribe una fila en la región del remitente, la operación de escritura se ejecuta por completo en la región del remitente sin esperar a que se actualicen las regiones de réplica. La latencia de red crea una demora en la replicación de los cambios en las regiones receptoras. La latencia para replicar los cambios en varias regiones incluye el tiempo que se tarda en recibir escrituras de la réplica y aplicarlas en la región del receptor. Si no ha habido escrituras de aplicación para la tabla en la región del remitente, el servicio utiliza los mecanismos de ping para calcular una aproximación de la demora, y la estadística de demora seguirá estando disponible en la región del receptor.
Para obtener más información sobre la métrica Replica Lag, consulte Details on Replica Lag.
Visión general de la creación de una tabla activa global
El proceso de creación de una tabla activa global comienza con la creación de una tabla única y, a continuación, la convierte en una tabla activa global
- Cree una tabla singleton y asegúrese de que una columna es JSON.
- Cambie el estado del esquema de la tabla de Mutable a Frozen (Congelado).
- Decida la región en la que desea agregar una réplica regional de la tabla. Al agregar una réplica regional, los campos de capacidad de lectura, capacidad de escritura y capacidad de almacenamiento se rellenan automáticamente con los valores correspondientes de la región del remitente. Puede cambiar la capacidad de lectura y escritura de la tabla.
- El servicio en la nube crea la tabla en la región del receptor. Si la tabla de la región de origen tiene datos, comienza a copiar datos de la región del remitente a la región del receptor. A medida que se copian los datos de la región del remitente a la región del receptor, el porcentaje de inicialización aumenta de 0 a 100. Puede ver el valor del porcentaje de inicialización en la información de tabla de la consola de OCI, como se muestra a continuación. No se permiten operaciones DML en la nueva réplica de tabla regional hasta que se complete el proceso de inicialización.
