Arquivamento de dados em tabelas particionadas - AWS Orientação prescritiva

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Arquivamento de dados em tabelas particionadas

O MySQL é compatível com o particionamento para o mecanismo de armazenamento InnoDB, e você pode usar esse recurso para particionar tabelas grandes. As partições dentro da tabela são armazenadas como tabelas físicas separadas, embora o SQL que opera na tabela particionada leia toda a tabela. Isso lhe dá a liberdade de remover partições desnecessárias da tabela sem realizar exclusões linha por linha, para que você possa arquivar linhas históricas em seu banco de dados.

Considere o exemplo de código a seguir. TABLE orders existe dentro do esquema orderprocessing. Seus dados históricos estão presentes na partição phistorical, que contém dados referentes a 2021 e anos anteriores. Na mesma tabela, os dados quentes no nível da aplicação estão presentes nas partições ativas de cada mês de 2022. Para arquivar os dados na partição phistorical, você pode criar um arquivo table orders_2021_and_older com a mesma estrutura no esquema archive. Em seguida, você pode usar EXCHANGE PARTITION do MySQL para mover a partição phistorical para essa tabela. Observe que a tabela de arquivamento não está particionada. Após o arquivamento, você poderá conferir seus dados e transferi-los para o 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)

Quando você usa o recurso EXCHANGE PARTITION para arquivar dados históricos, recomendamos as seguintes práticas:

  • Crie um esquema separado para armazenar dados arquivados em sua aplicação. Esse esquema conterá tabelas de arquivamento que armazenarão dados arquivados. Uma tabela de arquivamento em seu esquema de arquivamento deve ter a mesma estrutura de sua tabela ativa, incluindo seus índices e chave primária. No entanto, a tabela de arquivamento de destino não pode ser uma tabela particionada. A troca de partições entre duas tabelas particionadas não é permitida no MySQL.

  • Siga uma convenção de nomenclatura para sua tabela de arquivamento que ajuda você a identificar os dados históricos armazenados nela. Isso é útil quando você executa tarefas de auditoria ou trabalhos de design que transferem esses dados para o Amazon S3.

  • Execute a instrução EXCHANGE PARTITION de linguagem de definição de dados (DDL) em uma janela de tempo de inatividade quando não houver tráfego entrando em suas instâncias do gravador do Aurora compatível com MySQL, do Amazon RDS para MySQL ou do Amazon RDS para MariaDB.

    Talvez seja possível executar EXCHANGE PARTITION durante janelas de baixo tráfego em sua aplicação ou microsserviço. No entanto, não deve haver nenhuma gravação e nenhuma ou muito poucas seleções na tabela particionada. As consultas de seleção de longa duração existentes podem fazer com que sua DDL EXCHANGE PARTITION espere, causando contenções de recursos em seu banco de dados. Scripts de design que verificam se todas essas condições são atendidas antes da execução de EXCHANGE PARTITION no sistema.

Se o design da sua aplicação for compatível com dados particionados, e você tiver atualmente uma tabela não particionada, considere mover seus dados para tabelas particionadas para ser compatível com o arquivamento de seus dados. Para ter mais informações, consulte a documentação do MySQL.