🎩
HTAPとは何か？

2024/12/17に公開
(これはHTAPデータベース アドカレ2024 の1日目の記事です。)

 HTAPとはHTAPとは、
『Hybrid Transactional and Analytical Processing』
の略語であり、オンライントランザクション処理（OLTP）と分析処理（OLAP）を同時に実行すべく考えられた方式や、それを実装したデータベースを指します。
現在のデータベース利用においても、技術的理由やコスト・リソース面など様々な点に課題があり、2つのワークロードを同時に捌くことは容易ではありません。そのため、OLTP用データベースとOLAP用データベースは分割されることが多くなっています。

そもそも、用途別にデータベースを使い分けようという考え方を掲げるクラウドもあります。
では、HTAPとはそうした課題をクリアした「なんでもこなせる夢のデータベース」なのでしょうか。

本日の投稿の趣旨としては、Noです。
これは私だけの考えではなく、HTAPデータベースの開発をしているPingCAP社も過去に提唱していた意見です。
HTAPデータベースでデータウェアハウスを完全に置き換えることができないユースケースがあります。TiDBの場合、500 TBの制限と、すべてのデータを「ホット」として保存する高コストにより、これらの制限内に収まるユースケースへの適用が制限されます。当社のエンジニアはこれらの制限を克服するために懸命に取り組んでいますが、一方で、TiDBのようなHTAPデータベースには解決すべきユースケースがまだたくさんあると強く信じています。
（PingCAP社blogより自動翻訳）
今我々が利用できるHTAPデータベースは、OLTP＋OLAPのフルセットではなく、
リレーショナルデータベースから出発して、カラムナストア等の分析機能を具備したもの
DWHから出発して、OLTPの更新にも耐えられる性能・機能を備えたもの
のどちらかであり、OLTPまたはOLAPの専用で超高速処理を謳うデータベースと比較すると中途半端に見えることもあります。
しかし、それでもこれまで実現できなかった機能や使い勝手をユーザに提供するデータベースとして注目されています。

 HTAP≒リアルタイムOLAP?データベースのベテラン技術者に聞けば、HTAPという名前で思い出すのはSAP HANAかも知れません。
個人的にはHANAは触れる機会がなく、「すごいものが出てきた👀」という感想しかなかったのですが、その後もOracle Database In-Memory（DBIM）など、商用データベースにおいて分析機能強化という流れでHTAPの実装が続く時期がありました。
自身の経験としては、2008頃にSQL Server Analysis Services（SSAS）の検証をしています。こちらは今日良く見るカラムナストアではなく、多次元データモデル（キューブ）を構築して高速分析を行うものでしたが、
過去データは多次元モデルで事前構築して高速に分析する（MOLAP）
最新データはリレーショナルデータベースから取得して分析する（ROLAP）
上記のMOLAPとROLAPを組み合わせて、性能とデータの最新性をバランスさせて分析する（HOLAP）
という考え方がありました（参考）。
このROLAPやHOLAPの考え方は、HTAPに似ていると今になって思うわけです。

 近年のHTAPの盛り上がりでは近年、2020年以降にHTAPデータベースが改めて注目されるようになってきたのは何故でしょうか。
例えば、以下のようなHTAP機能を備えたデータベースを見ていると、2つのキーワードに気付きます。「クラウドサービス」そして「NewSQL」です。

HeatWave MySQL -> クラウド

AlloyDB for PostgreSQL -> クラウド

TiDB -> NewSQL
これは以前のblogで紹介した内容ですが、クラウド向けに開発されたデータベースではComputeとStorageが分離されます。
そうすると、以下のようなコンポーネント配置が可能になり、HTAPデータベースの実装が比較的容易になりました。
オンラインクエリと分析クエリ両方を受け付けて、適切なStorageに処理を投げるCompute
オンライン用の行（レコード）形式でデータを格納するStorage
分析用に列（カラムナ）でデータを格納するStorage ※メモリに格納する場合もあり
【最近のHTAPデータベースの構成例】



（自身の登壇資料より）

 DuckDB is eating Postgres?前節の話題は、私が主戦場とするリレーショナルデータベースを起点としたHTAPの盛り上がりについてですが、市場を見るともう1つ大きな流れが来ていることに気付きます。
それが分析系DB側からリレーショナルデータベースを統合しようとする動きです。
PostgreSQLでDuckDBを扱うpg_duckdbというextensionが人気で、オブジェクトストレージ上のデータレイクから高速に分析処理を行うことができるということで注目されています。これを使うことにより、ETL処理をPostgreSQLからSQLで行うことができ、データパイプラインの開発工数などを削減し、処理時間も短縮されます。

（こちらのblogが大変参考になります。）
【pg_duckdbの構成】



（Hydra社のドキュメントより）
※この節のタイトルはこちらのオマージュです。

 まとめ今年夏頃までの私の考えは、NewSQLなどの分散DBがカラムナストアの機能を備えてリアルタイム分析のユースケースを充足するようになる、というものでした。
しかし、pg_duckdbの登場で（おそらく私が気付かなかっただけでそれ以前から）状況は大きく違って見えてきています。
クラウド上の巨大なオブジェクトストレージに構築されたデータレイクを、従来のリレーショナルデータベースをインターフェースとして扱う形式が主流になり、更新の無い過去データはデータベース上に持つ必要がない世界線が実現する可能性もあります。

つまり、カラムナストアはデータベース・ストレージの1つの形態ではなく、Parquetなどに代表されるオープンなフォーマットで格納された外部ストレージになります。
2024年末の時点では、どちらが生き残るのか、または両立するのかは正直見えていません。
もし時間があれば、両方の形式を実際に試してみて気づいた点などをまとめてみたいと思います。
HTAPとは

HTAP≒リアルタイムOLAP?

近年のHTAPの盛り上がり

DuckDB is eating Postgres?

まとめ

Discussion
