分割テーブルへのデータのアーカイブ - AWS 規範ガイダンス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

分割テーブルへのデータのアーカイブ

MySQL はサポートしています分割InnoDB ストレージエンジン用で、この機能を使用して大きなテーブルを分割できます。テーブル内のパーティションは個別の物理テーブルとして格納されますが、分割されたテーブルを操作する SQL はテーブル全体を読み取ります。これにより、実行せずにテーブルから不要なパーティションを自由に削除できます。row-by-rowを削除して、データベース内の履歴行をアーカイブできるようにします。

次のコード例を考えてみましょう。TABLE orders内に存在するorderprocessingスキーマ。その履歴データはパーティションにありますphistorical には、2021 年以前のデータが含まれています。同じ表では、アプリケーションレベルのホットデータが、2022年の各月のライブパーティションにあります。パーティション内のデータをアーカイブするにはphistorical、アーカイブを作成できますtable orders_2021_and_older同じ構造でarchiveスキーマ。その後、MySQL を使用できます。パーティションの交換パーティションを移動するには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 に移動する監査タスクや設計ジョブを実行する場合に便利です。

  • を実行してくださいEXCHANGE PARTITIONAurora MySQL 互換ライター、MySQL 用 Amazon RDS、または MariaDB 用の Amazon RDS インスタンスにトラフィックが入らない場合に、ダウンタイムウィンドウに表示されるデータ定義言語 (DDL) ステートメント。

    実行できるかもしれませんEXCHANGE PARTITIONアプリケーションまたはマイクロサービスのトラフィックの少ない時間帯に ただし、パーティションテーブルには書き込みや選択は行わないか、ごくわずかであるはずです。実行時間の長い既存の select クエリが原因でEXCHANGE PARTITIONDDL が待機しているため、データベース上でリソース競合が発生しています。実行前にこれらの条件がすべて満たされていることを確認するデザインスクリプトEXCHANGE PARTITIONお使いのシステム上。

アプリケーションの設計が分割データに対応していて、現在分割されていないテーブルがある場合は、データのアーカイブをサポートするためにデータを分割テーブルに移動することを検討してください。詳細については、MySQL ドキュメントを参照してください。