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 datos sincronizados en las réplicas regionales.

Las empresas de hoy en día 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 recorrer 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 deben alojar aplicaciones y datos en las 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.

Ventajas de las tablas activas globales:

¿Cómo seleccionar una configuración activa global en NDCS?

La función de tablas activas globales permite replicar de forma transparente los datos de aplicación escritos en una región 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 sola región pasa a estar fuera de línea, aislada o degradada, se debe redirigir la aplicación a otra región y seguir realizando lecturas y escrituras como antes. En resumen, la base de datos debe proporcionar una recuperación ante desastres incluso cuando falla una región. Puede utilizar una tabla Global Active de Oracle NoSQL Database Cloud Service (NDCS) para proporcionar recuperación ante desastres mediante una configuración activa-activa o para replicar datos de forma activa en varias regiones a fin de lograr una baja latencia mediante el acceso a datos locales.

Considere las necesidades de un usuario viajero que compra desde un sitio web popular. Pueden acceder al mismo sitio web de compras de diferentes partes del mundo el mismo día. Debe asegurarse de que el usuario experimente latencia mínima y una interacción perfecta sin importar dónde se encuentre.

La función de tabla Global Active de NDCS proporciona una solución para los dos escenarios descritos anteriormente. Exploremos cada uno de los dos escenarios y entendamos 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 empresa 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 realizan compras en diferentes regiones del mundo. En este ejemplo, la compañía está atendiendo a sus clientes a través de centros de datos geográficamente más cercanos a ellos. Esta configuración implica 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 disponible 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 activo-activo, 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 vuelva la región con fallos, su réplica de tabla regional se sincronizará con las otras regiones. La tabla Global Active proporciona recuperación ante desastres en el sentido de que cuando una región está caída, la aplicación está conectada a otra réplica.

En el segundo escenario, asuma que el usuario en Phoenix, realiza compras en línea y agrega un teléfono móvil a su carro de compra. La región de NDCS de la costa oeste sirve a esta sesión y el usuario experimenta una latencia mínima de solicitud de lectura y escritura desde el almacén de datos local de la región. Este usuario se sube a un avión a Alemania, aterriza 13 horas más tarde, 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 se ve más atractivo. Así que el usuario decide actualizar el carrito de la compra 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. A continuación, 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 carro de compra con el último modelo del teléfono que está presente en la tienda móvil. Dado que 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 las tablas activas globales:

Reglas básicas para crear y gestionar tablas activas globales:

Se deben cumplir los siguientes criterios para crear y gestionar una tabla activa global.

Nota: En NDCS, la replicación de la tabla regional 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?

Cuando se agrega una réplica de tabla regional de una tabla NoSQL existente, se convierte la tabla singleton en una tabla Global Active. Lo siguiente se replicará en una tabla.

Nota: Las etiquetas de OCI permiten agregar metadatos a los recursos. Se pueden asociar una o más etiquetas a una tabla activa global. Las etiquetas de OCI no se replican y una tabla activa global puede tener diferentes etiquetas en diferentes regiones.

Adición de una réplica de tabla regional

Al replicar una tabla, la tabla se crea en otra región, denominada región de receptor. Si la tabla de la región de remitente es singleton, se convertirá en una tabla Global Active. Si la tabla de la región de remitente ya es una tabla activa global, se agregará otra réplica regional a la tabla. La réplica regional se inicializa con los datos de la tabla de la región de remitente. Por ejemplo, si la tabla de la región de remitente tiene 1000 filas, todos los datos se copian en la réplica regional recién creada.

Nota: Al agregar una réplica de tabla regional, la tabla de la región de receptor se coloca en el mismo compartimento con el mismo nombre de tabla que la tabla de la región de remitente. Durante la vida útil de la tabla Global Active, puede moverla a otro compartimento en cualquier momento.

Capacidad (unidades de lectura, unidades de escritura y almacenamiento) para réplicas de tablas regionales

Cuando se agrega una réplica regional de una tabla, los campos read capacity (Capacidad de lectura), write capacity (Capacidad de escritura) y storage capacity (Capacidad de almacenamiento) se establecen automáticamente por defecto 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 de 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 de receptor tiene la misma capacidad de almacenamiento que la tabla de la región de remitente. El modo de capacidad de una tabla activa global se puede aprovisionar o a demanda. 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 que el dato puede estar activo en la tabla (número de horas o días). Oracle NoSQL Database Cloud Service permite a las desarrolladores definir un tiempo de caducidad en las filas de una tabla, después del cual las filas caducan 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 de remitente. Cuando una fila se replica en otras regiones, su tiempo 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 de remitente. Durante esta inicialización de datos de tabla, si se alcanza el valor de 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:

Las siguientes operaciones DDL tienen ámbito global, lo que significa que un cambio en una réplica de tabla regional se propaga automáticamente a todas las réplicas de tabla regional.

Las siguientes operaciones DDL tienen un ámbito local, lo que significa un cambio solo en la réplica de tabla regional en la que se inicia.

Consideraciones de Modelado de Datos para Tablas Activas Globales

¿Por qué debe congelar el esquema de una tabla?

En una configuración de tabla Global Active, 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 las regiones de replicación, ya que estos 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 Global Active, 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, forzando a todas las regiones a un consenso inmediato sobre el esquema de una tabla. Para que resulte más sencillo, rendimiento y previsible, Oracle NoSQL Cloud Service requiere que se bloquee un esquema de 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 debe estar congelado y no se permiten más cambios en el 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 Oracle NoSQL Cloud volverá a rellenar todas las réplicas regionales con los datos más actuales de la región del remitente. Por este motivo, se recomienda tener al menos una columna JSON en la tabla, ya que proporciona más flexibilidad en el esquema y evita la necesidad de modificar el esquema.

Definición de identidad en una tabla activa global

Políticas y permisos de usuario

Las políticas de IAM de una tabla son específicas de la región de remitente.

Cuando un usuario agrega una réplica de una tabla única o una tabla activa global, no se agrega ninguna política o 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 necesita ningún permiso de usuario. Esto significa que el cambio de datos en una tabla de réplica se replicará en todas las demás réplicas de tabla 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 las réplicas de una tabla deben tener permiso NOSQL_TABLE_ALTER en la región de remitente y en todas las regiones de receptor existentes. Los usuarios que desean crear una nueva réplica deben tener el permiso NOSQL_TABLE_CREATE 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 de remitente no se crea en la región de 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.

Borrar réplica:

Los usuarios que desean gestionar las réplicas de una tabla deben tener el permiso NOSQL_TABLE_ALTER en la región de remitente y en todas las regiones de 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 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 las sentencias DML existentes.

Para obtener la mejor latencia, la aplicación suele 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 de remitente, la operación de escritura se ejecuta completamente en la región de 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 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 se confirma una transacción, solo se garantiza que sea atómica, consistente, aislada y duradera en la región donde se produjo 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 coherencia de las réplicas de tablas regionales no es absoluta. La consistencia absoluta es local para una sola región en la que se realiza la operación de lectura. Las lecturas de los datos que se replican desde la región del remitente a las regiones del receptor siempre son consistentes a la larga.

Las escrituras de una región de remitente se replican en todas las regiones de receptor en un intervalo de tiempo. Este intervalo de tiempo 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. Finalmente, la región de receptor obtiene la actualización de la región de remitente y la región de receptor nunca pierde una actualización de transacción que se haya producido en la región de remitente. Todas las réplicas de tablas regionales recibirán finalmente la escritura y serán duraderas.

Visión general del retraso 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 de remitente, la operación de escritura se ejecuta completamente en la región de remitente sin esperar a que se actualicen las regiones de réplica. La latencia de red crea un retraso en la replicación de los cambios en las regiones del receptor. La latencia para replicar los cambios en varias regiones incluye el tiempo que 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 de retraso de réplica, consulte Detalles sobre el retraso de réplica.

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, su conversión en una tabla activa global

A continuación se enumeran los pasos para crear una tabla Global Active.