―― SingleStore はその夢を実現できるのか
執筆者：CPO 石川 雅也
DBエンジニアとして30年を超えるキャリアのなかで、繰り返し「もうすぐ実現できそう」と期待させながら、なかなか本当には達成されてこなかった夢がある。
それは HTAP（Hybrid Transactional/Analytical Processing）。
先日、SingleStoreの技術的な話を聞く機会があり、久しぶりにHTAPについて考える機会となり刺激を受けた。
今回は、そのHTAPという概念の歴史をたどりながら、「HTAPを名乗る」製品群がどこで詰まってきたか、そしてSingleStore がそれを本当に乗り越えつつあるのかどうかを、SIGMOD 2022*¹のSingleStoreに関する論文*²をベースにして、久しぶりに現役エンジニアの目で調べてみた。書いている内に1回の分量には収まらず、今回は前編としてHTAPとは何かと、現在HTAPと呼ばれている製品をいくつか取り上げるところまで。
（※筆者は SingleStore 関係者ではなく、特定ベンダーと利害関係を持ちません）
なお、タイトルは敬愛するフィリップ・K・ディックよりいただきましたが、お気づきになりました？
1. HTAPとは何か
HTAP は「OLTP と OLAP の間の壁を壊す」ためのアーキテクチャだ、とよく言われる。用語としては Gartner が 2014 年のレポートで作った用語であるが、以下のような定義である。
オンライン・トランザクション処理（OLTP）とオンライン分析処理（OLAP）の双方を、単一のデータベースアーキテクチャ上で同時にサポートするデータ管理の技術*³
ここで重要なのは、単なる「DBが速い」ではなく、単一のデータベースアーキテクチャ上で同時にサポートするために「壁を壊す」ことが目的だという点だ。壁とは何か。現場にいると、それはだいたい次のような形で現れる。
- OLTP（業務DB）と OLAP（DWH/分析基盤）の分離
- それをつなぐ ETL/CDC/ELT の運用
- データ鮮度（結局は数分〜数時間遅れる）
- 二重の監視・障害対応・キャパ計画
- 指標のズレ（同じ“売上”なのに数字が合わない）
HTAP が欲しい本当の理由は、派手な技術トレンドではなく、地味で強烈な運用コストの効率化、あるいはリアルタイムに分析したいというビジネスニーズにあると言える。
2. OLTP → DWH → HTAP：データベース進化のタイムライン
ここで一度、歴史を年代で大まかに整理しておく。HTAP は 2014 年に命名されたが、「同じデータで更新しながら分析したい」という欲望はそのずっと前から存在していた。
- 1970年代 – 1980年代：RDBMSの黎明とOLTPの確立
- Oracle (1979)：最初期の商用RDBMSの一つとして登場。行指向ストレージによる厳格なACIDトランザクションを提供し、OLTPの時代を切り開く。（その前に IBM System Rや Ingresがあるが、興味のある人は調べてみてください）
- Shared Nothing Architecture (1985)：後の分散データベースの基本思想となる「共有なし」の考え方がマイケル・ストーンブレーカー*⁴により提唱された。
- 1990年代 – 2000年代前半：DWHの誕生と分析専用機の時代 + OSS RDBMS
- Teradata：大規模データの集計に特化したDWH（データウェアハウス）専用機（ハードウェア）として、OLAP市場を牽引した。
- Sybase IQ (1995)：列指向データベースの草分け。DWHやOLAP用途である。
- PostgreSQL / MySQL：オープンソースのOLTPデータベースが台頭しはじめた。
- 2000年代後半：列指向（カラムストア）の衝撃
- C-Store (2005)：列指向DBMSの圧倒的な分析パフォーマンスを世に知らしめた、現代カラムストアの理論的支柱となるプロジェクトである。後の商用製品 Verticaとなる。こちらもマイケル・ストーンブレーカーによるもの。
- Oracle Exadata (2008)：ストレージサーバーにスマートスキャン機能を組み込み、ストレージ層での処理オフロードにより、OLTPとOLAPを同一システムで高速化しようとした。
- 2010年代：HTAPへの挑戦とクラウドネイティブの普及
- SAP HANA (2010/2011)：全データをメモリに保持し、行と列の両形式を同時に扱うインメモリHTAPを初めて製品化した。ただしコストの壁は高い。
- MemSQL (2011)：SingleStoreの前身。インメモリ行ストアとJITコンパイルにより、超高速なOLTPを実現した。
- Amazon Redshift (2012)：クラウドDWHの普及を決定づけた、列指向・MPPアーキテクチャのDWHである。
- SQL Server 列ストアインデックス (2012)：行指向DBに列指向インデックスを「後付け」し、既存環境でOLAPを加速させる現実的な解法を提供した 。
- Snowflake (2014)：コンピュートとストレージを完全に分離した、クラウドネイティブDWHの代表格である。
- NewSQL (2010年代中盤): CockroachDBやYugabyteDBなどが登場し、分散環境でのOLTPの難題を解決しようとした 。
- TiDB (2010年代後半)：Raftプロトコルを用いて、行指向（TiKV）と列指向（TiFlash）を同期させる「2エンジン協調型」HTAPの代表例である。
- 2020年代：HTAPは実現するのか？ クラウドネイティブ前提の時代
- SingleStore (2020)：Universal Storageを発表。行と列を一つのテーブルで統合しHTAPの実現に大きく近づいた。
- Snowflake UniStore (2022)：Snowflakeによる、既存Snowflake基盤へのHTAP機能拡張である。
- AlloyDB (2022)：Googleによる、PostgreSQL互換クラウドネイティブHTAPデータベースである。
OLTPとOLAPの根本的な対立（行指向 vs 列指向）
OLTP（Online Transaction Processing）は、銀行口座の引き落としや、EC サイトの注文登録のような、少数のレコードを高頻度かつ確実に処理するために生まれた。行指向のストレージ、厳格な ACID トランザクション、インデックス、ロックや MVCC ─ これらは「1件のレコードを即座に更新する」ために最適化されている。
OLAP（Online Analytical Processing）は、「先月の売上を商品カテゴリ別・地域別に集計したい」という需要から生まれ、数億行を一気にスキャンする用途には、列指向ストレージと MPP（大規模並列処理）アーキテクチャが圧倒的に有利だ。しかし列指向は、1行更新が来るたびに複数の列ファイルを書き換えねばならず、OLTP には向かない。
この「行指向 vs 列指向」という物理的な対立が、OLTP と OLAP を別システムに分離させてきた根本理由である。
3.「HTAP対応」を名乗る現代の製品たち ─ 本当に実現できているか？
- TiDB ─ 最も“正直な”アーキテクチャ、しかし「2エンジン協調」の壁
TiDB（PingCAP）は、HTAP を正面から設計思想に掲げた数少ないオープンソース製品で、その設計姿勢は率直で評価できる。
アーキテクチャの概要は以下のとおり。
TiKV（行指向）に書き込まれたデータは Raft プロトコルで TiFlash（列指向）にリアルタイム複製され、クエリオプティマイザがどちらのエンジンを使うか自動判断する。オープンソースで MySQL 互換、かつ水平スケールできるという点は本物の強みだ。
しかし、これは「HTAPの実現」ではなく、「高速同期付きの OLTP + OLAP 分離アーキテクチャ」に近い。 物理的に2つの独立したストレージエンジンが存在し、その協調によってHTAP に見せている構造だ。したがって、リソース競合やデータ鮮度の問題は、構造上完全には解消されない。 - Snowflake UniStore ‐ 「OLAPの王者」がトランザクションを追加してみた
Snowflake は「OLAP 特化のクラウドネイティブ DWH」として市場を制してきた。その Snowflake が 2022年頃から推進しているのが UniStore（Hybrid Tables）で、方向性は TiDB とは逆で「OLAP にトランザクションを足す」アプローチだ。
UniStore は行指向のハイブリッドテーブルを Snowflake のアーキテクチャに追加し、列指向の標準テーブルと混在できるようにする。既存の Snowflake エコシステム（Data Sharing、Marketplace、Cortex AI）とシームレスに連携できる点は強みだ。
しかし限界も明確だ。Snowflake の基盤アーキテクチャは完全に OLAP 向けに設計されており、トランザクション機能は後付けに近い。ハイブリッドテーブルの行ロック粒度や、高頻度 OLTP ワークロードでのスループットは、専用 OLTP エンジンには遠く及ばない。 Snowflake は「分析の文脈でトランザクションが欲しい」というユースケースには応えられるが、「秒間数万トランザクションの OLTP と重い集計クエリを同時に」という本格的な HTAP の要求には、まだ答えられない。 - AlloyDB – PostgreSQL互換の最も賢いアプローチ
AlloyDB（2022年 GA）は、この文脈で最も設計が興味深いプロダクトの一つで、PostgreSQL 互換を保ちながら、機械学習を活用してキャッシュする列を適応的に選択し、行データを列形式に変換するという斬新な仕組みを採用している。
AlloyDB の最大の強みは、既存の PostgreSQL ユーザーが移行コストを最小化しながら HTAP に近づける点だ。psql が使える、pg_dump が使える、既存のドライバがそのまま動く。エコシステムの豊かさは他の HTAP 候補には真似できない。
ただし構造的な限界もある。列ストアは Primary Instance の WAL を非同期に読み取って構築されるため、TiDB と同様にデータ鮮度のラグが存在する。そして Google Cloud 専用のクローズドサービスである。 - その他の候補 – 各製品の「HTAPへの距離」
Oracle Database 23c（In-Memory + Exadata）は、インメモリ列ストア（IMCS）を行ストアと並列維持し、クエリが自動的に最適パスを選ぶ。技術的成熟度は高いが、ライセンスコストが圧倒的で大企業以外には現実的でない。
SAP HANA は全データをメモリ上に行・列両形式で同時保持するアーキテクチャで、概念的な HTAP 純度は現存するすべての製品の中で最も高い。更新もスキャンも同一メモリ上で完結するため、データ同期のラグがない。しかし裏返せば、テラバイト級データをメモリに収めるハードウェアコストが致命的で、SAP のライセンス体系と合わさって「技術的には最良だが、使える組織が限られる」製品になっている。コスト制約を無視した純粋な HTAP 実装という意味では依然トップだが、ほとんどのエンジニアにとっては「触れない夢」だ。
Microsoft SQL Server（列ストアインデックス）は最も普及した「HTAP 的な機能」の実装だ。2012年以来着実に改善が続いているが、本質は「行指向 RDBMS への後付け」であり、更新頻度の高いテーブルでのデルタストア肥大化やロック競合は今も課題として残る。
今回はここまで。
本稿では、SIGMODにおけるSingleStoreの論文まで十分に触れられなかったため、次回はさらに深掘りしていきたい。
脚注・参考
*¹SIGMOD (世界最大の計算機学会であるACMが設置している、データ管理に関する特別興味グループ（Special Interest Group on Management of Data）の略称。SIGMODで採択される論文は、将来的にデータベースのスタンダードになるような技術を含むことが多く、産業界からも非常に注目されている。
*²Cloud-Native Transactions and Analytics in SingleStore（https://dl.acm.org/doi/epdf/10.1145/3514221.3526055）
*³Gartnerの2014年の原文では、HTAPは “an emerging application architecture that ‘breaks the wall’ between transaction processing and analytics” と定義されており、アプリケーションアーキテクチャという言葉が使われていた。当時のGartnerはインメモリ技術（SAP HANAなどに代表される）を前提として想定しており、「アプリケーション全体の設計思想」としてHTAPを位置づけていた。その後、インメモリに限定しない分散・クラウドネイティブなデータベースが台頭するにつれ、HTAPは「データベースアーキテクチャ」の文脈で語られることが主流となった。Gartner自身も定義を段階的に拡張しており、2018年頃には「In-Process HTAP」という概念を追加してインメモリ限定の制約を外した。さらに近年のGartnerのレポートでは、HTAPという用語そのものを使わず、”Augmented Transactions”（トランザクションにAI・MLを組み込む概念）や “Operational Intelligence” といった新しい分類の中にHTAPの概念を内包させている。なお、Forrester ResearchはHTAPと同じ概念を “Translytical”（transactional＋analytical の造語）、451 GroupはHOAP（Hybrid Operational and Analytical Processing）と呼んでいる。
*⁴マイケル・ストーンブレーカー(Michael Stonebraker) RDBMSの父と呼ばれている。RDBMS先駆けのIngres, オブジェクトRDBMSの POSTGRES (後のPostgreSQL) を開発し、他には Informix, Vertica, Tamrなどの設立に関わる。余談であるが DWHの父はビル・インモン(Bill Inmon)で、昔、弊社主催のデータベース技術カンファレンス db tech showcaseの基調講演に来日されたことがある。