Archivar datos en tablas particionadas - AWS Guía prescriptiva

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Archivar datos en tablas particionadas

MySQL admiteparticiónpara el motor de almacenamiento InnoDB, y puede utilizar esta función para particionar tablas grandes. Las particiones de la tabla se almacenan como tablas físicas independientes, aunque el SQL que opera en la tabla particionada lee toda la tabla. Esto le da la libertad de eliminar particiones innecesarias de la tabla sin tener que realizar ninguna operaciónrow-by-rowelimina, para que pueda archivar las filas históricas de la base de datos.

Considera el siguiente código de ejemplo.TABLE ordersexiste dentro delorderprocessingesquema. Sus datos históricos están presentes en la particiónphistorical, que contiene datos de 2021 y anteriores. En la misma tabla, los datos activos a nivel de aplicación están presentes en las particiones activas de cada mes de 2022. Para archivar los datos de la particiónphistorical, puedes crear un archivotable orders_2021_and_oldercon la misma estructura enarchiveesquema. A continuación, puede utilizar el MySQLPARTICIÓN DE INTERCAMBIOmover la particiónphistoricalen esa mesa. Tenga en cuenta que la tabla de archivado no está particionada. Tras archivarlos, puede verificar sus datos y moverlos a Amazon S3.

CREATE TABLE orders (
      orderid bigint NOT NULL AUTO_INCREMENT,
      customerid bigint DEFAULT NULL,
      ............
      ............
      order_date date NOT NULL,
      PRIMARY KEY (`orderid`,`order_date`))
    PARTITION BY RANGE (TO_DAYS(order_date)) (
          PARTITION pstart   VALUES LESS THAN (0),
          PARTITION phistorical VALUES LESS THAN (TO_DAYS('2022-01-01')),
          PARTITION p2022JAN VALUES LESS THAN (TO_DAYS('2022-02-01')),
          PARTITION p2022FEB VALUES LESS THAN (TO_DAYS('2022-03-01')),
          PARTITION p2022MAR VALUES LESS THAN (TO_DAYS('2022-04-01')),
          PARTITION p2022APR VALUES LESS THAN (TO_DAYS('2022-05-01')),
          PARTITION p2022MAY VALUES LESS THAN (TO_DAYS('2022-06-01')),
          PARTITION p2022JUN VALUES LESS THAN (TO_DAYS('2022-07-01')),
          PARTITION p2022JUL VALUES LESS THAN (TO_DAYS('2022-08-01')),
          PARTITION p2022AUG VALUES LESS THAN (TO_DAYS('2022-09-01')),
          PARTITION p2022SEP VALUES LESS THAN (TO_DAYS('2022-10-01')),
          PARTITION p2022OCT VALUES LESS THAN (TO_DAYS('2022-11-01')),
          PARTITION p2022NOV VALUES LESS THAN (TO_DAYS('2022-12-01')),
          PARTITION p2022DEC VALUES LESS THAN (TO_DAYS('2023-01-01')),
          PARTITION pfuture       VALUES LESS THAN MAXVALUE
      );
CREATE TABLE orders_2021_and_older (
        orderid bigint NOT NULL AUTO_INCREMENT,
        customerid bigint DEFAULT NULL,
        ............
        ............
        order_date date NOT NULL,
        PRIMARY KEY (`orderid`,`order_date`));
mysql> alter table orderprocessing.orders exchange partition phistorical with table archive.orders_2021_and_older;
  Query OK, 0 rows affected (0.33 sec)

Cuando usa elEXCHANGE PARTITIONfunción para archivar datos históricos, recomendamos las siguientes prácticas recomendadas:

  • Cree un esquema independiente para almacenar los datos archivados en la aplicación. Este esquema contendrá tablas de archivado que albergarán los datos archivados. Una tabla de archivado del esquema de archivado debe tener la misma estructura que la tabla dinámica, incluidos sus índices y su clave principal. Sin embargo, la tabla de archivado de destino no puede ser una tabla particionada. El intercambio de particiones entre dos tablas particionadas no está permitido en MySQL.

  • Siga una convención de nomenclatura para la tabla de archivado que le ayude a identificar los datos históricos almacenados en ella. Esto resulta útil cuando realiza tareas de auditoría o trabajos de diseño que transfieren estos datos a Amazon S3.

  • Realice elEXCHANGE PARTITIONsentencia de lenguaje de definición de datos (DDL) en una ventana de tiempo de inactividad cuando no hay tráfico en sus instancias de escritor compatible con Aurora MySQL, Amazon RDS para MySQL o Amazon RDS para MariaDB.

    Podría ser posible ejecutarEXCHANGE PARTITIONdurante las ventanas de poco tráfico de su aplicación o microservicio. Sin embargo, no debe haber escrituras ni seleccionar ninguna o muy pocas selecciones en la tabla particionada. Las consultas selectas existentes y de larga duración pueden provocar queEXCHANGE PARTITIONDDL espera, lo que provoca una contención de recursos en la base de datos. Diseñe scripts que comprueben que se cumplen todas estas condiciones antes de ejecutarlasEXCHANGE PARTITIONen su sistema.

Si el diseño de su aplicación admite datos particionados y actualmente tiene una tabla sin particiones, considere la posibilidad de mover los datos a tablas particionadas para poder archivarlos. Para obtener más información, consulte la documentación de MySQL.