【ITニュース解説】DuckDB 2.0 alpha's triggers cost three times more per row than per statement

DuckDBは、埋め込み型の分析用データベースとして注目を集めている技術である。一般的なデータベースとは異なり、アプリケーションに直接組み込んで利用できる手軽さと、高速なデータ処理能力が特徴だ。そのDuckDBの次期メジャーバージョンである2.0のアルファ版が公開され、新たに導入される「トリガー」機能や、既存の「再帰的CTE」エンジンの改善状況について、詳細な検証結果が発表された。

まず、データベースにおける「トリガー」とは、特定のデータベース操作（例えば、データの追加、更新、削除など）が発生した際に、自動的に実行される処理のことである。これは、データの整合性を保ったり、変更履歴を記録したり、関連するデータを自動的に更新したりする際に非常に便利な機能だ。トリガーには、操作の「前（BEFORE）」に実行されるか「後（AFTER）」に実行されるか、そして「行ごと（FOR EACH ROW）」に実行されるか「SQL文全体（FOR EACH STATEMENT）」に対して一度だけ実行されるか、という組み合わせがある。例えば、データの追加前にその内容を検証し、不正なデータであれば追加を拒否する、といった使い方ができる。

DuckDB 2.0のアルファ版でトリガー機能が初めて実装されたが、まだ開発途上であることが検証で明らかになった。特に、データ検証によく利用される「BEFORE FOR EACH ROW」（行ごとに、操作の前に実行）のトリガーは、現時点では全くサポートされていない。これは、新しい行がデータベースに挿入される前に、その行のデータを検査したり、条件を満たさない場合は挿入を中止したりといった、多くのシステムで必要とされる基本的なデータ検証ロジックをトリガーで行うことができないことを意味する。 また、「AFTER FOR EACH ROW」トリガーは、データの追加（INSERT）と削除（DELETE）の際には動作するものの、更新（UPDATE）の際にはまだサポートされていない。一方、「FOR EACH STATEMENT」トリガーは、「BEFORE」と「AFTER」の両方で、追加、更新、削除のいずれの操作でも正常に動作することが確認された。 さらに、同じテーブルに対して「FOR EACH ROW」と「FOR EACH STATEMENT」のトリガーを両方設定することはできないという制限や、トリガーを削除する際のコマンド（DROP TRIGGER）の構文が、既存のドキュメントと異なり、削除対象のテーブル名を明示する必要があるといった細かな点も指摘されている。しかし、無限ループに陥る可能性のある「再帰トリガー」（トリガー自身が再度トリガーを発生させるような状況）については、システムがこれを検知し、安全にエラーを出す仕組みが既に実装されていることは、非常に評価できる点だ。これは、意図しないシステムの停止やデータ破損を防ぐための重要な安全機能である。

トリガーの導入によって、データベース処理の性能にどのような影響があるかも検証された。50万行のデータを一括で挿入するテストを行った結果、「FOR EACH ROW」トリガーを使用した場合、トリガーなしの時と比較して処理時間が約3倍に増加した。これは、50万行のデータに対して、トリガーが1行ずつ50万回呼び出されるため、その呼び出し処理自体が大きなオーバーヘッドとなるためである。 一方、「FOR EACH STATEMENT」トリガーを使用した場合、処理時間はトリガーなしの時と比較して約1.3倍の増加にとどまった。このトリガーは、SQL文全体が一度実行される際にまとめて1回だけ呼び出され、挿入された全てのデータを一時的なテーブル（「トランジションテーブル」と呼ばれる）として参照できる仕組みがある。これにより、行ごとに個別の処理を繰り返すのではなく、挿入された大量のデータ全体に対して一度に処理を実行できるため、はるかに効率が良い。例えば、監査ログのような、挿入された全データのIDを記録するような処理では、「FOR EACH STATEMENT」トリガーとトランジションテーブルを組み合わせることで、性能を大きく損なうことなく実現できることが示された。この結果から、もしDuckDB 2.0でトリガーを実装する際は、特に大量のデータを扱う場面では、「FOR EACH ROW」よりも「FOR EACH STATEMENT」トリガーを優先して検討することが推奨される。

トリガー機能以外にも、DuckDB 2.0のアルファ版では「再帰的CTE（Common Table Expression）」という、自己参照型のクエリを記述するための機能が大幅に改善されている。再帰的CTEは、例えばソーシャルネットワーク上の友達関係をたどるような、複雑なグラフ構造のデータを探索する際に非常に強力なツールとなる。検証では、4万ノードからなる長いチェーン状のデータ構造（多くのステップを順次処理する必要がある、再帰処理にとって厳しいケース）において、旧バージョン（1.5版）では約18.57秒かかっていた処理が、2.0アルファ版ではわずか約0.41秒で完了した。これは約45倍もの劇的な速度向上であり、再帰的CTEを多用する複雑なデータ分析や探索クエリにおいて、性能上のボトルネックが大幅に解消されることを示唆している。

最後に、DuckDB 2.0アルファ版の使用にあたっての重要な注意点として、データベースファイルのストレージ形式が変更された点が挙げられる。2.0アルファ版で作成されたデータベースファイルは、旧バージョン（1.5版）では読み込むことができない。これは、アルファ版がまだ開発段階であり、将来の変更に備えて形式が更新されているためだ。既存の安定版のデータベースを2.0アルファ版で開く、あるいはその逆の操作を行う必要がある場合は、一旦データをParquet形式などの標準的なファイル形式にエクスポートし、再度インポートするなどの方法で移行する必要がある。

これらの検証結果は、DuckDB 2.0がまだアルファ版であり、一部の機能は未完成であるものの、特に再帰的CTEの性能向上は非常に大きく、今後の正式リリースが期待される内容である。トリガーに関しては、現時点では「FOR EACH STATEMENT」を基本とし、必要な機能を評価しながら採用を検討することが賢明だ。