Migra de PostgreSQL a Spanner (dialecto de PostgreSQL)

En esta página, se explica cómo migrar una base de datos PostgreSQL de código abierto (de ahora en adelante, solo PostgreSQL) a un Base de datos de dialectos de PostgreSQL de Spanner (de ahora en adelante, conocida como Spanner).

Para obtener información sobre migrar a Spanner y al dialecto GoogleSQL, consulta Migra desde 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 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 inversas de bits (GoogleSQL, PostgreSQL), que producen que se distribuyen de manera uniforme en el espacio numérico positivo de 64 bits. Puedes usa estos números para evitar problemas de generación de hotspots.

Para obtener más información, consulta las estrategias de valor predeterminadas de claves primarias.

Controles de acceso

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

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
  • Migrar tus datos
  • Verificar el nuevo sistema y pasarlo al estado de producción

Paso 1: Asigna el esquema de PostgreSQL a Spanner

Tu primer paso para trasladar una base de datos de PostgreSQL de código abierto a Spanner determina 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 de la tabla La tabla la clave primaria identifica de manera única cada fila de una tabla, y Spanner usa la clave primaria para ordenar las filas de la tabla. Dado que Spanner es altamente distribuidas, es importante que elijas una generación de clave primaria que se adapte bien al crecimiento de tus datos. Para obtener más información, consulta la estrategias de migración de clave primaria que recomendamos.

Ten en cuenta que después de designar tu clave primaria, no podrás agregar ni quitar una columna de clave primaria o cambiar un valor de clave primaria más adelante sin borrar ni volver a crear la tabla. Para obtener más información sobre cómo designar tu clave primaria, consulta Esquema y modelo de datos: primario claves.

Índices

PostgreSQL índices del árbol b son similares a los índices secundarios en Spanner En una base de datos de Spanner, usas índices secundarios para las columnas más buscadas para obtener un mejor rendimiento y reemplazar Restricciones de 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
 );

Debes usar esta instrucción en el 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.

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 la indexación las columnas crecientes (como las que contienen datos de TIMESTAMP) pueden causar un hotspot. Consulta Lo que los DBA necesitan saber sobre Spanner, parte 1: índices y claves para obtener más información sobre los métodos para evitar hotspots.

Spanner implementa los í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 como 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 columna de la tabla original en el índice secundario con INCLUDE, por lo que es una í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 del original en una tabla, 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 o y borrar datos. Para obtener más información, consulta Vistas.

Columnas generadas

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

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 de ON DELETE 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      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 es compatible con la interfaz de PostgreSQL para Spanner.

Tipo de datos Usar en su lugar
bigserial,serial8 int8 y bigint
bit [ (n) ] -
bit variable [ (n) ], varbit [ (n) ] -
box -
character [ (n) ], char [ (n) ] carácter variable
cidr texto
circle -
inet texto
número entero, int4 int8 y bigint
intervalo [campos] [ (p) ] bigint
json jsonb
line -
lseg -
macaddr texto
money numérico, decimal
ruta -
pg_lsn -
point -
polygon -
realfloat4 doble precisión, float8
Smallint, int2 int8 y bigint
smallserial, serial2 int8 y bigint
serie, serie 4 int8 y bigint
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 utiliza dos columnas.
timestamp [ (p) ] [ without time zone ] texto o timestamptz
tsquery -
tsvector -
txid_snapshot -
uuid texto o bytesa
xml texto

Paso 2: Traduce cualquier consulta en SQL

Spanner tiene muchos de los servicios de PostgreSQL funciones disponibles para reducir la carga de conversiones.

Las consultas en SQL se pueden perfilar con la página de Spanner Studio en a 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 la optimización de consultas en SQL, lee el Prácticas recomendadas sobre SQL en la documentación de Google Cloud.

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

Crea la instancia y una base de datos en PostgreSQL dialecto. Luego, crea tu esquema con la definición de datos de PostgreSQL de lenguaje natural (DDL).

Usa pg_dump para crear sentencias DDL que definan los objetos en tu base de datos de PostgreSQL y, luego, modifica las sentencias como se describe en el secciones anteriores. Después de actualizar las declaraciones DDL, usa las declaraciones DDL 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 aplicación para dar cuenta del esquema modificado y el SQL revisado 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 maneras de migrar tus datos:

  • Mediante Harbourbridge.

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

  • Mediante el comando COPY FROM STDIN

    Si deseas obtener más detalles, consulta el comando COPY para importar datos.