ハイブリッドトランザクション/分析処理 (HTAP) データベースは、OLTPワークロードとOLAPワークロードを、互いに干渉することなく同じアーキテクチャで処理できます。 Gartnerは2014年にHTAPという用語を作り出し、SAP HANAなどのハイブリッドワークロード処理機能を備えたインメモリデータベースを指すようになりました。
しかし、技術的な課題がHTAPデータベースの普及を妨げてきました。ごく最近になって、TiDB、GoogleのAlloyDB、SnowflakeのUnistoreといった最新のデータアーキテクチャが登場し、HTAPが台頭してきました。
この投稿では、HTAPの利点と、HTAPを可能にする技術的進化について共有します。また、最新のHTAPアーキテクチャにおける主要な課題と、TiDBとAlloyDBという2つの代表的なHTAPデータベースを掘り下げることで、それらを解決する方法も説明します。
少し歴史を振り返ると…
何十年もの間、オンライントランザクション処理 (OLTP) とオンライン分析処理 (OLAP) のワークロードは、異なるデータベースシステムによって別々に処理されてきました。その理由は、この2つのワークロードは、レイテンシー、スループット、データの一貫性など、設計要素が異なるためです。このため、個々のデータベースシステムは、OLTPとOLAPのどちらかのワークロードに焦点を当てることになります。たとえば、業務用データベースは通常、非常に短いレイテンシーを必要としますが、データウェアハウスやデータレイクシステムは、はるかに長いレイテンシーを許容することができます。
図1. 各種データベースシステムの代表的なレイテンシー
しかし、そのために複雑なテクノロジースタックやデータサイロが発生し、企業の成長スピードが制限されることになります。このため、ハイブリッドなアプローチが必要とされています。
HTAPの魅力
実装方法にかかわらず、最新のHTAPアーキテクチャは通常、クラウドの拡張性を備え、1つのインフラストラクチャ・スタックで1つのデータ入力を行うことができます。そこでは、OLTPデータとOLAPデータをリアルタイムで同期させることができます。OLAPの実装の中には、MPP (Massively Parallel Processing) プッシュダウン・アプローチを使用して、アプリケーションやスキーマ、ETL (抽出、変換、ロード) プロセス、または異なるシステム間でデータを移動することなく業務データを分析するものもあります。
HTAPシステムでは、データ集約型のアプリケーションを、ミッションクリティカルな運用やトランザクションワークロードから直接実行することができ、より簡単でモダンなアーキテクチャ設計と実装が可能です。適用できるシナリオは、リアルタイムのビジネスインテリジェンス、リアルタイムにパーソナライズされたレコメンデーション、レポート、オンライン操作分析、eコマースのリアルタイムマーケティングなど多岐にわたります。
HTAPは、データインフラスタック全体とアプリケーション開発を大幅にシンプルにすることができます。これにより、市場投入までの時間を大幅に短縮することができます。一例として、HTAPシステム上に構築されたオープンソースのインサイトウェブサイトであるOSS Insightは、市場投入までの時間を数ヶ月からわずか数週間に短縮しました。今後のHTAPの記事では、その他の利点について説明する予定です。
HTAPを実現するために
TiDBやAlloyDBのようなデータベースシステムは、最新のアーキテクチャ設計により、スケーラブルな分散SQLアーキテクチャ、行・列ベースのストレージエンジン、Raftベースのレプリケーション、分散ベクトル化実行エンジン、高度なコストベースのオプティマイザなどの技術を活用しています。これらのシステムは、OLTPとOLAPの処理機能を1つのシステムに組み込んでいます。
このセクションでは、HTAPを実装する際の主な課題を紹介します。また、2つのHTAPシステム、TiDBとAlloyDBを紹介し、それらがどのようにこれらの課題を克服し、HTAPを実現したかを紹介します。
主な課題
前述の通り、HTAPは新しい概念ではありませんが、最近まであまり注目されていませんでした。HANAのようなHTAPのインメモリアプローチは高速でしたが、高価で独自性のあるデータベースでした。モダンかつより実用的なアプローチには、大きな技術的課題があります。例えば、行と列のストレージを活用して書き込みと読み込みのパフォーマンスを最大化する方法、クエリの最適な実行プランを決める方法などです。
行ベースと列ベースのストレージ・エンジン
OLAPクエリは通常、バッチ処理で効率的にデータにアクセスするために列フォーマットストレージを使用します。一方、OLTP業務では、集中的に書き込みを行うために行ストレージが有効です。そのため、従来のデータベースでは、1つのシステムで行ストアと列ストアを活用してハイブリッドワークロードのパフォーマンスを向上させることは困難でした。これが、HTAPデータベースが解決すべき主要な課題です。
図2. 行ベースのストレージと列ベースのストレージの比較
スマートなクエリオプティマイザ
データベースの重要な構成要素のひとつに、クエリオプティマイザがあります。その機能は非常に複雑で、オプティマイザの設計は”ロケット科学よりも難しい”と言われることもあります。下記課題は、HTAPのワークロードを最適化することになると、より困難なものとなります。
- より多くのプランが評価されるため、最適なプランを探索するための探索空間が大幅に拡大する。
- 異機種混在のストレージエンジンは、オプティマイザがクエリ実行エンジンの演算子を区別するためのコスト見積もりにおいて、さらなる課題をもたらす。
したがって、HTAPのためのスマートなクエリオプティマイザは、これらの課題を克服し、HTAPワークロードを効率的に処理する方法について正しい判断を下します。
HTAPの実例：TiDB
TiDBは、HTAP機能を提供する唯一のオープンソース、MySQL互換のデータベースです。様々な業界の何千ものプロダクションシステムで、プライマリデータベースとして採用されています。TiDBのHTAPアーキテクチャは、コンピューティングとストレージを分離したデカップルドアーキテクチャを使用しているのが特徴です。ハイブリッドワークロードのための行ストレージと列ストレージを実装しており、内部にいくつかの主要な技術を備えています。
TiDBのHTAP実装の詳細については、VLDBで発表した論文「TiDB: A Raft-based HTAP Database」をご覧ください。
デカップルドアーキテクチャ
Tクラウド時代の弾力的なインフラを最大限に活用するため、TiDBは柔軟なスケーラビリティを実現する分散型アーキテクチャを採用しています。TiDBクラスタは3つの主要コンポーネントで構成されています。
- TiDBサーバーは、SQLリクエストを受信して処理します。
- Placement Driver（PD）はクラスタのメタデータを管理し、分散トランザクションのためのグローバルクロックサービスを提供します。
- ストレージサーバーは、TiKV行ストアとTiFlash列ストアにデータを保存します。
図3. TiDBのHTAPアーキテクチャ
このアーキテクチャでは、コンピューティングリソースとストレージリソースが分離されており、それぞれを独立してスケールすることが可能です。TiDBは行と列の両方の形式のストレージエンジンを統合し、データへのアクセスに最適な方法を決めます。TiKVは行ストアによるOLTPシナリオ用に特別に設計されており、TiFlashはOLAPワークロード用の列指向のストレージです。
分散型実行エンジン
TiDBの分散型実行エンジンは、TiDBサーバランタイム、分散型TiKVコプロセッサ、TiFlash超並列処理（MPP）実行エンジンの3つの部分から構成されています。下図はTiDBの一般的な実行イメージ図です。
図4. TiDB実行図
TiDBサーバランタイムは、実行の”コーディネーター”として機能します。TiKVコプロセッサーはTiKV行ストアとともに配置され、”ニアストレージ”の計算を提供します。これにより、TiDBは各TiKVインスタンス上のデータを並列に処理することが可能です。
同様に、TiDBは射影、選択、集約、ソート（TopN）、分散JOINをTiFlash MPPの実行エンジンにプッシュダウンします。これにより、TiFlash MPP実行エンジンは、複雑な分析処理を行うことができます。
TiKVコプロセッサとTiFlash MPP実行エンジンを組み込むことで、TiDBはクエリを効率的に処理することができます。行ストアや列ストアだけでは対応できないHTAPワークロードを処理することができます。
スマートオプティマイザの実例
前述したように、クエリの正しい実行プランを決定するクエリオプティマイザをどのように実装するかは、HTAPワークロードにとって最重要課題です。TiDBの答えはTiDB optimizerです。これは、行と列の両方のストレージと実行エンジンを最適に活用できるクエリプランを生成するものです。このオプティマイザは、行データと列データのどちらを使用するかを決定するだけでなく、各「プッシュダウン」計算に対してどの実行エンジンを使用するかも考慮しています。
最適化されたプランでは、TiDBオプティマイザは可能な限り多くの計算を分散型行ベースコプロセッサやMPP実行エンジンにプッシュダウンします。これにより、分散計算の利点を生かし、中間結果を減らすことができます。また、TiDBサーバーの計算負荷も最小限に抑えることができます。
図5. TiDBオプティマイザが生成したクエリとそのプラン
TiDB上で実行されるOpen Source Software Insightプラットフォーム (https://ossinsight.io) のクエリ例を紹介します。このクエリは、2021年にGitHub上で最も多くのデータベース貢献を行った国や地域を調べるものです。TiDBオプティマイザーの力を借りて、生成されたプランはTiKV行ベースコプロセッサーとTiFlash列ベースMPP実行エンジンの両方を活用します。図のクエリプランでは、TiKVの行ストアではユーザーテーブルへのインデックスアクセスが、列ストアのTiFlash MPPエンジンではテーブルgithub_eventsとdb_reposの分散ハッシュ結合が選ばれていることがわかります。
HTAPの実例：AlloyDB
AlloyDBは、Googleが新たに発表したHTAPシステムで、オープンソースのPostgreSQLとの互換性を持ち、レガシーデータベースの近代化をサポートするものです。AlloyDBのコアは、コンピュートとストレージを分離した最適化ストレージサービスとなっています。次の図は、そのハイレベルなアーキテクチャを示したものです。
図6. AlloyDBのハイレベルなアーキテクチャ
AlloyDBの主要な設計や技術には、以下のようなものがあります。
- インメモリカラムデータ：機械学習（ML）支援による予測に基づいて、カラムデータはユーザーの操作なしに自動的に生成され、更新されます。
- コンピュートとストレージの分離：データベース（コンピュート）層とストレージサービスを分離することで、ログ処理などのオペレーションをストレージ層にオフロードします。キャッシュの階層化により、パフォーマンスとスケーラビリティを向上させることができます。
- ML支援による管理・推論機能：AlloyDBは、ML技術を活用して、ストレージやメモリ管理、列データ変換、バキューム管理など、さまざまなシステム最適化を実現し、ユーザーがクエリでそのMLモデルを呼び出すことを可能にします。
AlloyDBの詳細については、ドキュメントやリリースブログ「Introducing AlloyDB for PostgreSQL」をご覧ください。
TiDBとAlloyDBの同一条件での比較
本セクションでは、データベースシステムの様々な側面からTiDBとAlloyDBを比較・分析します。HTAPデータベースとしての共通点、相違点が見えてきます。
全体像と機能性
TiDBは完全なオープンソースデータベースシステムで、3つのカーネルコンポーネントであるTiDB、TiKV、TiFlashはすべてオープンソースプロジェクトであり、TiKVはCNCFのGraduated (卒業) プロジェクトとなっています。AlloyDBはオープンソースのPostgreSQLと「互換性」がありますが、独自の機能はどれもオープンソース化されておらず、オープンソース化の計画もありません。
TiDBはMySQLと互換性があり、一方AlloyDBはPostgreSQLと互換性があります。この互換性により、現在MySQLやPostgreSQLを使用しているユーザーは、余分な労力をかけずに簡単にアプリケーションを新システムに移行することができます。
AlloyDBとTiDBは、ともにML技術を採用しています。AlloyDBはMLの推論計算を拡張SQL構文に統合し、インメモリのカラムデータを生成するタイミングを予測するなどのシナリオで活用されます。TiDBは、システムチューニングサービスにMLを活用しています。
クエリ処理エンジン
TiDBとAlloyDBのクエリ処理エンジンは、クエリオプティマイザによる判断で、行フォーマットと列フォーマットのデータを同時に処理することが可能です。これにより、OLTPとOLAPのハイブリッドワークロードをクエリ処理エンジンを最適に活用して処理することができます。
TiDBとAlloyDBのクエリ処理エンジンの主な違いは、分散クエリ処理エンジンを利用しているかどうかです。TiDBのクエリ処理エンジンは、TiDBサーバーランタイム、TiKV分散コプロセッサ、TiFlash MPP実行エンジンから構成されています。後者の2つは、TiDBを強力な分散処理能力で強化されています。一方、AlloyDBは、1つのノード (プライマリサーバノード、またはレプリカサーバノード) でデータの取得とクエリの計算を行います。
行・列データストレージ・エンジン
TiDBとAlloyDBは、どちらも行フォーマットと列フォーマットのデータをサポートしています。ただし、AlloyDBは行フォーマットのデータのみを永続的な共有ブロックストレージとLogic Production System (LPS) ノードのブロックキャッシュに保存します。
列データはオンデマンドで生成され、プライマリサーバノードやレプリカサーバノードのメモリキャッシュに格納されます。データが大きくなると、スケーラビリティが性能のボトルネックになる可能性があります。
一方、TiDBは行と列の両方のフォーマットデータを永続ストレージに保存します。TiDBはRaftベースのレプリケーションアルゴリズムにより、常にカラムデータを複製しています。これにより、TiDBは遅延やデータ損失なしにリアルタイムでカラムデータにアクセスすることができます。TiDBの分散アーキテクチャは水平方向のスケーラビリティを特徴としています。
行と列の両方のフォーマットデータをストレージエンジンに保持することで、より優れたリソース分離が可能になることも利点の1つです。TiDBの場合、TiKVとTiFlashは行と列のフォーマットデータを互いに影響を与えずに処理することができます。多くのシナリオで、この分離はクエリ処理の性能 (例えばスループット) と安定性の向上に大きく貢献します。
HTAPの2大データベースの比較。TiDB vs AlloyDB
| TiDB | AlloyDB | |
| SQLの互換性 | MySQL | PostgreSQL |
| フルオープンソース | Yes | No |
| 高可用性 | あり(クロスゾーン、リージョン) | あり (クロスゾーン) |
| スケーラビリティ | 制限なし | 最大1000vCPUまで |
| デプロイメント | マルチクラウド (AWS、GCP) 、プライベート | クラウドサービス (GCPのみ) |
| 動的なリサイズ | 対応 | 対応 |
| ストレージ | ローカルストレージ、Elastic Block Store (EBS) | 分散ファイルシステム(Colossus) + ティアキャッシュ |
| 永続的なストレージ | 列、行 | 行 (インメモリカラム) |
| カラムデータ定義 | ユーザーによるデータ定義言語(DDL)の実行で制御 | システム決定(またはコマンドで設定) |
| リアルタイムカラムデータ | あり (ラフトベースレプリケーション、MVCC) | なし (オンデマンド変換、AIによる予測) |
| クエリ実行エンジン | 分散行ストアコプロセッサ＋MPPカラムナエンジン | MPPモードなしの単一実行ノード |
| カラムナ実行 | ベクトル化 | ベクトル化 |
| ストレージ層での計算プッシュダウン | フィルタリング、アグリゲーション、LIMIT、TopN、JOIN | なし |
| ML統合 | TiDB Autonomous Serviceと統合 (チューニングとアドバイザリーのみ) | Vertex AI Platformと統合 (チューニングとML推論の両方) 。 |
まとめ
TiDBとAlloyDBは、どちらもプライマリデータベースとして、急速に増加する複雑なビジネスワークロードに対応できます。特に、従来のOLTPやOLAPのデータベースでは処理しきれないようなワークロードを処理する場合に有効な選択肢となります。
TiDBとAlloyDBには、それぞれ長所と最適なシナリオがあります。エコシステム、ビジネス成長、ワークロードに基づき、ビジネスにフィットする堅実なソリューションです。
両者ともHTAPの時代が来ることを明らかにしており、今後ますます多くのHTAPシステムが登場することが予想されます。
HTAPのその他のリソースをいくつか紹介します。
TiDB Cloud Dedicated
TiDB Cloudのエンタープライズ版。
専用VPC上に構築された専有DBaaSでAWSとGoogle Cloudで利用可能。
TiDB Cloud Serverless
TiDB Cloudのライト版。
TiDBの機能をフルマネージド環境で使用でき無料かつお客様の裁量で利用開始。