Migra de PostgreSQL a Spanner (dialecto de PostgreSQL)

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

Para obtener información sobre cómo migrar a Spanner y el dialecto de GoogleSQL, consulta Cómo migrar de PostgreSQL a Spanner (dialecto de GoogleSQL).

Restricciones de migración

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 la arquitectura de la aplicación para aprovechar al máximo sus capacidades. Es posible que también debas complementar Spanner con otros servicios deGoogle Cloud para satisfacer tus necesidades.

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, se debe trasladar la lógica empresarial que implementaron los activadores y los procedimientos almacenados a nivel de base de datos a la aplicación.

Secuencias

Spanner recomienda 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 representados como tipo STRING.

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

Para obtener más información, consulta estrategias de valores predeterminados de claves primarias.

Controles de acceso

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

Proceso de migración

La migración incluye las siguientes tareas:

  • Asignar un esquema de PostgreSQL a Spanner
  • Traducción de consultas de SQL
  • Crear una instancia, una base de datos y un esquema de Spanner
  • Reestructurar la aplicación para que funcione con tu base de datos de Spanner
  • Migrar tus datos
  • Verificar el nuevo sistema y pasarlo al estado de producción

Paso 1: Asigna tu esquema de PostgreSQL a Spanner

El primer paso para mover una base de datos de PostgreSQL de código abierto a Spanner es determinar qué cambios de esquema debes realizar.

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 clave primaria de tu tabla identifica de forma única cada una de sus filas, y Spanner usa la clave primaria para ordenar las filas de la tabla. Debido a que Spanner está muy distribuido, es importante que elijas una técnica de generación de claves principales que se ajuste bien al crecimiento de tus datos. Para obtener más información, consulta las estrategias de migración de claves primarias que recomendamos.

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.

Índices

Los índices b-tree de PostgreSQL son similares a los índices secundarios en Spanner. En una base de datos de Spanner, utiliza índices secundarios para indexar las columnas más buscadas con el fin de mejorar el rendimiento y reemplazar las restricciones UNIQUE especificadas en tus 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 sentencia 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 si ejecutas el meta-comando \di en psql.

Después de determinar los índices que necesitas, agrega instrucciones CREATE INDEX para crearlos. Sigue las instrucciones en Índices secundarios.

Spanner implementa índices como tablas, por lo que indexar columnas que aumentan de forma monótona (como las que contienen datos TIMESTAMP) puede generar un hotspot. Para obtener más información sobre los métodos para evitar hotspots, consulta el artículo Lo que los DBA necesitan saber sobre Spanner, parte 1: Índices y claves.

Spanner implementa índices secundarios de la misma manera que las tablas, por lo que los valores de columnas que se usarán como claves de índice tendrán 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 INCLUDE, lo que la convierte en un índice de cobertura.

El optimizador de consultas de Spanner solo usa un índice secundario de manera automática cuando el índice almacena 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=$1;

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);

Si creas índices adicionales después de que se cargan los datos, es posible que lleve un poco de tiempo para propagarse. Te recomendamos que limites la frecuencia con la que los agregas 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.

Vistas

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

Columnas generadas

Spanner admite columnas generadas. Consulta Crea y administra columnas generadas para conocer las diferencias y restricciones de sintaxis.

Intercalación de tablas

Spanner tiene una función que te permite definir una relación de superior y secundario de tipo uno a varios entre dos tablas. Esta función intercala las filas de datos secundarias con las filas superiores en el almacenamiento, lo 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 ON DELETE 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      bigint,
 AlbumID       bigint,
 AlbumTitle    varchar,
 PRIMARY KEY (SingerID, AlbumID)
 )
 INTERLEAVE IN PARENT Singers ON DELETE CASCADE;

Para obtener más información, consulta Crea 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 de PostgreSQL para Spanner.

Tipo de datos Usa en su lugar
bigserial,serial8 bigint, int8
bit [ (n) ] -
bit varying [ (n) ], varbit [ (n) ] -
caja -
character [ (n) ], char [ (n) ] character varying
cidr texto
circle -
inet texto
número entero, int4 bigint, int8
interval [fields] [ (p) ] bigint
json jsonb
línea -
lseg -
macaddr texto
money numérico, decimal
ruta de acceso -
pg_lsn -
point -
polygon -
realfloat4 precisión doble, 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
time [ (p) ] with time zonetimetz texto, con la notación HH:MM:SS.sss+ZZZZ. O bien usa dos columnas.
timestamp [ (p) ] [ without time zone ] texto o timestamptz
tsquery -
tsvector -
txid_snapshot -
uuid texto o bytea
xml texto

Paso 2: Traduce las consultas de SQL que uses

Spanner tiene muchas de las funciones de código abierto de PostgreSQL disponibles para ayudar a reducir la carga de conversió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. Para obtener más información sobre cómo optimizar las consultas de SQL, consulta la documentación de prácticas recomendadas de 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. Luego, crea tu esquema con el lenguaje de definición de datos (DDL) de PostgreSQL.

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

Para obtener más información, consulte:

Paso 4: Refactoriza la aplicación

Agrega lógica de la aplicación para tener en cuenta el esquema modificado y las consultas SQL revisadas, y para reemplazar la lógica residente en la base de datos, como los procedimientos y los activadores.

Paso 5: Migra tus datos

Existen dos maneras de migrar tus datos: