Migrar de PostgreSQL a Spanner (dialecto PostgreSQL)

En esta página se explica cómo migrar una base de datos de PostgreSQL de código abierto (en adelante, PostgreSQL) a una base de datos de dialecto PostgreSQL de Spanner (en adelante, Spanner).

Para obtener información sobre cómo migrar a Spanner y al dialecto GoogleSQL, consulta el artículo Migrar de PostgreSQL a Spanner (dialecto GoogleSQL).

Restricciones de migración

Spanner usa ciertos conceptos de forma diferente a otras herramientas de gestión de bases de datos empresariales, por lo que es posible que tengas que ajustar la arquitectura de tu aplicación para aprovechar al máximo sus funciones. También es posible que tengas que complementar Spanner con otros servicios deGoogle Cloud para satisfacer tus necesidades.

Procedimientos almacenados y activadores

Spanner no admite la ejecución de código de usuario a nivel de base de datos, por lo que, como parte de la migración, la lógica empresarial implementada por los procedimientos y los activadores almacenados a nivel de base de datos se debe mover a la aplicación.

Secuencias

Spanner recomienda usar la versión 4 de UUID como método predeterminado para generar valores de clave principal. La función GENERATE_UUID() (GoogleSQL, PostgreSQL) devuelve valores de la versión 4 de UUID representados como tipo STRING.

Si necesitas generar valores enteros, Spanner admite secuencias positivas invertidas por bits (GoogleSQL y PostgreSQL), que producen valores que se distribuyen de forma uniforme en el espacio de números positivos de 64 bits. Puedes usar estos números para evitar problemas de hotspotting.

Para obtener más información, consulte las estrategias de valor predeterminado de clave principal.

Controles de acceso

Spanner admite el control de acceso pormenorizado a nivel de tabla y de columna. No se admite el control de acceso pormenorizado para las vistas. Para obtener más información, consulta Información sobre el control de acceso pormenorizado.

Proceso de migración

La migración implica las siguientes tareas:

• Asignar un esquema de PostgreSQL a Spanner.
• Traducir consultas de SQL.
• Crear una instancia, una base de datos y un esquema de Spanner.
• Refactorizar la aplicación para que funcione con tu base de datos de Spanner.
• Migrando tus datos.
• Verificar el nuevo sistema y cambiarlo al estado de producción.

Paso 1: Asigna tu esquema de PostgreSQL a Spanner

El primer paso para migrar una base de datos de PostgreSQL de código abierto a Spanner es determinar qué cambios de esquema debe hacer.

Claves principales

En Spanner, todas las tablas que deban almacenar más de una fila deben tener una clave principal compuesta por una o varias columnas de la tabla. La clave principal de una tabla identifica de forma única cada fila de la tabla y Spanner la usa para ordenar las filas de la tabla. Como Spanner está muy distribuido, es importante que elijas una técnica de generación de claves principales que se adapte bien al crecimiento de tus datos. Para obtener más información, consulta las estrategias de migración de claves principales que recomendamos.

Ten en cuenta que, después de designar la clave principal, no podrás añadir ni quitar una columna de clave principal, ni cambiar el valor de una clave principal más adelante sin eliminar y volver a crear la tabla. Para obtener más información sobre cómo designar tu clave principal, consulta Esquema y modelo de datos: claves principales.

Índices

Los índices de árbol B de PostgreSQL son similares a los índices secundarios de Spanner. En una base de datos de Spanner, se usan índices secundarios para indexar las columnas que se buscan con frecuencia y así mejorar el rendimiento, así como para sustituir las restricciones UNIQUE especificadas en las tablas. Por ejemplo, si tu DDL de PostgreSQL tiene esta instrucción:

 CREATE TABLE customer (
    id CHAR (5) PRIMARY KEY,
    first_name VARCHAR (50),
    last_name VARCHAR (50),
    email VARCHAR (50) UNIQUE
 );

Puedes usar la siguiente instrucción en tu DDL de Spanner:

CREATE TABLE customer (
   id VARCHAR(5) PRIMARY KEY,
   first_name VARCHAR(50),
   last_name VARCHAR(50),
   email VARCHAR(50)
   );

CREATE UNIQUE INDEX customer_emails ON customer(email);

Puedes encontrar los índices de cualquiera de tus tablas de PostgreSQL ejecutando el \di metacomando en psql.

Una vez que hayas determinado los índices que necesitas, añade instrucciones CREATE INDEX para crearlos. Sigue las instrucciones de la sección Índices secundarios.

Spanner implementa los índices como tablas, por lo que indexar columnas que aumentan de forma monótona (como las que contienen datos TIMESTAMP) puede provocar un punto de acceso. Consulta el artículo Lo que los administradores de bases de datos deben saber sobre Spanner (parte 1): claves e índices para obtener más información sobre los métodos para evitar los puntos de acceso.

Spanner implementa los índices secundarios de la misma forma que las tablas, por lo que los valores de las columnas que se utilicen como claves de índice tendrán las mismas restricciones que las claves principales de las tablas. Esto también significa que los índices tienen las mismas características de coherencia que las tablas de Spanner.

Las búsquedas de valores que usan índices secundarios son prácticamente iguales a una consulta con una combinación de tablas. Puede mejorar el rendimiento de las consultas mediante índices almacenando copias de los valores de las columnas de la tabla original en el índice secundario con la cláusula INCLUDE, lo que lo convierte en un índice de cobertura.

Es más probable que el optimizador de consultas de Spanner use un índice secundario cuando el propio índice almacene todas las columnas de la consulta (una consulta cubierta). Para forzar el uso de un índice al consultar columnas que no están almacenadas en el índice, debes usar una directiva FORCE INDEX en la instrucción SQL. Por ejemplo:

SELECT *
FROM MyTable /*@ FORCE_INDEX=MyTableIndex */
WHERE IndexedColumn=$1;

A continuación, se muestra un ejemplo de una instrucción DDL que crea un índice secundario para la tabla Albums:

CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);

Si creas índices adicionales después de cargar los datos, puede que tarde un tiempo en rellenarse el índice. Te recomendamos que limites la frecuencia con la que los añades a una media de tres al día. Para obtener más información sobre cómo crear índices secundarios, consulta el artículo Índices secundarios. Para obtener más información sobre las limitaciones de la creación de índices, consulta Actualizaciones de esquemas.

Vistas

Las vistas de Spanner son de solo lectura. No se pueden usar para insertar, actualizar ni eliminar datos. Para obtener más información, consulta Visualizaciones.

Columnas generadas

Spanner admite columnas generadas. Consulta Crear y gestionar columnas generadas para ver las diferencias y las restricciones de sintaxis.

Intercalado de tablas

Spanner tiene una función que permite definir que dos tablas tengan una relación entre un elemento superior y varios secundarios. Esta función intercala las filas de datos secundarios junto a su fila principal en el almacenamiento, lo que permite combinar la tabla previamente y mejorar la eficiencia de la recuperación de datos cuando se consultan la tabla principal y las secundarias juntas.

La clave principal de la tabla secundaria debe empezar por las columnas de clave principal de la tabla superior. Desde la perspectiva de la fila secundaria, la clave principal de la fila superior se denomina clave externa. Puede definir hasta 6 niveles de relaciones entre elementos principales y secundarios.

Puedes definir ON DELETE acciones para las tablas secundarias con el fin de determinar qué ocurre cuando se elimina la fila principal: se eliminan todas las filas secundarias o se bloquea la eliminación de la fila principal mientras existan filas secundarias.

A continuación se muestra un ejemplo de cómo crear una tabla Albums intercalada en la tabla Singers principal definida anteriormente:

CREATE TABLE Albums (
 SingerID      bigint,
 AlbumID       bigint,
 AlbumTitle    varchar,
 PRIMARY KEY (SingerID, AlbumID)
 )
 INTERLEAVE IN PARENT Singers ON DELETE CASCADE;

Para obtener más información, consulta Crear tablas intercaladas.

Tipos de datos

En la siguiente tabla se enumeran los tipos de datos de PostgreSQL de código abierto que no admite la interfaz PostgreSQL para Spanner.

Nota: La herramienta de migración de Spanner puede hacer automáticamente algunas de las conversiones que se indican en la columna Usar en su lugar. Para obtener más información, consulta Evaluación y migración de la herramienta de migración de Spanner.

Tipo de datos	Usar en su lugar
bigserial,serial8	bigint, int8
bit [ (n) ]	-
bit varying [ (n) ], varbit [ (n) ]	-
de correos	-
carácter [ (n) ], char [ (n) ]	character varying
cidr	texto
círculo	-
inet	texto
entero, int4	bigint, int8
interval [fields] [ (p) ]	bigint
json	jsonb
línea	-
lseg	-
macaddr	texto
dinero	numérico, decimal
ruta	-
pg_lsn	-
punto	-
Polígono	-
realfloat4	Doble precisión, float8
smallint, int2	bigint, int8
smallserial, serial2	bigint, int8
serial, serial4	bigint, int8
time [ (p) ] [ without time zone ]	texto, con la notación HH:MM:SS.sss
hora [ (p) ] con zona horariatimetz	texto, con la notación HH:MM:SS.sss+ZZZZ. También puedes usar dos columnas.
timestamp [ (p) ] [ without time zone ]	text o timestamptz
tsquery	-
tsvector	-
txid_snapshot	-
uuid	text o bytea
xml	texto

Paso 2: Traduce las consultas de SQL

Spanner tiene muchas de las funciones de PostgreSQL de código abierto disponibles para ayudar a reducir la carga de conversión.

Las consultas SQL se pueden perfilar mediante la página Spanner Studio de la Google Cloud consola para ejecutar la consulta. En general, las consultas que realizan análisis de tabla completa en tablas grandes son muy costosas y deben usarse con moderación. Para obtener más información sobre cómo optimizar las consultas de SQL, consulta la documentación sobre prácticas recomendadas para SQL.

Paso 3: Crea la instancia, la base de datos y el esquema de Spanner

Crea la instancia y una base de datos en el dialecto de PostgreSQL. A continuación, crea el esquema con el lenguaje de definición de datos (DDL) de PostgreSQL.

Usa pg_dump para crear instrucciones DDL que definan los objetos de tu base de datos PostgreSQL y, a continuación, modifica las instrucciones como se describe en las secciones anteriores. Después de actualizar las instrucciones DDL, úsalas para crear tu base de datos en la instancia de Spanner.

Para obtener más información, consulta estos artículos:

• Crear y gestionar instancias
• Crear y gestionar bases de datos
• Acerca de los esquemas

Paso 4: Refactorizar la aplicación

Añade lógica de aplicación para tener en cuenta el esquema modificado y las consultas SQL revisadas, así como para sustituir la lógica residente en la base de datos, como los procedimientos y los activadores.

Paso 5: Migra tus datos

Hay dos formas de migrar tus datos:

• Usando la herramienta de migración de Spanner.

  La herramienta de migración de Spanner admite la migración de esquemas y datos. Puedes importar un archivo pg_dump o un archivo CSV, o bien importar datos mediante una conexión directa a la base de datos de código abierto PostgreSQL.

• Usando el comando COPY FROM STDIN.

  Para obtener más información, consulta el artículo sobre el comando COPY para importar datos.