【セッションレポート】 データベースの新潮流 ～NewSQLとHTAPを中心に～ #devsumiA

ウィスキー、シガー、パイプをこよなく愛する大栗です。

先日 Developers Summit 2025 に参加してきました。印象が強かったセッションについてレポートします。まずはミックさんの NewSQL と HTAP についてのセッションです。

データベースの新潮流 ～NewSQLとHTAPを中心に～

データベースの新潮流 ～NewSQLとHTAPを中心に～

登壇資料 : データベースの新潮流 -NewSQLとHTAP-

概要

近年、データベースの世界において二つの大きな技術トレンドが注目を集めています。一つがNewSQLというリレーショナルデータベースの進化形です。リレーショナルデータベースのSQLインタフェースやACIDのような強いトランザクション一貫性を保証しつつ、水平スケーラビリティを確保しようとする“いいとこどり”を狙った野心的なデータベース群が登場してきています。また、HTAPは従来分離することがシステム開発のセオリーだった基幹系と分析系のデータベースを統合しようという壮大な夢を追う技術です。この二つの技術を軸としてデータベースの進化の最前線を解説します。

登壇者

ミック氏

データベース分野におけるエンジニアとして20年以上のキャリアを持つ。特に大規模データを扱うBI/DWHでの開発経験が豊富で、性能設計やパフォーマンスチューニングを得意とする。2018年より3年間、米国シリコンバレーにて技術発掘や先進技術の調査に従事。2025年現在は、会社全体の技術戦略の策定に分野横断的に従事している。データベース関連の著書多数：『センスの良いSQLを書く技術』、『SQL緊急救命室』、『達人に学ぶ DB設計徹底指南書 第2版』など。

近刊の紹介

• おうちで学べるデータベースのきほん 第2版
• 達人に学ぶDB設計徹底指南書 第2版
• SQL緊急救命室──非効率なコードを改善せよ！
• センスの良いSQLを書く技術　達人エンジニアが実践している３５の原則

データベースの新潮流(1) NewSQL ー 統合と分散の螺旋

セッション冒頭では、データベースの進化は 3 つの期間に分けられると提示されました。「RDBMS」の時代、高可用性や水平スケールなどに対応した「NoSQL」の時代、高可用性や水平スケールに対応しつつ SQL が利用できる「分散クラウドネイティブ SQL」の時代です。

「分散クラウドネイティブ SQL」は NewSQL と呼ばれますが水平方向のスケーリングがある分散データデースであるが、"新しい機能"がある訳ではない。

2017年には以下の予言をしています。

NoSQL というのは、将来的には RDB の機能の一つを指す言葉になることも、十分に考えられます。

RDB のスケーラビリティは以下の方式がありますが、限界があります。

• シェアードエブリシング方式：Oracle RAC で採用される方式で、更新と参照をスケールできるが共有リソースのストレージがボトルネック
• リードレプリカ方式：参照はスケールするが、更新はプライマリノードで受ける

RDBMS の長所を活かしたままスループットを出すためには分散合意アルゴリズムが必要となる。Paxos が知られていたが実装の難易度が高く採用が進みませんでしたが、代替の分散合意アルゴリズムである Raft が登場して採用が進むようになりました。分散データベースでのデータ書き込み時にはリーダーノードが受けてフォロワーノードへレプリケーションで同期して、Raft で合意した結果は覆されません。

リーダー選挙では、Follower から始まり、一定時間で選挙が始まり Candidate に変化し、過半数のノードから投票されると Leader になります。Raft の動きを理解するアニメーションもあります。

NewSQL の主要プレイヤーには以下のようなものがあります。Google とスタートアップです。

• Cloud Spanner
  • マルチリージョンで 99.999%
• yugabyteDB
• TiDB
  • MySQL 互換
• CockroachDB
  • 日本法人なし
    • マルチリージョンで 99.999%

最近ビックベンダの NewSQLとして AWS では Aurora DSQL を発表しています。ハイスケーラブルよりも可用性を重視しているように思われます。日本で利用可能になっても Witness をどこに配置するのかを検討する必要があるでしょう。

Oracle では 23ai より Raft ベースのレプリケーション機能（Globally Distributed Database）をサポートして信頼性や可用性を強調しています。Kafka や GoldenGate などでも Raft が採用され始めています。

事例として、リテール EC の DoorDash はコロナ禍の需要にマッチして大ヒットした結果在庫ステータスの更新が追いつかなくなり、CockroarchDB でデータを受けて CDC で Kafka に流してニアリアルタイムに反映させました。

みんなの銀行では、東阪両現用を実現させるために Cloud Spanner を採用しています。日本国内で 99.999% の可用性があるサービスは Spanner のみです。

レバテックでは、マイクロサービスにより増えたデータベースによりインフラチームが障害対応に追われる状況に。TiDB の 1 つのクラスタにまとめることで管理を効率化とコスト最適化を行った事例。日本的なユースケースと言えます。

DMM.com では、ログイン情報、セッション、ログイン履歴で別々のデータベースを採用していたが全てに精通しているエンジニアは少なく開発効率が悪く、また人承認派のサービスが落ちるとすべてが落ちる状況でした。TiDB に統合してそれらの問題を解決。

ユースケースの意外なダークホースとして、NewSQL でまとめるという考え方があります。集約するとノイジーネイバーが問題になるが、TiDB ではリソースコントロールの仕組みがある。

統合と分散は 10 年単位で行ったり来たりする。Data Lake は 2010 年くらいから。Data Mesh は 2019 年くらいから。元々データを統合して使おうと Data Lake ができました。

NewSQL の欠点として、以下のようなものがあります。

• レスポンスタイムが悪化する
  • 分散しているためネットワークのオーバーヘッドは乗ってしまう。
• まだ比較的割高
  • まだ広く普及していないため薄利多売になっておらず割高になっている。
• 障害対応が大変
  • 分散構成にコンポーネントが複雑で障害の原因調査が大変になる、マネージドサービスを使用してベンダーを頼る選択肢もある。

データベースの新潮流(2) HTAP ー スーパーデータベースの夢

データベースアーキテクチャの黄金律として、基幹系（OLTP）と情報系（OLAP）を分けるのは原則です。基幹系は重要で、情報系はヘビークエリでも社内システムなので可用性を求めません。

情報系のアーキテクチャはシェアードナッシングで MPP（Massive Parallel Processing）構成となり、リソースを使い切ります。MPP はクエリ多重度に比例してレスポンスが悪くなるため OLTP に向かない。OLAP 用のデータベースで OLTP のパフォーマンスが出ないと呼ばれたことがあるが『DB ベンダーの営業が悪い』。

どうしてもリアルタイムに分析を行いたいということで、HTAP（Hybrid Transaction and Analytics Processing）を 2014 年にガートナー社が提唱しました。

TiDB では、OLTP 用の行ベースのストアとOLAP 用カラムベーズのストアの両方を用意しています。Snowflake の Unistore も同じ発想で行ベースとカラムベースの両方のストアを持っています。

HTAP の懸念には以下のようなものがあります。

• 性能
  • OLAP のクエリによって、OLTP のクエリが遅延したりスループットが合ったすることはないか
• 信頼性
  • OLAP 向けアーキテクチャで障害が発生したときに OLTP でも巻き込まれて障害が発生しないか
• データ量
  • OLAP 向けと OLTP 向けでデータコピーを持つと全体のデータ量が増えるのではないか？

疎結合型 HTAP も考えられます。AWS は懸念に対して、OLTP と OLAP を分離する考え方で Zero-ETL として CDC によるレプリケーションを行います。Azure も疎結合型です。密結合型も疎結合型もデファクトの位置をしめられていません。日本はどちらかというと疎結合な気がしています。

HTAP には様々なユースケースがあります。

• リアルタイムマーケティング
• 不正検知
• 需要予測
• IoT 予測分析

中国の事例では不正検知やマーケティングに Hadoop を利用していたが、リアルタイム性を求めて TiDB を選択しています。

ラムダアーキテクチャは実装が困難であまり流行りませんでした。また、そもそも分析するビックデータ自体がありませんでした。Snowflake は初期費用を抑えたスモールスタートができて、大規模への拡張の容易であったため、マス層の中小企業で利用できる「データの民主化」が行いました。

• NewSQL
  • RDBMS にスケーラビリティを信頼性を高める。
  • Google とスタートアップだけであったが、ビッグベンダが参入している。
  • 運用付屋とコストを減らしてスモールスタートできるかが普及の鍵。
• HTAP
  • OLTP と OLAP の統合データデースという見果てぬ夢
  • リアルタイム分析ができると嬉しいが、どこまでリスクを許容できるか
  • 密結合型と疎結合型のどちらの HTAP が 主流になるか見極めが重要

さいごに

ここ数年はスタートアップだけでなくメガクラウドベンダーでも新しい NewSQL や HTAP が登場しています。例えば NewSQL として AWS では Aurora Limitless Database や Aurora DSQL、Google Cloud では AlloyDB などがあります。スタートアップではそれ以外のプロダクトが多数登場してきています。そのため NewSQL と HTAP についてのセッションということで聴講してみました。セッションな中で、個人的には NewSQL を複数データベースの集約で使用するという意外なユースケースが思いがけない発見でした。今後のデータベースの進化を考えるうえで必要となる知識を得られるセッションだったと思います。