DALL·E 2024 03 10 19.58.48 Imagine a 1024x1024 pixels illustration that showcases a comparison between partitioning by reference in Oracle and PostgreSQL. The image should depic

Particionado por referencia: Migración Oracle a PostgreSQL

El otro día hablábamos con un cliente que quería migrar desde su Oracle 12c a Postgres.

Todo iba bien hasta que nos encontramos una tabla particionada por referencia…

En ese momento nos dimos cuenta de que habíamos pasado algo por alto. ¡No existe el particionamiento por referencia en Postgres!

Podemos particionar por Hash, por rango, por listas… pero no por referencia. Y eso nos lleva al artículo de hoy, donde os enseñamos cómo lo hicimos para emular este funcionamiento.

¿Qué es particionar por referencia?

La partición por referencia, también conocida como partición basada en referencias, es una técnica de particionado que utiliza una columna dentro de una tabla ajena a la que se está particionando como clave de partición.

Dicho así puede quedar un poco lioso, pero vais a entenderlo enseguida.

  • Tienes una tabla que estás particionando. Eso significa que los datos se dividen en múltiples particiones. Se reparten en trocitos, por así decirlo.
  • Para repartirse y saber qué datos van en qué trocito se mira un valor específico de una columna.
  • Este valor y esta columna no están en la tabla que estamos dividiendo. De ahí que lo llamemos «particionado por referencia».

Veamos un ejemplo:

CREATE TABLE pedido (
        pedido_id         NUMBER(12),
        pedido_fecha       DATE,
        pedido_estado     NUMBER(2),
        CONSTRAINT pedido_pk PRIMARY KEY(pedido_id)
)
PARTITION BY RANGE(pedido_fecha) (
        PARTITION Q1_2025 VALUES LESS THAN (TO_DATE('01-APR-2025','DD-MON-YYYY')),
        PARTITION Q2_2025 VALUES LESS THAN (TO_DATE('01-JUL-2025','DD-MON-YYYY')),
        PARTITION Q3_2025 VALUES LESS THAN (TO_DATE('01-OCT-2025','DD-MON-YYYY')),
        PARTITION Q4_2025 VALUES LESS THAN (TO_DATE('01-JAN-2026','DD-MON-YYYY'))
);

CREATE TABLE articulos (
        pedido_id         NUMBER(12) NOT NULL,
        item_id            NUMBER(3)  NOT NULL,
        product_id       NUMBER(6)  NOT NULL,
        precio          NUMBER(8,2),
        cantidad           NUMBER(4),
        CONSTRAINT pedidos_fk FOREIGN KEY(pedido_id) REFERENCES pedido(pedido_id)
)
PARTITION BY REFERENCE(pedidos_fk);

La tabla pedidos tiene una columna con la fecha del pedido que hemos usado para particionarla. Luego tenemos la tabla articulos donde tenemos detalles sobre los elementos que van en el pedido.

Imagina que queremos saber en qué fecha se retiraron artículos de nuestro stock, pero por temas de diseño y normalización de datos no hemos almacenado ese dato.

Aquí entra en juego la partición por referencia, donde utilizamos la clave foránea a la tabla de pedidos para usar su campo de fecha como valor condicionante.

Partición por referencia en Oracle

En Oracle se puede particionar por referencia desde la versión 11g. La partición por referencia se puede implementar en Oracle con las siguientes cláusulas:

PARTITION BY REFERENCE: especifica que se particiona por referencia.
PARTITION REFERENCE: indica la columna de referencia.
TABLESPACE: permite especificar un tablespace diferente para cada partición.

Oracle también soporta la partición por referencia compuesta, que significa que una tabla se puede particionar utilizando más de una columna de referencia en lugar de sólo una.

Partición por referencia en PostgreSQL

Como ya os adelantamos, en PostgreSQL no está esta funcionalidad como tal así que tendremos que explorar varias opciones.

Opción 1 – No particionar

Una de las opciones predeterminadas que tenemos en Ora2Pg cuando estamos haciendo el export de Oracle es la de no particionar la tabla secundaria.

Podemos encontrar esta opción en el archivo de configuración como PARTITION_BY_REFERENCE none.

Con esto conseguimos migrar las tablas sin errores, pero no conseguimos la funcionalidad que teníamos en Oracle.

Opción 2 – Duplicar la columna referenciada en la tabla destino

¿Os acordáis en el ejemplo de arriba cuándo decíamos que por temas de diseño y normalización de datos no queríamos duplicar la columna con el campo fecha?

Pues eso es justo lo que haríamos en esta solución, aplicando exactamente el mismo tipo de particionamiento a ambas tablas.

Esto implica que perdemos algunas funcionalidades automáticas y tendríamos que comparar en cláusulas WHERE ambos campos de fecha, pero es un funcionamiento bastante similar a lo que teníamos en Oracle.

Para que Ora2Pg haga esto automáticamente usaremos la opción PARTITION_BY_REFERENCE duplicate.

Conclusión

La partición por referencia es una técnica útil para mejorar la eficiencia del rendimiento de las operaciones de consulta y escritura en una base de datos.

Cuando pasamos de Oracle a PostgreSQL nos encontramos con la situación de tener que recrear esta funcionalidad a través de distintas formas y opciones en Ora2Pg.

En el artículo de hoy hemos explicado 2 formas para hacerlo, pero dependerá de ti y del entorno que utilices el saber cuál es la mejor de las dos.

Únete a la lista de emails para no perderte nada

No tengo ningún producto, publicidad, ni nada que venderte. De hecho, aún no tengo nada que hacer con estos emails. Pero si te interesa estar en contacto o no perderte las próximas actualizaciones en el futuro… Ya sabes 😉

    ¿Quieres trabajar con nosotros?

    Ya sea que necesites mejorar el rendimiento de consultas existentes, planificar y ejecutar migraciones de datos críticas, diseñar bases de datos desde cero o mantener un entorno de base de datos estable, estamos aquí para ayudarte.

    Trabajamos con una amplia variedad de sistemas de gestión de bases de datos (DBMS) y estamos comprometidos en proporcionar soluciones adaptadas a tus necesidades específicas. Puedes consultar nuestra lista completa de servicios aquí.

    Confía en nosotros para optimizar tus bases de datos y liberar tiempo y recursos para que puedas concentrarte en lo que realmente importa: hacer crecer tu negocio.

    ¡Contáctanos hoy mismo y descubre cómo podemos ayudarte a lograr un rendimiento óptimo en tu entorno de bases de datos!


    Comentarios

    Deja una respuesta

    Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *