【次世代高速RDB劔"Tsurugi"】Tsurugi 1.12.0 の TRUNCATE TABLE を検証する: 1億件の DELETE と比較
はじめに
Tsurugi 1.12.0 では、テーブルの全行を削除する TRUNCATE TABLE が追加されました（Tsurugi 1.12.0 リリースノート）。全件削除には DELETE も利用できますが、大量データを扱う作業テーブルでは、処理完了までにかかる時間が運用へ影響します。
本記事では、DELETE と TRUNCATE TABLE の操作完了までの時間を、100万件から1億件までのデータで比較します。さらに、セカンダリインデックスの有無による違いも確認します。
検証内容
実行環境
テーブル定義とインデックス条件
主キーのみの条件では、以下のテーブル定義を使用しました。主キー + セカンダリインデックスありの条件では、同じテーブルに続けて event_at 列のセカンダリインデックスを作成しました。
CREATE TABLE benchmark_events (
id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
event_at TIMESTAMP NOT NULL,
category VARCHAR(32) NOT NULL,
value BIGINT NOT NULL
);
CREATE INDEX benchmark_events_event_at_idx ON benchmark_events (event_at);比較した SQL と計測方法
以下の SQLを tgsql で実行して比較しました。
DELETE FROM benchmark_events;
TRUNCATE TABLE benchmark_events;各試行は、DDL の実行、対象件数のデータ投入、DELETE または TRUNCATE TABLE の計測、Tsurugi の停止、ログディレクトリの削除を 1 セットとして実施しました。これにより、テーブル定義、インデックス、データ件数、ログの状態を試行ごとに初期化しています。
主キー + セカンダリインデックスありの条件では、100万件・1000万件を各5回、1億件を3回測定しました。主キーのみの1億件は各3回測定しました。
結果
中央値による比較
すべての条件で、TRUNCATE TABLE は DELETE より短い時間で完了しました。主キー + セカンダリインデックスありの1億件では、DELETE の中央値が約17.5分であるのに対し、TRUNCATE TABLE は約1.4分でした。
試行ごとの詳細結果
主キー + セカンダリインデックスあり: 100万件
主キー + セカンダリインデックスあり: 1000万件
主キー + セカンダリインデックスあり: 1億件
主キーのみ: 1億件
考察
今回の条件では、全件削除に TRUNCATE TABLE を使うことで、すべての件数で操作完了時間を短縮できました。とくに、主キー + セカンダリインデックスありの1億件では、DELETE と比べて約12.1倍短い時間で完了しています。
また、1億件では主キーのみと主キー + セカンダリインデックスありで、大きく異なる計測値が観測されました。これは今回のテーブル定義・データ・実行環境における結果です。内部実装に基づく原因の特定は本記事の範囲外であるため、インデックス条件が操作時間へ影響し得るという観測結果として扱います。
使い分け
一部の行だけを削除する場合や、削除条件を指定する場合は DELETE を使用します。一方、作業テーブルや検証用テーブルを全件初期化して再利用する場合は、TRUNCATE TABLE が有力な選択肢になります。
ただし、TRUNCATE TABLE は DDL として扱われ、ロールバックでは取り消せません。削除対象のテーブルと実行タイミングを確認したうえで使用する必要があります。
まとめ
Tsurugi 1.12.0 の TRUNCATE TABLE を、最大1億件のテーブルで DELETE と比較しました。今回の測定では、すべての条件で TRUNCATE TABLE が DELETE より短い時間で完了しました。
大量データの再投入や検証を繰り返す作業テーブルでは、TRUNCATE TABLE を使うことで初期化に要する時間を短縮できる可能性があります。一方で、ロールバックできない操作である点を踏まえ、用途に応じて DELETE と使い分けることが重要です。
その他の劔"Tsurugi"を使う際に役立つTips集はコチラ↓
次世代高速RDB劔"Tsurugi"は、オープンソースで公開中です。
ぜひダウンロードしてみて、触ってみてください。
