NewSQLが急速に支持を拡大する理由は？──新定番「TiDB」がもつ“ユニークさ”から探る

NewSQLのアーキテクチャ──「分散DB」と呼ばれる所以

　NewSQLの実装は製品によって異なるが、共通するアーキテクチャを抽象化して示すと、下図のようにコンピュート層とストレージ層を分離して疎結合にしている。

　これによってコンピュート層のノードとストレージ層のノードを独立に増やすといった柔軟なスケーラビリティを実現。更新の際は、リーダーノードがリクエストを受けつけ、更新結果を複数のフォロワーに伝搬する。こうすることで、ユーザーからは1つのテーブルに見えるデータを、物理的には分散したノードに分割して保持することになる（「分散データベース」と呼ばれる所以である）。

　この分散ノードでデータを持ち合う際に用いられるのが、分散合意アルゴリズムの「Raft」である^[注2]。Raftにおいてリーダーは、書き込みを行った際にフォロワーの過半数から応答があった場合にはじめて、ユーザーへ完了を通知する。この分散構成を採用することで、write/readの両方のスループットを飛躍的に向上させることが可能になった。またノード数が増えることで可用性も向上する。ノードがダウンしても残ったノードで処理を継続できる仕組みになっているからだ。複数ノードによる運用を行うことで、ローリングアップデートによってバージョンアップ等の際にも無停止運用を行うことができる利点もある。

　ただし、NewSQLは良いことばかりではない。大きく3つの欠点がある。

1. NW転送オーバヘッドが乗ってレスポンスタイムが悪化する：これはNewSQLに限らず分散システム全般が宿命的に抱える問題でもある。ただこれは程度問題であり、多くのケースではms（ミリセカンド）のオーダーで収まるようであり、実際にNewSQLは既に多くの商用実績を持つことからも、それほど大きな問題にはなっていない
2. 一般的にまだ若干割高：同じリソース量ならば通常のRDBの方がコストメリットが出るケースもある。そのためユースケースをよく考えねばならない（第2回でテーマとして取り上げる）
3. ノード数が多いため障害や遅延時の調査が難しくなりやすい：この点については、近年マネージドサービス化が進んでおり、それを利用することで軽減することもできる。TiDBもAWSおよびGoogle Cloudでマネージドサービスを展開しており、運用負荷を減らすことができる。Azureでも2025年中に利用可能になる予定だ