原文: 🚀 Lightning-Fast Archiving in MySQL HeatWave Using Table Partition Exchange
大規模なデータセットの管理では、パフォーマンスとストレージのバランスを取ることが重要です。「ホット」データをスリムに保つことは、速度とメモリ効率に不可欠です。一方で、保持が必要な「コールド」データはどのように扱えばよいでしょうか。
Partition Exchange Archiving は、行を書き換えたり大規模なロックを発生させたりすることなく、古いデータをプライマリ・テーブルから即座に移動できる、シンプルで本番環境向けの戦略です。スマートにアーカイブするための方法です。
🔥 MySQL HeatWaveとは
MySQL HeatWave は、トランザクション、分析、Lakehouse、機械学習、生成AIを、MySQL互換の単一エンジンに統合したフルマネージドのMySQLサービスです。超並列のインメモリ・エンジンを使用して分析クエリを高速化し、個別のETLパイプラインや外部データ・ウェアハウスを不要にします。
🧠 戦略: メタデータのみのアーカイブ
このパターンでは、MySQLが持つ、テーブル・パーティションを非パーティション・テーブルと交換する機能を活用します。物理的な行コピーを伴わないメタデータのみの操作であるため、高速です。
大まかな流れは次のとおりです。
- テーブルを
RANGE(order_date)でパーティション化する - 古いパーティションをアーカイブ・テーブルと交換する
- アーカイブをディスクまたはオブジェクト・ストレージへダンプする（バックアップ手順）
- アーカイブ済みテーブルを
TRUNCATEする（クリーンアップ手順）
⚙️ ステップごとの実装
✅ 1. パーティション化テーブルを作成する
まず、ライブの orders テーブルを定義し、order_date を基準に月単位でパーティション化します。ここでは、構成をシンプルに保つために単一の AUTO_INCREMENT 主キーを使用します。
SQL:
CREATE TABLE orders (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
order_date DATE NOT NULL,
customer_id INT NOT NULL,
total DECIMAL(10, 2) NOT NULL
)
PARTITION BY RANGE (TO_DAYS(order_date)) (
PARTITION p202201 VALUES LESS THAN (TO_DAYS('2022-02-01')),
PARTITION p202202 VALUES LESS THAN (TO_DAYS('2022-03-01')),
PARTITION p202203 VALUES LESS THAN (TO_DAYS('2022-04-01')),
PARTITION pmax VALUES LESS THAN (MAXVALUE)
);💡 TO_DAYS(order_date) でパーティション化することで、レンジ境界の一貫性を確保できます。
🔢 サンプル・データを投入する
SQL:
INSERT INTO orders (order_date, customer_id, total) VALUES
('2022-01-15', 1, 100.00),
('2022-01-20', 2, 200.00),
('2022-02-01', 3, 300.00),
('2022-02-15', 4, 400.00),
('2022-03-01', 5, 500.00);🗄️ 2. アーカイブ・テーブルを作成する（インデックスなし）
orders テーブルから、常に成立しない条件で選択するというシンプルな方法でアーカイブ・テーブルを作成します。これにより、コールド・ストレージやエクスポートに適した、非パーティションかつインデックスなしのクローンを作成できます。
SQL:
-- Create archive table with same structure, no data or indexes
CREATE TABLE orders_archive AS SELECT * FROM orders WHERE NULL;これにより、次の状態になります。
- ✅ 同一の列
- ❌ 行なし
- ❌ インデックスなし
- ❌ パーティションなし
- ✅
EXCHANGE PARTITIONに完全対応
⚡ 3. パーティションを交換する（瞬時かつロックを抑制）
次に、メタデータのみの操作を使用して、1か月分のデータ全体をアーカイブ・テーブルへ瞬時に移動します。
SQL:
ALTER TABLE orders EXCHANGE PARTITION p202201 WITH TABLE orders_archive WITH VALIDATION;注意点:
WITH VALIDATIONは、正しいレンジの行だけが交換されることを確認します。- 事前にレンジを検証済みのパフォーマンス重視パイプラインでは、
WITHOUT VALIDATIONを使用できます。
🧪 4. 交換結果を検証する
交換後、対象パーティションが空になり、アーカイブ・テーブルに正しいデータが含まれていることを確認します。
SQL:
-- Check that the partition is now empty
SELECT PARTITION_NAME, TABLE_ROWS
FROM INFORMATION_SCHEMA.PARTITIONS
WHERE TABLE_NAME = 'orders';
-- Check the archive table
SELECT COUNT(*) FROM orders_archive;
SELECT MIN(order_date), MAX(order_date) FROM orders_archive;💾 5. アーカイブをバックアップする（Jump VM上のMySQL Shell）
これは省略してはいけないバックアップ・メカニズムです。
アーカイブ・テーブルに古いデータが格納されたら、Jump VM上のMySQL Shellを使用して、ディスクまたはクラウド・ストレージへダンプできます。
MySQL Shell（JSモード）では、次のように実行します。
JS:
util.dumpTables(
"test_arch", /* schema */
["orders_archive"], /* tables */
"/Folder/BackupFolder/", /* dump target; could be a bucket mount or local path */
{ threads: 4, ocimds: true, compatibility: ["strip_definers"] }
);これは次をサポートします。
- ✅ ローカル・ディスク
- ✅ マウント済みNFS / FUSE経由のOCIバケット
- ✅ インスタンス・プリンシパルを使用したOCI Object Storageへの直接アップロード（
ocimds: true）
🧹 6. クリーンアップする、またはLakeへ流す（TRUNCATEメカニズム）
アーカイブが安全にバックアップされたら、同じアーカイブ・テーブルを再利用できるように領域を解放できます。
SQL:
TRUNCATE TABLE orders_archive;この時点で、次の状態になります。
- ライブ・パーティション（例: 2022年1月）は
EXCHANGEによって空になっています。 - 履歴データはディスクまたはオブジェクト・ストレージへバックアップされています。
- アーカイブ・テーブルは再び空になり、次回のパーティション交換に備えられています。
🚀 MySQL HeatWaveでこの方法が有効な理由
- ⚡ 瞬時のパフォーマンス:
EXCHANGE PARTITIONはメタデータのみの操作です。 - 💪 ロックに強い: 長時間実行される
DELETEや行単位のアーカイブ・ジョブを回避できます。 - 🧠 メモリ効率が高い: インメモリ・テーブルが小さくなるほど、HeatWave分析は高速になります。
- 🔁 自動化しやすい: 月次イベントとMySQL Shellジョブを組み合わせることで、手間のかからないアーカイブを実現できます。
- 📜 コンプライアンスに対応しやすい: 規制当局に対して明確で反復可能なアーカイブ戦略を示せます。
よりスマートに、より高速にアーカイブを始めましょう。🔨🤖🔧