新時代のデータベース「NewSQL」── TiDBに見るその魅力と可能性（AD）

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

第1回：「NewSQL」とは何か？その魅力をTiDBから探る

2025/03/24 10:00

通知

　この連載は、2020年代に入って普及が進んでいるデータベースの新たな潮流「NewSQL」の魅力と可能性について、その有力な製品である「TiDB」にフォーカスして探ることを目的としている。TiDBは2015年に創業されたPingCAP社が開発するデータベースであり、全世界で3,000社以上に導入されており、NewSQLの中でも高い人気を誇る製品だ。「db tech showcase」の来場者アンケートによる「今後利用したいデータベース」で、2022年から3年連続で1位を獲得している。第1回では、そもそもNewSQLとはいかなる特徴とアーキテクチャを持った製品であり、どこに革新性があるのかを解説していく。第2回では、TiDBが利用されているユースケースを見ながらどのような用途に向いた製品であり、どういうメリットがあるのかを考えたい。第3回では、TiDBが強く推進するHTAPというコンセプトが持つ可能性について検討する。

通知

NewSQLは何が“New”なのか？従来DBとの違い

　2024年12月、AWSがre:Inventで「Amazon Aurora DSQL」を発表した。久々にAI以外の大きなアップデートということもあり広く注目を集めた。DSQLは、NewSQLと呼ばれる製品に位置づけられるが、“New”SQLは何が新しいのだろうか。

　先に答えを言ってしまうと、実はNewSQLに固有の新機能はない。そのため海外ではそのアーキテクチャから「分散データベース（Distributed Database）」と呼ばれることもある。しかし、既にNewSQLという名前も人口に膾炙しているため、本稿では以後この用語を使う。

　NewSQLは、LinkedIn、Pinterestなどグローバルに展開するメガサービスや、国内でもメルカリ、カプコン、DMM.com、mixi2、楽天など有名企業やサービスが多く採用しており、実は私たちも知らないうちにNewSQLの恩恵を受けているのだ（今挙げたのはいずれもTiDBのユーザーである）。その仕組みと革新性を理解するのが第1回の主題である。

RDB・NoSQL・NewSQLの違い

　現在、データベースの選択肢にはRDB、NoSQL、NewSQLという3つがある。これらの特徴を比較表にまとめると、以下のように表わせる。

　RDBとNoSQLの間にはトレードオフの関係があることが見てわかるだろう。NoSQLは水平スケーラビリティを持つが、クエリ言語やACIDトランザクションがないという欠点を持つ^[注1]。一方、RDBにはこうした便利な機能は充実しているが、スケーラビリティ（特に更新のスケーラビリティ）に限界がある。

　これに対して、NewSQLはいずれの特性も満たす。いわばNewSQLは、RDBとNoSQLの間の対立関係を止揚するために考え出された「スケーラブルRDB」と言える。なぜNewSQLはRDBとNoSQLのトレードオフを克服することができたのか？そこには一つの技術革新がある。

[注1] 厳密に言うと、この表には少し補足が必要である。というのも、上3つの軸で見ると近年のRDBとNoSQLは似通ってきているからである。たとえば「Apache Cassandra」を例にとると、CQLというクエリ言語やスキーマ定義を備えるようになってきている。Amazon DynamoDBのようにACIDトランザクションをサポートするNoSQL製品もある。またRDBの方もJSON型をサポートして半構造化データを扱えるようになってきている。

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

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

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

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

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

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

[注2] 分散合意アルゴリズムとしては、従来Paxosが知られていたが、難解なためなかなかデータベースへの応用が進まなかった（SpannerのようにPaxosを採用するDBも少数ながらある）。Raftは理解しやすいアルゴリズムとして近年分散システムでよく利用されている。TiDBのほかにも、「CockroachDB」や「YugabyteDB」といったNewSQL製品が採用している。次のサイトがRaftの動作をアニメーションで解説しており理解の助けになる。

様々なNewSQL製品のなかで「TiDB」がもつユニークさ

　NewSQLには、「Google Cloud Spanner」をはじめとして、「YugabyteDB」「CockroachDB」などのスタートアップのほか、AWSもDSQLを発表し、Oracleも23aiよりRaftによるレプリケーションをサポートするなど、ビッグベンダーも参入するホットな分野となっている。その中でTiDBはどのような点に特色があるだろうか。

1. MySQL互換

　多くのNewSQL製品がPostgreSQL互換を謳うなか、MySQL互換なのはTiDBのみである。MySQLはWebサービスを中心に広く利用される人気の高いDBMSである。そのため、アプリケーションから見るとMySQLと変わらない使い勝手で扱えるTiDBは利便性が高く、マイグレーションも容易である。

2. データベースの統合による運用負荷の低減

　マイクロサービスなどによって散在したデータストアを統合して運用負荷を低減することができる。リソース制御機能はTiDBの優れた機能であり、マルチテナントの収容というユースケースはユニークな長所となっている（第2回で詳述する）。

3. 豊富な選択肢と充実したサポート

　NewSQLの中には、SpannerのようにGoogle Cloud限定になったり、CockroachDBのように日本進出していないなど、利用制限のある製品もある。TiDBは上述のようにクラウドプラットフォームを問わず利用可能。日本法人もあり、日本企業にも多く導入されているためサポート面でも実績がある。