Migra de un sistema de OLTP de Oracle® a Cloud Spanner

En este artículo, explicaremos cómo migrar tu base de datos de los sistemas de procesamiento de transacciones en línea (OLTP) de Oracle® a Cloud Spanner.

Cloud Spanner usa ciertos conceptos de manera diferente a otras herramientas de administración de bases de datos empresariales, por lo que es posible que debas ajustar tu aplicación para aprovechar al máximo sus capacidades. Es posible que también debas complementar Cloud Spanner con otros servicios de Google Cloud Platform (GCP) para satisfacer tus necesidades.

Restricciones de migración

Cuando migras tu aplicación a Cloud Spanner, debes tener en cuenta las diferentes funciones disponibles. Probablemente necesites rediseñar la arquitectura de tu aplicación para que se ajuste al conjunto de atributos de Cloud Spanner y para integrarla a servicios de GCP adicionales.

Procedimientos y activadores almacenados

Cloud Spanner no admite la ejecución de código de usuario en el nivel de la base de datos, por lo que, como parte de la migración, debes pasar a la aplicación la lógica empresarial implementada mediante procedimientos y activadores almacenados a nivel de la base de datos.

Secuencias

Cloud Spanner no implementa un generador de secuencias y, como se explica a continuación, el uso de números monótonamente crecientes como claves primarias es un antipatrón en Cloud Spanner. Una forma alternativa de generar una clave primaria única es usar un UUID aleatorio.

Si necesitas usar secuencias por algún motivo externo, tendrás que implementarlas en la capa de la aplicación.

Controles de acceso

Cloud Spanner solo admite controles de acceso a nivel de la base de datos mediante los permisos y las funciones de acceso de Cloud IAM. Las funciones predefinidas pueden dar acceso de lectura y escritura o acceso de solo lectura a la base de datos.

Si necesitas permisos más detallados, debes implementarlos en la capa de la aplicación. En una situación normal, solo la aplicación tiene permiso para leer y escribir en la base de datos.

Si necesitas exponer tu base de datos a los usuarios para generar informes y deseas utilizar permisos de seguridad específicos (como permisos a nivel de la tabla y la vista), debes exportar tu base de datos a BigQuery.

Restricciones de validación de datos

Cloud Spanner puede admitir un conjunto limitado de restricciones de validación de datos en la capa de la base de datos.

Si necesitas restricciones de datos más complejas, tendrás que implementarlas en la capa de la aplicación.

En la siguiente tabla, se describen los tipos de restricciones que se encuentran comúnmente en las bases de datos de Oracle® y cómo implementarlas con Cloud Spanner.

Restricción Implementación con Cloud Spanner
No nulo Restricción de columna NOT NULL
Único Índice secundario con restricción UNIQUE
Clave externa (para tablas normales) Se implementa en la capa de la aplicación
Acciones ON DELETE/ON UPDATE de clave externa Solo es posible para tablas intercaladas; si quieres usarlas en otro contexto, tendrás que implementarlas en la capa de la aplicación
Verificaciones de valor y validación mediante restricciones o activadores CHECK Se implementa en la capa de la aplicación

Tipos de datos admitidos

Las bases de datos de Oracle® y Cloud Spanner admiten diferentes conjuntos de tipos de datos. En la siguiente tabla, se enumeran los tipos de datos de Oracle y su equivalente en Cloud Spanner. Para obtener definiciones detalladas de cada tipo de datos de Cloud Spanner, consulta Tipos de datos.

Es posible que también tengas que realizar transformaciones adicionales en tus datos, como se describe en la columna de Notas, para que los datos de Oracle se ajusten a tu base de datos de Cloud Spanner.

Por ejemplo, puedes almacenar un BLOB grande como objeto en un depósito de Cloud Storage en lugar de en la base de datos y, luego, almacenar la referencia de URI al objeto de Cloud Storage en la base de datos como una STRING.

Tipo de datos de Oracle Equivalente en Cloud Spanner Notas
Tipos de caracteres (CHAR, VARCHAR, NCHAR, NVARCHAR) STRING Nota: Cloud Spanner siempre usa strings Unicode.
Oracle admite una longitud máxima de 32,000 bytes o caracteres (según el tipo), mientras que Cloud Spanner admite hasta 2,621,440 caracteres.
BLOB, LONG RAW, BFILE BYTES o STRING que contienen el URI del objeto. Los objetos pequeños (menos de 10 MiB) se pueden almacenar como BYTES.
Para almacenar objetos más grandes, considera utilizar otras ofertas de GCP, como Cloud Storage.
CLOB, NCLOB, LONG STRING (que puede contener datos o el URI de un objeto externo) Los objetos pequeños (menos de 2,621,440 caracteres) se pueden almacenar como STRING. Para almacenar objetos más grandes, considera utilizar otras ofertas de GCP, como Cloud Storage.
NUMBER, NUMERIC, DECIMAL STRING, FLOAT64, INT64 El tipo de datos NUMBER de Oracle admite hasta 38 dígitos de precisión, mientras que el tipo de datos FLOAT64 de Cloud Spanner admite hasta 16 dígitos de precisión. Consulta Almacena datos numéricos de precisión arbitraria para conocer mecanismos alternativos.
INT, INTEGER, SMALLINT INT64
BINARY_FLOAT, BINARY_DOUBLE FLOAT64
DATE DATE La representación predeterminada en STRING del tipo DATE de Cloud Spanner es yyyy-mm-dd, lo cual difiere de la representación predeterminada que se usa en Oracle. Por eso, debes tener cuidado si conviertes automáticamente las representaciones en STRING de un sistema al otro. Contamos con funciones de SQL para convertir las fechas en una string con formato.
DATETIME TIMESTAMP Cloud Spanner almacena el tiempo independientemente de la zona horaria. Si necesitas almacenar una zona horaria, tendrás que usar una columna de STRING aparte. Se proporcionan funciones de SQL para convertir las marcas de tiempo en una string con formato mediante zonas horarias.
XML STRING (que puede contener datos o el URI de un objeto externo) Los objetos XML pequeños (menos de 2,621,440 caracteres) se pueden almacenar como STRING. Para almacenar objetos más grandes, considera utilizar otras ofertas de GCP, como Cloud Storage.
URI, DBURI, XDBURI, HTTPURI STRING
ROWID PRIMARY KEY Cloud Spanner utiliza la clave primaria de la tabla para ordenar las filas y hacer referencia a ellas de forma interna. Por lo tanto, en la práctica, la clave primaria en Cloud Spanner es equivalente al tipo de datos ROWID.
SDO_GEOMETRY, SDO_TOPO_GEOMETRY_SDO_GEORASTER   Cloud Spanner no admite tipos de datos geoespaciales. Tienes que almacenarlos como tipos de datos estándares y, además, implementar en la capa de la aplicación la lógica de búsqueda y filtrado que quieras usar.
ORDAudio, ORDDicom, ORDDoc, ORDImage, ORDVideo, ORDImageSignature Cloud Spanner no admite tipos de datos de medios. Si necesitas almacenar datos de este tipo, considera utilizar Cloud Storage.

Proceso de migración

Un cronograma general del proceso de migración incluiría los pasos que se indican a continuación:

  • Convertir tu esquema y modelo de datos
  • Traducir las consultas de SQL que uses
  • Migrar tu aplicación para usar Cloud Spanner, además de Oracle
  • Hacer una exportación masiva de tus datos de Oracle y, luego, importarlos en Cloud Spanner mediante Cloud Dataflow
  • Mantener la coherencia entre ambas bases de datos durante la migración
  • Migrar tu aplicación para sacarla de Oracle

Convierte tu base de datos y esquema

Convierte tu esquema existente en un esquema de Cloud Spanner para almacenar tus datos. Esto debería coincidir con el esquema de Oracle existente lo más cercanamente posible para simplificar las modificaciones de la aplicación. Sin embargo, debido a las diferencias en las características, se necesitarán algunos cambios.

El uso de las recomendaciones en el diseño de esquemas puede ayudarte a aumentar la capacidad de procesamiento y a reducir los puntos críticos en tu base de datos de Cloud Spanner.

Claves primarias

Cada tabla que necesita almacenar más de una fila debe tener una clave primaria compuesta por una o más columnas de la tabla. La clave primaria de tu tabla identifica de forma única cada una de sus filas, y debido a que las filas de la tabla están ordenadas por clave primaria, la tabla en sí funciona como índice primario.

No es recomendable designar columnas que aumenten o disminuyan monótonamente como la primera parte de la clave primaria (por ejemplo, secuencias o marcas de tiempo), ya que esto puede generar puntos problemáticos causados por inserciones que se producen al final del espacio de claves. Un punto problemático es una concentración de operaciones en un solo nodo, lo cual reduce la capacidad de procesamiento de escritura a la capacidad del nodo, en lugar de beneficiarse del balanceo de cargas de todas las escrituras entre los nodos de Cloud Spanner.

Utiliza las siguientes técnicas para generar valores de claves primarias únicos y reducir el riesgo de tener puntos problemáticos:

Una vez que hayas designado tu clave primaria para la tabla, no podrás cambiarla sin borrar y volver a crear la tabla. Para obtener más información sobre cómo designar tu clave primaria, consulta Esquema y modelo de datos: Claves primarias.

A continuación, se incluye una instrucción de DDL de ejemplo en la que se crea una tabla para una base de datos de pistas de música:

CREATE TABLE Singers (
  SingerId   INT64 NOT NULL,
  FirstName  STRING(1024),
  LastName   STRING(1024),
  SingerInfo BYTES(MAX),
  BirthDate  DATE,
) PRIMARY KEY(SingerId);

Intercala tus tablas

Cloud Spanner tiene una característica que te permite definir una relación de superior y secundaria de tipo uno a varios entre dos tablas. Esto intercala las filas de datos secundarias con las filas superiores en el almacenamiento, que en la práctica funciona como una unión previa de la tabla y mejora la eficiencia de la recuperación de datos cuando una consulta requiere datos del nivel superior y secundario a la vez.

La clave primaria de la tabla secundaria debe comenzar con las columnas de la clave primaria de la tabla superior. Desde la perspectiva de la fila secundaria, la clave primaria de la fila superior se denomina clave externa. Puedes definir hasta 6 niveles de relaciones entre tablas superiores y secundarias.

Puedes definir acciones de eliminación para las tablas secundarias en las que indicas qué sucede cuando se borra la fila superior: se borran todas las filas secundarias o se impide la eliminación de la fila superior mientras existen filas secundarias.

A continuación, te mostramos un ejemplo de cómo crear una tabla de Álbumes intercalada en la tabla superior de Cantantes definida anteriormente:

CREATE TABLE Albums (
  SingerId     INT64 NOT NULL,
  AlbumId      INT64 NOT NULL,
  AlbumTitle   STRING(MAX),
) PRIMARY KEY (SingerId, AlbumId)
INTERLEAVE IN PARENT (Singers)
ON DELETE CASCADE;

Crea índices secundarios

También puedes crear índices secundarios para indexar datos dentro de la tabla aparte de la clave primaria.

Cloud Spanner implementa índices secundarios de la misma manera que las tablas, por lo que los valores de las columnas que se usarán como claves del índice tienen las mismas restricciones que las claves primarias de las tablas. Esto también significa que los índices tienen las mismas garantías de coherencia que las tablas de Cloud Spanner.

Las búsquedas de valores con índices secundarios son, en la práctica, lo mismo que una consulta con una unión de tablas. Para mejorar el rendimiento de las consultas con índices, puedes almacenar copias de los valores de las columnas de la tabla original en el índice secundario mediante la cláusula STORING, lo que la convierte en un índice de cobertura.

El optimizador de consultas de Cloud Spanner solo usará los índices secundarios automáticamente cuando el índice en sí almacene todas las columnas que se consultan (una consulta cubierta). Para forzar el uso de un índice cuando se consultan columnas de la tabla original, debes usar una directiva FORCE INDEX como la siguiente en la instrucción de SQL:

SELECT *
FROM MyTable@{FORCE_INDEX=MyTableIndex}
WHERE IndexedColumn=@value

Los índices pueden utilizarse para aplicar valores únicos dentro de una columna de la tabla; para ello, se define un índice UNIQUE en esa columna. El índice impedirá que se agreguen valores duplicados.

A continuación, se incluye una instrucción de DDL de ejemplo en la que se crea un índice secundario para la tabla de Álbumes:

CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);

Ten en cuenta que si creas índices adicionales después de cargar tus datos, la propagación de datos al índice puede tardar un poco. Debes limitar la velocidad a la que los agrega a un promedio de tres por día. Para obtener más indicaciones sobre cómo crear índices secundarios, consulta Índices secundarios. Para obtener más información sobre las limitaciones de la creación de índices, consulta Actualizaciones del esquema.

Traduce cualquier consulta de SQL

Cloud Spanner usa el dialecto ANSI 2011 de SQL con extensiones, y tiene muchas funciones y operadores para ayudar a traducir y agregar tus datos. Debes convertir cualquier consulta de SQL que utilice sintaxis, funciones y tipos específicos de Oracle para que sea compatible con Cloud Spanner.

Si bien Cloud Spanner no admite datos estructurados como definiciones de columna, los datos estructurados se pueden usar en las consultas de SQL con los tipos ARRAY y STRUCT.

Por ejemplo, se podría escribir una consulta que muestre todos los álbumes de un artista mediante un ARRAY de STRUCTs en una sola consulta (esto permite aprovechar los datos unidos previamente). Para obtener más información, consulta la sección Notas sobre subconsultas de la documentación.

Las consultas de SQL pueden perfilarse mediante la interfaz de consulta de Cloud Spanner en GCP Console para ejecutar la consulta. En general, las consultas que realizan análisis de tablas completos en tablas grandes son muy costosas y deben usarse con moderación.

Consulta la documentación de recomendaciones de SQL para obtener más información sobre cómo optimizar las consultas de SQL.

Migra tu aplicación para usar Cloud Spanner

Cloud Spanner proporciona un conjunto de bibliotecas cliente para varios lenguajes y la capacidad de leer y escribir datos con llamadas a API específicas de Cloud Spanner, así como mediante consultas de SQL y declaraciones de lenguaje de modificación de datos (DML). El uso de llamadas a la API puede ser más rápido para algunas consultas, como la lectura directa de filas por clave, ya que no hace falta traducir la instrucción de SQL.

También puedes usar el controlador de Conectividad a base de datos de Java (JDBC) para conectarte a Cloud Spanner, lo que te permite aprovechar las herramientas y la infraestructura existentes que no tienen integración nativa.

Como parte del proceso de migración, las características que no están disponibles en Cloud Spanner deben implementarse en la aplicación. Por ejemplo, si usas un activador para que se verifiquen los valores de determinados datos y se actualice una tabla relacionada, tendrás que implementarlo en la aplicación mediante una transacción de lectura y escritura en la que se lea la fila existente, se verifiquen las restricciones y se escriban las filas actualizadas en ambas tablas.

Cloud Spanner ofrece transacciones de lectura y escritura y también de solo lectura, que garantizan la coherencia externa de tus datos. Además, a las transacciones de lectura se les pueden aplicar límites de marca de tiempo, en cuyo caso se lee una versión coherente de los datos especificados de las siguientes maneras:

  • En un momento exacto del pasado (hasta hace 1 hora)
  • En el futuro (en cuyo caso la lectura se bloquea hasta que llegue ese momento)
  • Con una cantidad aceptable de obsolescencia limitada, en cuyo caso se muestra una vista coherente hasta algún tiempo en el pasado sin necesidad de verificar que los datos posteriores estén disponibles en otra réplica. Esto puede ser beneficioso en términos de rendimiento, pero tiene la desventaja de que los datos podrían estar obsoletos

Transfiere tus datos de Oracle a Cloud Spanner

Para transferir tus datos de Oracle a Cloud Spanner, deberás exportar tu base de datos de Oracle a un formato de archivo portátil (por ejemplo, CSV) y luego importar esos datos a Cloud Spanner mediante Cloud Dataflow.

El proceso para extraer, transformar y cargar en Cloud Dataflow

Exporta de forma masiva desde Oracle

Oracle no proporciona ninguna utilidad integrada para exportar o descargar tu base de datos completa en un formato de archivo portátil.

En las Preguntas frecuentes de Oracle se enumeran algunas opciones para realizar una exportación.

Estas incluyen lo siguiente:

  • Utilizar SQL*plus o SQLcl para enviar una consulta a un archivo de texto mediante una operación de tipo Spool.
  • Escribir una función PL/SQL mediante UTL_FILE para descargar una tabla en paralelo a archivos de texto.
  • Usar funciones de Oracle APEX o de Oracle SQL Developer para descargar una tabla en un archivo CSV o XML.

Cada una de estas opciones tiene como desventaja que solo se puede exportar una tabla a la vez, por lo que debes pausar tu aplicación o desactivar tu base de datos para que permanezca en un estado coherente durante la exportación.

Otras opciones incluyen las herramientas de terceros descritas en la página Preguntas frecuentes de Oracle, algunas de las cuales pueden descargar una vista coherente de la base de datos completa.

Una vez descargados los archivos de datos, debes subirlos a un depósito de Cloud Storage a fin de que pueda accederse a ellos para la importación.

Importa de forma masiva a Cloud Spanner

Debido a que probablemente haya diferencias entre los esquemas de base de datos de Oracle y Cloud Spanner, tal vez tengas que hacer algunas conversiones de datos como parte del proceso de importación.

La forma más fácil de hacer estas conversiones antes de importar los datos a Cloud Spanner es mediante Cloud Dataflow.

Cloud Dataflow es el servicio distribuido de extracción, transformación y carga (ETL) de GCP. Proporciona una plataforma para ejecutar canalizaciones de datos escritas con el SDK de Apache Beam a fin de leer y procesar grandes cantidades de datos en paralelo en varias máquinas.

El SDK de Apache Beam requiere que escribas un programa Java sencillo para configurar la lectura, la transformación y la escritura de los datos. Existen conectores de Beam para Cloud Storage y Cloud Spanner, por lo que el único código que debe escribirse es la transformación de datos.

Para ver un ejemplo de canalización simple que lee desde archivos CSV y escribe en Cloud Spanner, consulta el repositorio de código de muestra que acompaña este artículo.

Si se utilizan tablas superiores y secundarias intercaladas en tu esquema de Cloud Spanner, se debe tener cuidado en el proceso de importación para que la fila superior se cree con anterioridad a la fila secundaria. El código de canalización de importación de Cloud Spanner se encarga de esto. Para ello, importa primero todos los datos de las tablas de nivel de raíz, luego todas las tablas secundarias de nivel 1, luego todas las tablas secundarias de nivel 2 y así sucesivamente.

La canalización de importación de Cloud Spanner puede usarse directamente para hacer una importación masiva de tus datos, pero esto requiere que los datos existan en archivos Avro que usen el esquema correcto.

Mantén la coherencia entre ambas bases de datos

Muchas aplicaciones tienen requisitos de disponibilidad que hacen imposible mantener la aplicación sin conexión durante el tiempo necesario para exportar y, luego, importar tus datos. Mientras transfieres tus datos a Cloud Spanner, tu aplicación continúa modificando la base de datos existente. Debes duplicar las actualizaciones en la base de datos de Cloud Spanner mientras se ejecuta la aplicación.

Existen varios métodos para mantener tus dos bases de datos sincronizadas, incluida la captura de datos modificados y la implementación de actualizaciones simultáneas en la aplicación.

Captura los datos modificados

Oracle GoldenGate puede proporcionar una transmisión de captura de datos modificados para tu base de datos. Puedes escribir una aplicación que se suscriba a esta transmisión y aplique las mismas modificaciones (después de convertir los datos, claro) a tu base de datos de Cloud Spanner.

Actualiza en forma simultánea ambas bases de datos desde la aplicación

Un método alternativo es modificar tu aplicación para realizar escrituras en ambas bases de datos. Una base de datos (en principio, Oracle) se consideraría la fuente de información y, después de cada escritura de la base de datos, toda la fila se lee, se convierte y se escribe en la base de datos de Cloud Spanner.

De esta manera, la aplicación reemplaza constantemente las filas de Cloud Spanner con los datos más recientes.

Una vez que estés seguro de que todos tus datos se transfirieron correctamente, puedes cambiar la fuente de información a la base de datos de Cloud Spanner.

Este mecanismo proporciona una ruta de reversión si se detectan problemas cuando se realiza el cambio a Cloud Spanner.

Verifica la coherencia de los datos

A medida que los datos se transmiten a tu base de datos de Cloud Spanner, puedes ejecutar una comparación periódica entre tus datos de Cloud Spanner y tus datos de Oracle para asegurarte de que sean coherentes.

Para validar la coherencia, puedes consultar ambas fuentes de datos y comparar los resultados.

Puedes usar Cloud Dataflow para realizar una comparación detallada de grandes conjuntos de datos mediante la transformación Unir. Esta transformación toma 2 conjuntos de datos con clave y busca los valores que se corresponden entre sí clave por clave. Luego, los valores pueden compararse para determinar si son iguales.

Puedes ejecutar esta verificación regularmente hasta que el nivel de coherencia coincida con los requisitos del negocio.

Cambia a Cloud Spanner como fuente de información de tu aplicación

Cuando confías en la migración de datos, puedes cambiar tu aplicación a Cloud Spanner como fuente de información. Continúa reescribiendo los cambios en la base de datos de Oracle para mantener dicha base de datos actualizada, lo que te brinda una ruta de reversión en caso de que se detecten problemas.

Por último, puedes inhabilitar y quitar el código de actualización de la base de datos de Oracle y cerrar dicha base de datos.

Importa y exporta bases de datos de Cloud Spanner

De forma opcional, puedes exportar tus tablas de Cloud Spanner a un depósito de Cloud Storage mediante una plantilla de Cloud Dataflow para realizar la exportación. La carpeta resultante contiene un conjunto de archivos Avro y archivos de manifiesto JSON que contienen tus tablas exportadas. Estos archivos pueden servir para distintos propósitos, incluidos los que se indican a continuación:

  • Hacer copias de seguridad de tu base de datos para usarla en la recuperación ante desastres o cumplir una política de retención de datos
  • Importar el archivo Avro a otras ofertas de GCP como BigQuery

Para obtener más información sobre el proceso de exportación y de importación, consulta Cómo exportar bases de datos y Cómo importar bases de datos.

Pasos siguientes

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...