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

Suporte ao MySQLparticionamentopara 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 a tabela inteira. Isso lhe dá a liberdade de remover partições desnecessárias da tabela sem executarrow-by-rowexclui, para que você possa arquivar linhas históricas em seu banco de dados.

Considere o código de exemplo a seguir.TABLE ordersexiste dentro doorderprocessingesquema. Seus dados históricos estão presentes na partiçãophistorical, que contém dados pertencentes a 2021 e anteriores. Na mesma tabela, os dados ativos em nível de aplicativo estão presentes nas partições ativas de cada mês de 2022. Para arquivar os dados na partiçãophistorical, você pode criar um arquivotable orders_2021_and_oldercom a mesma estrutura noarchiveesquema. Você pode então usar o MySQLPARTIÇÃO DE TROCApara mover a partiçãophistoricalnaquela mesa. Observe que a tabela de arquivamento não está particionada. Após o arquivamento, você pode verificar seus dados e movê-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 oEXCHANGE PARTITIONrecurso para arquivar dados históricos, recomendamos as seguintes práticas recomendadas:

  • Crie um esquema separado para armazenar dados arquivados em seu aplicativo. Esse esquema conterá tabelas de arquivamento que armazenarão os dados arquivados. Uma tabela de arquivamento em seu esquema de arquivamento deve ter a mesma estrutura da sua tabela dinâmica, 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 o ajude a identificar os dados históricos armazenados nela. Isso é útil quando você executa tarefas de auditoria ou trabalhos de design que movem esses dados para o Amazon S3.

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

    Talvez seja possível executarEXCHANGE PARTITIONdurante janelas de baixo tráfego em seu aplicativo ou microsserviço. No entanto, não deve haver gravações e nenhuma ou muito poucas seleções na tabela particionada. As consultas selecionadas existentes e de longa duração podem fazer com queEXCHANGE PARTITIONDDL aguarde, causando contenções de recursos em seu banco de dados. Crie scripts que verificam que todas essas condições foram atendidas antes da execuçãoEXCHANGE PARTITIONem seu sistema.

Se o design do seu aplicativo pode suportar dados particionados e você atualmente tem uma tabela não particionada, considere mover seus dados para tabelas particionadas para suportar o arquivamento de seus dados. Para obter mais informações, consulte a documentação do MySQL.