【次世代高速RDB劔"Tsurugi"】DDL/DML の同時実行制御

Tsurugi はメニーコアハードウェアを最大限に活用することを設計目標としたOLTPデータベースです。SQLでデータ操作を行う DML (data manipulation language) 間の同時実行制御はその中核機能ですが、データ定義を行う DDL (data definition language) と DML 間の排他制御はあまり取り上げられることがありません。本稿では、DDL と DML が同一データベースに対して並行して発行された場合に、Tsurugi がどのような排他制御を行うかについて解説します。

対象とする操作範囲

Tsurugi において、本制御の対象となる DDL は  CREATE TABLE ,  DROP TABLE ,  CREATE INDEX ,  DROP INDEX  に加え、GRANT , REVOKE などのアクセス制御系文も含みます。
DML は  SELECT ,  INSERT ,  UPDATE ,  DELETE が対象です。

DDL と DML の性質の違い

DDL はテーブルやインデックスといったメタデータの追加・変更・削除を行う操作であり、DML のようにデータそのものを扱うものではありません。実行頻度や使用パターンも大きく異なります。DML はアプリケーションの通常処理の中で頻繁に発行されるのに対し、DDL はスキーマ変更やメンテナンス作業として低頻度かつ計画的に実行されるのが一般的です。

この性質の違いから、Tsurugi では DDL と DML が競合するような状況において、排他制御を駆使して両方を成功させることは想定していません。両者が同一テーブルに対して重なる実行区間を持つことを検出した場合は、後から来た側にエラーを返すことを基本方針としています。

また、DDL はトランザクションを用いて発行されますが、トランザクショナルな操作ではなく、トランザクションのアボート時にロールバック対象にはなりません。DDL を実行したトランザクションはその完了まで対象テーブルを排他的に取り扱う必要が生じるため、対象テーブルへの DML は成功せずエラーになります。DDL を含むトランザクションは、発行後速やかにコミットすることが推奨されます。

排他制御なしに生じうる問題

DDL と DML が同一テーブルに対して同時に発行される場合、もし Tsurugi が適切な制御を行わないと次のような問題が生じえます。

• DROP TABLE の実行中または実行後、そのトランザクションのコミット前に、別トランザクションが同じテーブルに INSERT しようとする。

• INSERT などの DML ステートメントの実行完了後、そのトランザクションのコミット前に、別トランザクションが同じテーブルを DROP TABLE しようとする。

いずれの状況においても、メタデータが削除されようとしている領域上で INSERT 処理やコミット検証処理が実行されることで不正なメモリ領域のアクセスとなる可能性があります。実行中の DDL と DML が重なる問題にはテーブル閉塞（DDL と DML の実行区間を排他する仕組み）で対処します。DML のステートメント完了後も、そのトランザクションが内部的にテーブルの実体を参照し続ける問題には、ストレージ遅延削除（DML が使用中のストレージを DDL が削除しないようにする仕組み）で対処します。

テーブル閉塞

Tsurugi ではテーブルに対するアクセスを閉塞することによって DDL と DML の実行区間を排他制御します。
これをテーブル閉塞と呼びます（Tsurugi の独自機構です）。
テーブル閉塞は、テーブルにアクセスしたステートメントやトランザクションが共有ロック・排他ロックを取得したようなふるまいとして観察されます。閉塞の種別と保持期間は次の通りです。

競合の考え方

• 共有ロック同士は競合しない : 複数 DML が同じテーブルを対象とする場合は互いにブロックしない

• 排他ロックは共有ロックと競合する : DDL 実行中は、対象テーブルへの新規 DML の開始を阻止する

• 共有ロックは排他ロックと競合する : DML 実行中は、対象テーブルへの DDL の開始を阻止する

この仕組みにより、危険な操作の組み合わせが実行区間として重なることを防ぎます。

動作例

ケース1：DDL 実行中に DML を開始しようとした場合

TX-A が CREATE TABLE を実行してコミットしていない状態で、TX-B が同じテーブルに SELECT を発行します。

[セッション A]
tgsql> BEGIN TRANSACTION;
transaction started.

tgsql> CREATE TABLE products (id INT PRIMARY KEY, name VARCHAR(100));
execute succeeded

（コミットせずに保留中）

[セッション B]
tgsql> SELECT * FROM products;
[id: INT, name: VARCHAR(100)]
SQL_EXECUTION_EXCEPTION (SQL-02000: DML operation was blocked by DDL operation)

TX-A のトランザクションがコミットまたはアボートするまで、TX-B はそのテーブルにアクセスできません。

ケース2：DML 実行中に DDL を開始しようとした場合

セッション A と B をほぼ同時に実行します。TX-A が DML ステートメントを実行している最中に TX-B が同じテーブルに DROP TABLE を発行すると、テーブル閉塞の競合が検出され TX-B はエラーを受け取ります。

次の例では、セッション A の INSERT がまだ完了していない時点で、セッション B が DROP TABLE を発行したものとします。

[セッション A]
tgsql> INSERT INTO orders VALUES (1, 'apple');
（実行中）

[セッション B]
tgsql> DROP TABLE orders;
SQL_EXECUTION_EXCEPTION (SQL-02000: DDL operation was blocked by other DML operation. table:"orders")

TX-A の INSERT ステートメントが完了した後であれば、TX-B は改めて DROP TABLE を試みることができます。

ケース3：同一トランザクション内で DDL の後に DML を実行した場合

排他ロックは共有ロックよりも強い制御であり、同一トランザクション内の DML はその配下として動作します。

tgsql> BEGIN TRANSACTION;
transaction started.

tgsql> CREATE TABLE products (id INT PRIMARY KEY, name VARCHAR(100));
execute succeeded

tgsql> INSERT INTO products VALUES (1, 'apple');
(1 row inserted)

tgsql> COMMIT;
transaction commit(DEFAULT) finished.

ただし、このパターンはテストや開発時のセットアップには有効ですが、本番コードでの使用は推奨しません。DDL はロールバック非対応であるため、トランザクションがアボートした場合に DDL の効果は残ったまま DML のみが取り消されます。この挙動を正しく扱うには例外処理が複雑化するため、DDL と DML は別々のトランザクションで実行することを推奨します。

競合時は待機しない

テーブル閉塞が競合した場合、Tsurugi は待機せずにエラーを返します。

この設計には次のような意図があります。

• デッドロックのリスクを避ける：待機する設計ではトランザクション同士が互いに待ち続けるデッドロックが生じうる

• 予測可能な動作：アプリケーション側がエラーを受け取り、リトライなどの制御を明示的に行える

ただし、利便性のために将来的には限定的な待機機能を検討する可能性もあります。

閉塞の粒度

Tsurugi のテーブル閉塞はテーブル単位です。共通のテーブルを持たない操作同士は互いに影響しません。

TX-A: INSERT INTO orders ...   ← orders テーブルを閉塞中
TX-B: DROP TABLE customers     ← customers テーブルを閉塞しようとする
→ 別テーブルなので閉塞は競合せず、TX-B はエラーなく実行できる

ストレージ遅延削除

テーブル閉塞は「DDL（例えば DROP TABLE）の実行開始を、DML 使用中は阻止する」という保護を提供します。しかし、保護が必要な場面はこれだけではありません。

DML によるテーブル閉塞はステートメント完了時に解除されます。そのため、DML ステートメントが完了した後であれば、同じテーブルに対する DROP TABLE が受け付けられる場合があります。

一方で、DROP TABLE が受け付けられたからといって、テーブルの実体をすぐに物理削除できるとは限りません。DML を実行したトランザクションがまだコミット・アボートに至っていない場合、トランザクションエンジン（shirakami）内部では、そのテーブルの実体を参照し続けることがあります。この状態で物理削除してしまうと安全ではありません。

この問題に対応するため、Tsurugi は DROP TABLE/INDEX を受け付けた際にストレージの物理削除を即座に行わず、参照カウンタが 0 になるまで遅延させる設計を採用しています。

DROP DDL 実行時の動作

利用者から見ると、DROP TABLE 後はそのテーブルに新しくアクセスできなくなります。ただし、すでにそのテーブルを使っていたトランザクションが残っている場合、内部の実体削除はそのトランザクションの終了後まで遅れます。

DROP TABLE が発行されると、Tsurugi の SQL 実行エンジンは次の2段階の処理を行います。

1. 論理削除（即時）

• ストレージを名前検索のマップから除外し、新規 DML からはそのテーブルが見えなくなる

• ストレージエントリに削除予約フラグを設定し、永続化する

2. 物理削除（遅延）

• ストレージエントリ自体はメモリ上に残り、参照カウンタの管理対象となる

• 物理削除はメンテナンススレッドが参照カウンタが 0 になったことを確認してから実行する

DROP TABLE orders が発行された瞬間：
  orders は名前検索から除外される（新規DMLはアクセス不可）
  削除予約フラグが設定される
  既存のトランザクションはまだ orders のストレージを参照中

参照カウンタが 0 になった時点（全トランザクションが完了）：
  メンテナンススレッドがストレージ削除APIを実行
  ストレージが物理的に削除される

まとめ

Tsurugi の DDL/DML 同時実行制御は、2つの層で構成されています。

利用者の観点では、DML 処理中にそのテーブル定義等を DDL で変更しようとしないこと、DDL を発行したトランザクションは速やかにコミットすること、競合エラーを受け取った場合は実行タイミングの調整やリトライを検討することが重要です。

テーブル閉塞

• DDL：対象テーブルを排他的に閉塞し、トランザクション完了まで維持

• DML：対象テーブルを共有的に閉塞し、ステートメント完了まで維持

• 閉塞が競合した場合はエラーを即返却（待機しない）

ストレージ遅延削除

• DROP DDL はストレージを即時に論理削除（名前検索から除外）するが、物理削除は遅延させる

• 参照カウンタが 0 になった時点でメンテナンススレッドが物理削除を実行する

2つの仕組みが組み合わさることで、DDL と DML の同時発行を安全に制御しています。

その他の劔"Tsurugi"を使う際に役立つTips集はコ

次世代高速RDB劔"Tsurugi"は、オープンソースで公開中です。
ぜひダウンロードしてみて、触ってみてください。

劔"Tsurugi"のダウンロードはコチラから

https://www.tsurugidb.com/