En este artículo, se explica cómo migrar tu base de datos de los sistemas de procesamiento de transacciones en línea (OLTP) de Oracle® a Spanner.
Spanner usa algunos conceptos de manera diferente a otras herramientas de administración de bases de datos empresariales, por lo que es posible que debas configurar tu aplicación para aprovechar al máximo sus capacidades. Es posible que también debas complementar Spanner con otros servicios de Google Cloud para satisfacer tus necesidades.
Restricciones de migración
Cuando migres la aplicación a Spanner, deberás tener en cuenta todas las funciones disponibles. Es probable que necesites rediseñar la arquitectura de la aplicación a fin de ajustarla al conjunto de atributos de Spanner, así como para integrarla a los servicios adicionales de Google Cloud.
Procedimientos y activadores almacenados
Spanner no admite la ejecución de código de usuario a nivel de base de datos. Por lo tanto, como parte de la migración, deberás trasladar la lógica empresarial que implementaron los activadores y los procedimientos almacenados a nivel de base de datos a la aplicación.
Secuencias
Recomendamos usar la versión 4 de UUID como método predeterminado para generar valores de clave
primaria.
La función GENERATE_UUID()
(GoogleSQL, PostgreSQL) muestra valores de UUID de versión 4 como un tipo STRING
.
Si necesitas generar valores enteros de 64 bits, Spanner admite secuencias positivas con inversión de bits (GoogleSQL, PostgreSQL), que producen valores que se distribuyen de manera uniforme en el espacio numérico positivo de 64 bits. Puedes usar estos números para evitar problemas con la generación de hotspots.
Para obtener más información, consulta estrategias de valores predeterminados de claves primarias.
Controles de acceso
Spanner solo admite controles de acceso a nivel de la base de datos mediante las funciones y los permisos 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
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, impleméntalas en la capa de la aplicación.
En la siguiente tabla, se analizan los tipos de restricciones que suelen encontrarse en las bases de datos de Oracle® y cómo implementarlas con Spanner.
Restricción | Implementación con Spanner |
---|---|
No nula | Restricción de columna NOT NULL |
Única | Índice secundario con restricción UNIQUE |
Clave externa (para tablas normales) | Consulta Crea y administra relaciones de claves externas |
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 Oracle® y Spanner admiten conjuntos diferentes de tipos de datos. En la siguiente tabla, se enumeran los tipos de datos de Oracle y sus equivalentes en Spanner. Para obtener definiciones detalladas de cada tipo de datos de Spanner, consulta Tipos de datos.
Es posible que también tengas que realizar transformaciones adicionales en los datos, como se describe en la columna de notas, para que los datos de Oracle se ajusten a tu base de datos de Spanner.
Por ejemplo, puedes almacenar un BLOB
grande como objeto en un depósito de Cloud Storage en lugar de 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 Spanner | Notas |
---|---|---|
Tipos de caracteres (CHAR , VARCHAR , NCHAR , NVARCHAR ) |
STRING
|
Nota: Spanner usa strings Unicode en todo momento. Oracle admite una longitud máxima de 32,000 bytes o caracteres (según el tipo), mientras que 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 usar otras ofertas de Google Cloud, como Cloud Storage. |
CLOB , NCLOB |
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 usar otras ofertas de Google Cloud, 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 Spanner admite hasta 16 dígitos. Consulta Almacena datos numéricos de precisión arbitrarios para ver mecanismos alternativos. |
INT , INTEGER , SMALLINT |
INT64
|
|
BINARY_FLOAT , BINARY_DOUBLE |
FLOAT64
|
|
DATE
|
DATE
|
La representación predeterminada STRING del tipo DATE de Spanner es yyyy-mm-dd , lo cual difiere de la que se usa en Oracle. Por eso, debes tener cuidado si conviertes las representaciones de fechas en STRING de un sistema al otro de forma automática. Se proporcionan funciones de SQL para convertir las fechas en una string con formato.
|
DATETIME
|
TIMESTAMP
|
Spanner almacena el tiempo de forma independiente de la zona horaria. Si necesitas almacenar una zona horaria, debes usar una columna de STRING separada.
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 (de menos de 2,621,440 caracteres) se pueden almacenar como STRING . Para almacenar objetos más grandes, considera usar otras ofertas de Google Cloud, como Cloud Storage. |
URI , DBURI , XDBURI , HTTPURI |
STRING
|
|
ROWID
|
PRIMARY KEY
|
Spanner usa la clave primaria de la tabla para ordenar las filas y hacer referencia a ellas de forma interna. Por lo tanto, en Spanner, es equivalente al tipo de datos ROWID . |
SDO_GEOMETRY , SDO_TOPO_GEOMETRY_SDO_GEORASTER |
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 |
Spanner no admite tipos de datos de medios. Si necesitas almacenar datos de este tipo, considera usar 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 Spanner, además de Oracle
- Hacer una exportación masiva de tus datos de Oracle y, luego, importarlos en Spanner mediante Dataflow
- Mantener la coherencia entre ambas bases de datos durante la migración
- Migrar tu aplicación para sacarla de Oracle
Paso 1: Convierte la base de datos y el esquema
Debes convertir tu esquema existente en un esquema de Spanner para almacenar los datos. Dentro de lo posible, esto debe coincidir con el esquema de Oracle existente para simplificar las modificaciones de la aplicación. Sin embargo, debido a las diferencias en las funciones, se necesitarán algunos cambios.
Usando prácticas recomendadas para el diseño de esquemas puede ayudarte a aumentar la capacidad de procesamiento y reducir los hotspots en tu Base de datos de Spanner.
Claves primarias
En Spanner, cada tabla que debe almacenar más de una fila debe tener una clave primaria que conste de una o más columnas de la tabla. La tabla la clave primaria identifica de manera única cada fila de una tabla y las filas de la tabla se ordenan según la clave primaria. Debido a que Spanner está altamente distribuido, es importante que elijas una técnica de generación de clave primaria que escale con el crecimiento de tus datos. Para obtener más información, consulta las recomendaciones estrategias de migración de claves primarias.
Ten en cuenta que, después de designar tu clave primaria, no podrás agregar ni quitar una columna de clave primaria, ni cambiar un valor de clave primaria más adelante 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.
Intercalar las tablas
Spanner tiene una función 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 permite una unión previa de la tabla y mejora la eficiencia de la recuperación de datos cuando se consultan datos del nivel superior y del 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 en las tablas secundarias para determinar qué sucede cuando se borra la fila superior: se borran todas las filas secundarias o se bloquea 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.
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 de í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 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 Spanner solo usará los índices secundarios de forma automática cuando el índice 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
en la instrucción de SQL, por ejemplo:
SELECT *
FROM MyTable@{FORCE_INDEX=MyTableIndex}
WHERE IndexedColumn=@value
Se pueden usar los índices para aplicar valores únicos dentro de una columna de la tabla; para ello, se define un índice UNIQUE
en esa columna. Este í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 en la creación de índices, consulta Actualizaciones del esquema.
Paso 2: Traduce cualquier consulta en SQL
Spanner usa el dialecto ANSI 2011 de SQL con extensiones y tiene muchas funciones y operadores para ayudarte a traducir y a agregar tus datos. Deberás convertir cualquier consulta de SQL que use sintaxis, funciones y tipos específicos de Oracle para que sea compatible con Spanner.
Si bien Spanner no admite datos estructurados como definiciones de columnas, esos datos se pueden usar en consultas de SQL que usan 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 con anterioridad).
Para obtener más información, consulta la sección Notas sobre las subconsultas de la documentación.
Para ejecutar una consulta de SQL, puedes perfilarla mediante la página de Spanner Studio en la consola de Google Cloud. 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 prácticas recomendadas de SQL para obtener más información sobre cómo optimizar las consultas de SQL.
Paso 3: Migra tu aplicación para usar Spanner
Spanner proporciona un conjunto de bibliotecas cliente para varios lenguajes y la capacidad de leer y escribir datos mediante llamadas a la API específicas de Spanner, así como mediante el uso de consultas de SQL y de instrucciones 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 la conectividad a bases de datos de Java (JDBC) para conectarte a Spanner, lo que te permite aprovechar las herramientas existentes y la infraestructura sin integración nativa.
Como parte del proceso de migración, las funciones que no están disponibles en Spanner deben implementarse en la aplicación. Por ejemplo, si usas un activador para verificar los valores de datos y actualizar una tabla relacionada, tendrás que implementarlo en la aplicación mediante una transacción de lectura y escritura a fin de leer la fila existente, verificar las restricciones y escribir las filas actualizadas en ambas tablas.
Spanner ofrece transacciones de solo lectura y de lectura y escritura, que garantizan la coherencia externa de los datos. Además, se pueden aplicar límites de marca de tiempo a las transacciones de lectura, 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
Paso 4: Transfiere tus datos de Oracle a Spanner
Para transferir tus datos de Oracle a Spanner, deberás exportar la base de datos de Oracle a un formato de archivo portátil (por ejemplo, CSV) y, luego, importar esos datos a Spanner mediante Dataflow.
Exportación 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 Desarrollador de Oracle SQL 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 que se describen en la página Preguntas frecuentes de Oracle, algunas de las cuales pueden descargar una vista coherente de la base de datos completa.
Cuando se hayan descargado, debes subir los archivos de datos a un Cloud Storage de modo que sean accesibles para la importación.
Importa de forma masiva a Spanner
Debido a que puede haber diferencias entre los esquemas de base de datos de Oracle y Spanner, es posible que debas realizar algunas conversiones de datos como parte del proceso de importación.
El uso de Dataflow es la forma más sencilla de realizar estas conversiones y, luego, importar los datos a Spanner.
Dataflow es el servicio de extracción, transformación y carga (ETL) de Google Cloud. Proporciona una plataforma para ejecutar canalizaciones de datos escritas con el SDK de Apache Beam para leer y procesar grandes cantidades de datos en paralelo en múltiples máquinas virtuales.
El SDK de Apache Beam requiere que escribas un programa de Java sencillo para configurar la lectura, la transformación y la escritura de los datos. Existen conectores de Beam para Cloud Storage y Spanner, por lo que el único código que debe escribirse es la transformación de datos.
Consulta un ejemplo de una canalización simple que lee desde archivos CSV y escribe en Spanner en el repositorio de código de muestra que acompaña este artículo.
Si se usan tablas superiores y secundarias intercaladas en el esquema de Spanner, se debe tener cuidado en el proceso de importación para que la fila superior se cree antes que la secundaria. El código de canalización de importación de Spanner se encarga de esto. Para ello, primero importa todos los datos de las tablas de nivel raíz; luego, todas las tablas secundarias de nivel 1; luego, todas las tablas secundarias de nivel 2, y así sucesivamente.
Se puede usar directamente la canalización de importación de Spanner para hacer una importación masiva de tus datos, pero esto requiere que los datos existan en archivos Avro que usen el esquema correcto.
Paso 5: 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, además, importar los datos. Mientras transfieres los datos a Spanner, tu aplicación continúa con la modificación de la base de datos existente. Deberás duplicar las actualizaciones de la base de datos de Spanner mientras la aplicación esté en ejecución.
Existen varios métodos para mantener las 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 (CDC) para tu base de datos de Oracle. Oracle LogMiner o Oracle XStream Out son interfaces alternativas para que la base de datos de Oracle obtenga una transmisión de CDC que no involucre a Oracle GoldenGate.
Puedes escribir una aplicación que se suscriba a una de estas transmisiones y aplique las mismas modificaciones (después de convertir los datos) a tu base de datos de Spanner. Esta aplicación de procesamiento de transmisión debe implementar varias funciones:
- Establecer una conexión con la base de datos de Oracle (base de datos de origen)
- Conéctate a Spanner (base de datos de destino).
- Realizar, de manera reiterada, las siguientes acciones:
- Recibir los datos generados mediante una de las transmisiones de CDC de la base de datos de Oracle
- Interpretar los datos generados mediante la transmisión de CDC
- Convertir los datos en instrucciones
INSERT
de Spanner - Ejecutar las instrucciones
INSERT
de Spanner
La tecnología de migración de bases de datos, que es de tipo middleware, implementó las funciones necesarias como parte de su funcionalidad. La plataforma de migración de bases de datos se instala como un componente independiente en la ubicación de origen o de destino, de acuerdo con los requisitos del cliente. La plataforma de migración de bases de datos solo requiere la configuración de conectividad de las bases de datos involucradas para especificar y comenzar la transferencia de datos continua desde la base de datos de origen hasta la de destino.
Striim es una plataforma de tecnología de migración de bases de datos que está disponible en Google Cloud. Proporciona conectividad a las transmisiones de CDC de Oracle GoldenGate, así como de Oracle LogMiner y Oracle XStream Out. Striim ofrece una herramienta gráfica que te permite configurar la conectividad de la base de datos y las reglas de transformación necesarias para transferir datos de Oracle a Spanner.
Puedes instalar Striim desde Google Cloud Marketplace, conectarte a las bases de datos de origen y destino, implementar reglas de transformación y comenzar a transferir datos sin tener que compilar una aplicación de procesamiento de transmisión.
Realiza actualizaciones de forma simultánea en 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 Spanner.
De esta manera, la aplicación reemplaza de forma constante las filas de Spanner por los datos más recientes.
Una vez que estés seguro de que todos tus datos se transfirieron de manera correcta, podrás cambiar la fuente de información a la base de datos de Spanner.
Este mecanismo proporciona una ruta de reversión si se detectan problemas cuando se realiza el cambio a Spanner.
Verifica la coherencia de los datos
A medida que los datos se transmiten a tu base de datos de Spanner, podrás ejecutar una comparación de forma periódica entre los datos de Spanner y los de Oracle para asegurarte de que sean coherentes.
Para validar la coherencia, puedes consultar ambas fuentes de datos y comparar los resultados.
Puedes usar Dataflow para realizar una comparación detallada en conjuntos de datos grandes mediante la transformación de unión. Esta transformación toma 2 conjuntos de datos con clave y hace coincidir los valores por clave. Luego, los valores pueden compararse para determinar si son iguales.
Puedes ejecutar esta verificación con regularidad hasta que el nivel de coherencia coincida con tus requisitos empresariales.
Paso 6: Cambia a Spanner como fuente de información de tu aplicación
Cuando estés seguro acerca de la migración de datos, puedes cambiar tu aplicación a Spanner como la fuente de información. Continúa reescribiendo los cambios en la base de datos de Oracle para mantenerla actualizada, lo que te brindará 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 cerrarla.
Importa y exporta bases de datos de Spanner
De manera opcional, puedes exportar tus tablas de Spanner a un bucket de Cloud Storage mediante una plantilla de Dataflow para realizar la exportación. La carpeta resultante contiene un conjunto de archivos Avro y archivos de manifiesto JSON que contienen las tablas exportadas. Estos archivos pueden servir para distintos propósitos, incluidos los que se indican a continuación:
- Crear copias de seguridad de tu base de datos para usarlas en la recuperación ante desastres o cumplir con una política de retención de datos
- Importar el archivo Avro a otras ofertas de Google Cloud, como BigQuery
Para obtener más información sobre el proceso de importación y exportación, consulta Cómo exportar bases de datos y Cómo importar bases de datos.
¿Qué sigue?
- Lee la página Optimizar el diseño del esquema para Cloud Spanner.
- Aprende a usar Dataflow para situaciones más complejas.