パーティションテーブルにデータをアーカイブする - AWS 規範ガイダンス

パーティションテーブルにデータをアーカイブする

MySQL は、InnoDB ストレージエンジンのパーティション化に対応しているため、この機能を使用して大規模テーブルをパーティション化できます。テーブル内のパーティションは個別の物理テーブルとして保存されますが、パーティションテーブルに SQL を実行すると、テーブル全体が読み取られます。そのように物理的に分かれていることで、行ごとの削除を行わずにテーブルから不要なパーティションを削除できるため、データベースの履歴行をアーカイブできます。

次のコード例を考察してみましょう。TABLE orders は orderprocessing スキーマ内に存在します。その履歴データは、2021 年以前のデータが含まれる phistorical パーティションにあります。同じテーブルにおいて、アプリケーションレベルのホットデータが 2022 年の各月のライブパーティションに存在します。phistorical パーティション内のデータをアーカイブするには、同じ構造を持つ table orders_2021_and_older アーカイブを archive スキーマ内に作成すると良いでしょう。これにより、MySQL の EXCHANGE PARTITION を使用して、phistorical パーティションをそのテーブルに移動できます。このアーカイブテーブルは、パーティション化されていないことに注意してください。アーカイブが終わったら、そのデータを検証し 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)

この EXCHANGE PARTITION 機能を使用した履歴データのアーカイブには、次のベストプラクティスをお勧めします。

  • アーカイブデータをアプリケーションに保存するための別のスキーマを作成します。このスキーマ内には、アーカイブしたデータを格納するアーカイブテーブルを作成します。アーカイブスキーマのアーカイブテーブルは、インデックスやプライマリキーといったライブテーブルと同じ構造でなければなりません。ただし、ターゲットアーカイブテーブルを、パーティション化することはできません。MySQL では、2 つのパーティションテーブル間でパーティションを交換できないからです。

  • アーカイブテーブルに保存済みの履歴データを識別しやすくなる、アーカイブテーブルの命名規則に従います。これは、監査タスクを実行したり、このデータを Amazon S3 に移動するジョブを設計したりする場合に便利です。

  • Aurora MySQL 互換ライター、Amazon RDS for MySQL、Amazon RDS for MariaDB の各インスタンスに取り込まれるトラフィックがない場合は、ダウンタイムの時間帯に EXCHANGE PARTITION データ定義言語 (DDL) ステートメントを実行します。

    アプリケーションまたはマイクロサービスのトラフィックが少ない時間帯であれば、EXCHANGE PARTITION を実行できる可能性がありますが、パーティションテーブルへの書き込みがまったくなく、テーブル選択がほとんどない状態でなければなりません。また、選択のクエリを長時間実行し続けると、EXCHANGE PARTITION DDL の実行が待機状態になりかねず、これによって、データベースでリソース競合が発生する可能性があります。システムで EXCHANGE PARTITION を実行する前に、こうした条件がすべて満たされていることを確認するスクリプトを作成してください。

アプリケーション設計でパーティションデータがサポートされており、現在、非パーティションテーブルが存在している場合は、データをパーティションテーブルに移動することを検討してください。これにより、データアーカイブに対応できるようになります。詳細については、MySQL ドキュメントを参照してください。