Migra 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 (de ahora en adelante, solo llamada PostgreSQL) a una base de datos de dialecto de PostgreSQL de Spanner (de ahora en adelante, llamada Spanner).

Para obtener información sobre cómo migrar a Spanner y el dialecto GoogleSQL, consulta Migra 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 de Google 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 el método predeterminado para generar valores de clave primaria. La función GENERATE_UUID() (GoogleSQL, PostgreSQL) muestra los valores de la versión 4 de UUID representados como tipo STRING.

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

Para obtener más información, consulta las estrategias de valor predeterminado de la clave primaria.

Controles de acceso

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

Proceso de migración

La migración implica las siguientes tareas:

• Cómo asignar un esquema de PostgreSQL a Spanner
• Traducir consultas en 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
• Migrar tus datos
• Verificar el nuevo sistema y pasarlo al estado de producción

Paso 1: Asigna el 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 compuesta por una o más columnas. La clave primaria de la tabla identifica de manera única cada fila de una tabla y Spanner usa la clave primaria para ordenar las filas de la tabla. Debido a que Spanner está altamente distribuido, es importante que elijas una técnica de generación de clave primaria que se escale bien con el 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 puedes agregar ni quitar una columna de clave primaria, ni cambiar un valor de clave primaria sin borrar y volver a crear la tabla. Si deseas obtener más información para 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 de Spanner. En una base de datos de Spanner, se usan índices secundarios para indexar las columnas que se buscan con frecuencia a fin de obtener un mejor rendimiento y reemplazar cualquier restricción UNIQUE especificada 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
 );

Usarías esta declaració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 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 que se indican en Índices secundarios.

Spanner implementa índices como tablas, por lo que la indexación de columnas que aumentan de forma monótona (como las que contienen datos de TIMESTAMP) puede causar un hotspot. Consulta Lo que los DBA deben saber sobre Spanner, parte 1: Índices y claves a fin de obtener más información sobre los métodos para evitar hotspots.

Spanner implementa índices secundarios de la misma manera que las tablas, por lo que los valores de columna 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 como la siguiente en la instrucción de SQL:

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 Cómo crear y administrar columnas generadas para conocer las diferencias sintácticas y las restricciones.

Intercalado 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 a fin de 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 existan 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 Cómo crear tablas intercaladas.

Tipos de datos

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

Nota: HarbourBridge puede realizar automáticamente algunas de las conversiones que se enumeran en la columna Usar en su lugar. Para obtener más información, consulta HarbourBridge: Spanner Evaluation and Migration.

Tipo de datos	Usar en su lugar
serie grande,serie8	bigint, int8
bit [ (n) ]	-
bit variable [ (n) ], varbit [ (n) ]	-
box	-
character [ (n) ], char [ (n) ]	carácter variable
cidr	texto
circle	-
inet	texto
número entero, int4	bigint, int8
intervalo [campos] [ (p) ]	bigint
json	jsonb
line	-
lseg	-
macaddr	texto
money	numérico, decimal
ruta de acceso	-
pg_lsn	-
point	-
polygon	-
realfloat4	precisión doble, float8
pequeñoint, int2	bigint, int8
serie pequeña, serial2	bigint, int8
serie, serial4	bigint, int8
time [ (p) ] [ without time zone ]	texto con la notación HH:MM:SS.sss
time [ (p) ] con zona horaria	con la notación HH:MM:SS.sss+ZZZZ. También puedes usar dos columnas.
timestamp [ (p) ] [ without time zone ]	texto o timestamptz
tsquery	-
tsvector	-
txid_snapshot	-
uuid	texto o bytea
xml	texto

Paso 2: Traduce cualquier consulta en SQL

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

Las consultas de SQL se pueden perfilar mediante la página de Spanner Studio en la consola de Google Cloud 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. 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 declaraciones 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 declaraciones DDL, úsalas para crear tu base de datos en la instancia de Spanner.

Para obtener más información, consulta:

• Crea y administra instancias
• Crea y administra bases de datos
• Acerca de los esquemas

Paso 4: Refactoriza la aplicación

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

Paso 5: Migra tus datos

Existen dos formas de migrar tus datos:

• Mediante Harbourbridge.

  Harbourbridge admite la migración de esquemas y datos. Puedes importar un archivo pg_dump o un archivo CSV, o bien puedes importarlo a través de una conexión directa a la base de datos PostgreSQL de código abierto.

• Con el comando COPY FROM STDIN

  Si deseas obtener más información, consulta el comando COPY para importar datos.