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 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 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 UUID versión 4 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 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
- 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 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 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: Claves primarias.
Í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 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 la indexación
las columnas crecientes (como las que contienen datos de TIMESTAMP) pueden causar 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 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 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 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 admite la interfaz de PostgreSQL para Spanner.
| Tipo de datos | Usar en su lugar |
|---|---|
| bigserial,serial8 | bigint, int8 |
| bit [ (n) ] | - |
| bit variable [ (n) ], varbit [ (n) ] | - |
| box | - |
| character [ (n) ], char [ (n) ] | character varying |
| cidr | texto |
| circle | - |
| inet | texto |
| número entero, int4 | bigint, int8 |
| interval [fields] [ (p) ] | bigint |
| json | jsonb |
| line | - |
| lseg | - |
| macaddr | texto |
| money | numérico, decimal |
| ruta | - |
| pg_lsn | - |
| point | - |
| polygon | - |
| realfloat4 | precisión doble, 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 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 cualquier consulta en SQL
Spanner tiene muchas de las funciones de código abierto de PostgreSQL disponibles para ayudar a reducir la carga de conversión.
Las consultas en SQL se pueden perfilar usando 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 el dialecto de PostgreSQL. Luego, crea tu esquema con el lenguaje de definición de datos (DDL) de PostgreSQL.
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 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:
Con 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.
Usa el comando
COPY FROM STDIN.Si deseas obtener más detalles, consulta el comando COPY para importar datos.