データベースの進化と課題、NewSQLの登場
ミック氏はSIerでのエンジニア経験を経て、SQLチューニングや大規模データベースの構築・運用に携わってきた。その後、シリコンバレーでスタートアップの探索やベンダー連携を担当し、現在はブロックチェーンやロボティクス、デジタルツインなど新規技術の調査や技術戦略の策定に従事している。
セッション冒頭では、データベースの進化を三つの時代に分けて解説した。まずは、リレーショナルデータベース（RDB）が主流だった時代だ。ACIDトランザクションにより高い整合性を担保しつつ、2000年代後半にはExadataなどアプライアンス製品も普及した。次に、2010年代前半から台頭したNoSQLが挙げられる。スケーラビリティや非構造化データの扱いやすさが強みである一方、ACIDトランザクションの欠如やSQLの限定的なサポートが課題だった。
これらの課題を背景に、2010年代後半に登場したのがNewSQLだ。NewSQLは、RDBの整合性やSQLの利便性を保ちながら、NoSQLのスケーラビリティを取り入れた技術である。「実は何か新しい機能が追加されたわけではない。RDBのACIDトランザクションとSQLの利便性を維持しつつ、NoSQLのスケーラビリティを取り入れた“いいとこどり”の技術だ」とミック氏は説明する。
そもそもRDBがスケールしにくい理由は、そのアーキテクチャに起因している。RDBのアーキテクチャは「シェアードエブリシング方式」と「リードレプリカ方式」の2種類があるが、それぞれに限界がある。
シェアードエブリシング方式は、Oracle RACのように複数のインスタンスが同一ストレージを共有する。更新と参照をスケールできる利点があるが、共有ストレージのボトルネックやキャッシュフュージョンのオーバーヘッドが問題となる。一方、リードレプリカ方式は、MySQLなどで一般的である。読み取り処理の負荷分散には有効だが、プライマリーノードに更新処理が集中し、ライト性能が限界に達しやすい。またプライマリーノードが単一障害点になりやすいという欠点もある。
NewSQLはこの課題に対処するため、ACIDトランザクションとSQLの利便性を維持しつつ、分散環境でスケーラビリティを確保することを目指したものだ。NewSQLの進化を支えた重要な技術として、分散合意アルゴリズムが挙げられる。従来より知られていたPaxosは、理論的には先駆的だったが、実装の複雑さが普及の妨げとなっていた。
この課題に対して、2014年に登場したRaftは、理解しやすく実装が容易なため、現在では多くのNewSQL製品に採用されている。NewSQLでは、コンピュートとストレージのノードを分離している。それぞれを個別にスケールアウトできるため、需要に応じて柔軟にリソースを追加できる。それに加えRaftを応用することで、更新処理はリーダーノードが受け付け、ログレプリケーションという形でフォロワーノードに送信される。過半数のフォロワーから応答を得られた時点で書き込みを確定させるという仕組みが、一種のマルチマスタ構成を実現することで、ライト性能を向上させている。
NewSQLの基礎を築いた代表的な存在が、Google Cloud Spannerだ。2012年に発表された論文をもとにGoogleが開発した分散データベースであり、その画期的な技術は多くのエンジニアに衝撃を与えた。
Spannerに触発される形で、YugabyteDB、TiDB、CockroachDBといったNewSQL製品が次々に誕生している。これらはスケーラビリティと整合性を両立することを目指したNewSQLの代表格であり、各社がしのぎを削って急成長を遂げている。
日本市場においては、特にTiDBの存在感が強い。MySQL互換のデータベースとしてWebサービスで広く利用されており、国内企業でも採用が進んでいるという。一方で、CockroachDBはまだ日本への進出をしていないものの、海外では大規模なユースケースで注目を集めており、今後の展開が期待されるところだ。
ミック氏は、NewSQLがRDBとNoSQLのトレードオフを解消しつつ、進化を続けている点を強調。技術の選択肢が増えたことで、ユースケースに応じた最適なデータベースを選べる時代が到来していることを示した。
