NewSQLの代表的な欠点「レイテンシー」
NewSQLの欠点としてよく上がるのが「レイテンシー」です。
これは分散DBである程度強いデータ整合性を達成しようと思うと、仕方ない話なのかなと思います。
構造的にも納得できます。
意外な欠点「外部キー制約で性能劣化する」「外部キー制約が使えない」
多少レイテンシーが犠牲になるくらいならNewSQLかなり便利なのでは？と思っていたのですが、TiDBやAurora DSQLを調べてみると「外部キー制約」が弱点かもしれないと思いました。
TiDBでは外部キー制約を貼った子テーブルに挿入を繰り返すと性能劣化する
具体的にはTiDBにおいて外部キー制約を利用した際に、子テーブルに挿入を繰り返すと性能が劣化するそうです。
これは子テーブルに挿入する際に親テーブルをロックするという挙動が起こるため発生するそうです。
東京ガスさんではこの問題に対して、性能が劣化する当該セッションのみ外部キー制約のチェックを緩和することで性能問題を回避したとのことです
そのため、全体としては、性能劣化したテーブル・クエリは外部キー制約を緩和して、性能劣化していないマスターデータなどは外部キー制約で整合性を保つみたいなバランスを取っているのだと思います。
ただこれは一時的な対処であり、外せる制約は制約と呼べるのか、、という気もするので、アプリ側でもデータ間の整合性を保つ工夫が求められそうですね。
Aurora DSQLではそもそも外部キー制約が使えない
またAurora DSQLではそもそも外部キー制約が利用できません(2025/3/24時点)。
もともとTiDBでも外部キー制約はサポートされていなかったそうなので、DSQLでもまだ性能的に使えるレベルの実装ができていないのかもしれないですね。
外部キー制約が無いと何が困るのか？
また外部キー制約が無いと何が困るのか？という感じですが、ざっと以下のメリットが享受できないと考えられそうです。
- 外部キー制約があると大規模な集計クエリのパフォーマンスが向上する場合がある. https://yukiotechblog.com/tidb-vs-aurora-on-tpch10-with-query-discription/
- データの整合性をDBレベルで担保できるので、アプリケーションレイヤーではビジネスロジックの実装に集中できる
- DDLからER図を自動生成した際に制約を元にテーブル間の関係を作成してくれる
おわりに
銀の弾丸っぽく思えていたNewSQLですが意外な弱点がありました
これもNewSQLのロックの機構が変わることで改善されていくかも知れないので、要チェックですね
参考
