HTAPデータベースはどのようにOLTPとOLAPのワークロードを同時に処理しているのか

※このブログは2022年3月7日に公開された英語ブログ「How an HTAP Database Handles OLTP and OLAP Workloads at the Same Time」の拙訳です。

データベースの世界で重要な考え方は、目的に特化したデータベースは汎用目的のデータベースよりも優れているということです。A.M.チューリング賞受賞者であり、データベースの世界で最も影響力のある人物の1人であるMichael Stonebraker氏も、彼の論文である”One Size Fit All: An Idea Who Time Has Gone Gone”でこの点について論じています。

オンライントランザクション処理 (OLTP) またはオンライン分析処理 (OLAP) のワークロードのいずれかをサポートするデータベースよりも、両方を同時にサポートするデータベースを構築することは言うまでもなく大変である、これは合理的な判断です。しかしジレンマとして、今日多くのユーザーがOLTPとOLAPの混合ワークロードの需要の増大に直面しています。このジレンマをどのように解決すればいいでしょうか?

PingCAPでは、混合ワークロードを処理できるハイブリッドトランザクションおよび分析処理 (HTAP) データベースであるTiDBというソリューションを提供します。この投稿では、HTAPの秘密とHTAPデータベースがユーザーの問題解決にどのように役立つかを明らかにします。

HTAP ≠ OLTP + OLAP

セクションのタイトルが示すように、HTAPはOLTPとOLAPの直接的な統合ではありません。

良い例えはキャンピングカーです。「車輪付きの家」と呼ばれることもありますが、実際には車と家の組み合わせではありません。代わりに、キャンピングカーはユニークな体験であり、特別なニーズを満たすための特別な製品です。HTAPもそうです。

HTAPはOLTP、OLAPまたはその2つの組み合わせだけでなく、特殊なシナリオ向けに設計されています。

HTAPシナリオの台頭

近年、リアルタイムのデータ処理と分析の需要が急速に高まっています。オフラインデータ処理に特化した従来のデータベースは、ユーザーの増大するニーズに対応できていません。これには主に2つの理由があります。

まず最初に、リアルタイムデータ処理のテクノロジースタックは常に開発され、発展しています。例としてビッグデータエコシステムを取り上げます。リアルタイム計算フレームワークは、単純なセマンティクスを備えたApache Stormから、その上にTridentを備えたApache Storm、そして複雑なセマンティクスを備え、組み込み状態ストレージに補完されたApache Flinkに進化しました。これらすべての変更の後、ストリーム処理フレームワークは、多くの複雑なリアルタイム分析シナリオで広く採用されています。これらのフレームワークは、異なる特性を持つダウンストリーム処理とペアになっており、リアルタイムアプリケーションのイノベーションを加速します。

さらに、ユーザーは業務をリアルタイムでデジタル化するための新しいアイデアを試し続けています。テクノロジースタックが使いやすくなるように。そしてデータベース技術の開発はリアルタイムアプリケーションの普及も促進させます。

第二に、デジタルトランスフォーメーションプロセスは従来の多くの業界で加速しており、新しい需要を生み出しています。かつては不可能だったタスクの処理は、今ではうまく運営されているビジネスの要件になっています。

例として中国の速達便業界を取り上げます。市場規模が拡大し続けるにつれて、配達注文は非常に大きく増加しました。注文のリアルタイム監視と分析は必要不可欠になり、リアルタイムの配送ルートの最適化やペナルティ管理など、運用のあらゆる側面を最適化するのに役立ちます。従来のオフライン分析では、特にトランザクションのピークが発生する大規模なセールにおいて、これらの要求を満たすことができませんでした。

今日、ますます多くのユーザーが純粋なOLTPまたはOLAPではなく、ワークロードが混在するシナリオに直面しています。私達はこのことをHTAPシナリオと呼んでいます。従来のOLAPソリューションでは、新しい要求に応えることはとても面倒です。純粋なOLTPデータベースの場合も同様です。ユーザーが本当に望んでいるのは、OLTPデータベースとOLAPデータベースの間にあるソリューションです。

HTAP—PingCAPのソリューション

PingCAPにおいて、私達の製品戦略はTiDBがOLAP機能を補完したOLTP指向のデータベースであるということです。つまり、私たちの野心はOLTPとHTAPの分野にあります。今日はHTAPについて説明しているので、OLTPの部分は省略してHTAPに焦点を当てます。

HTAPがOLTPとOLAPの直接的な組み合わせではない理由については既に説明しました。私たち自身の経験を踏まえてもう少し詳しく説明しましょう。

以前は多くのデータを中継するアプリケーションのシナリオに直面していました。ユーザーは、異なるビジネスラインのデータサイロから同じリアルタイムの一元化されたデータストアにデータを統合してから、その上にデータサービスと分析を提供することを意図していました。別のケースでは、ユーザーはOLTPデータベースから複製されたリードレプリカを構築することを計画しました。このレプリカは、個別の分析ワークロードとデータサービスワークロードをサポートし、無制限のクエリと分析サービスに応答するために使用されました。

上記のシナリオでは、データベースで次のことを行う必要があります。

• 従来のデータウェアハウスと同様の分散アーキテクチャを使用して、同様の規模のデータ集約を維持する
• トランザクションデータベースと同様にデータの一貫性とリアルタイムパフォーマンスを確保し、インデックスベースのデータ呼び出しと列ストアに基づく大規模な分析も提供する
• オフラインのデータウェアハウスとスムーズに接続する

つまり、データベースはOLTPとOLAPの混在ワークロードに重点を置く必要があります。また、下記の要件が必要ないため、従来のデータウェアハウスよりも軽量になる可能性があります。

• オフラインシナリオ用に複雑なコンピューティングモデルを内部に配置する
• ペタバイトのデータストレージをサポート、リアルタイムデータの量は通常のデータウェアハウスのコールドストレージの制限に達しない

また、主要なタスクがトランザクション処理でしたが、リアルタイム分析が必要になるシナリオにも遭遇しました。

HTAPは、まさに上記のシナリオと言えます。TiDBのHTAP機能はこれらの要件に合わせて設計されており、リアルタイム、アジャイル、軽量です。

• ユーザーは、統合されたフロントエンドを介して、トランザクションへのアクセスと分析クエリを同時に行うことができる
• 行ストアと列ストアは、リアルタイムで一貫性が保たれる
• 行と列のリソースは分離され、レプリケーションメカニズムによって負荷分散と自動障害回復が保証される
• トランザクションサービスはステートレスなスタンドアロンのサービスノードグループで処理され、分析クエリはベクトル化高速化された超並列処理 (MPP) モードで処理される

次の図は、TiDBがOLTPワークロードとOLAPワークロードを同時に独立して処理する方法を示しています。

TiDBのアーキテクチャ

加えて、ワークロードが混在するシナリオでは、複雑なタスクを綺麗に分割し、さまざまな種類のデータベースを使用してそれらに対応させることは不可能です。しかし、TiDBを採用すれば、すべては異なります。

TiDBは、ユーザーが従来のデータベースと同じように複雑なインデックス作成で同時実行性の高い短いクエリを作成するためのデータハブとして使用できます。また、同じ論理データに対してTiDBの列ストアとMPPテクノロジーを使用して、大規模なリアルタイム分析を高速化することもでき、そのパフォーマンスは従来の特殊なOLAPデータベースよりも劣ることはありません。さらに、TiDBのコストベースのオプティマイザー (CBO) は、さまざまなタイプのクエリをさまざまなストレージまたはコンピューティングエンジンに自動的に割り当てることができます。

ユーザー事例

TiDBのHTAP機能が、お客様が問題を解決してビジネスの成功を達成するのにどのように役立っているかを見てみましょう。

ZTO Express 

ZTO Expressは中国の大手速達便会社であり、世界最大の企業の一つです。彼らはフルリンクのロジスティクス管理プラットフォームデータベースとしてTiDBを使用しています。

管理プラットフォームでは、配送注文のステータスは常に更新されます。多くの場合、ステータスは新規注文よりも頻繁に更新されます。管理プラットフォームは注文状況をリアルタイムで監視し、モバイルアプリケーションからの注文クエリに応答し、分析レポートがリアルタイムで保持されることを保証する必要があります。

このような要件を満たすために、彼らはデータベースで次のことを望んでいました。

• OLTPワークロードをサポートする
• モバイルアプリケーションからの同時実行性の高い短いクエリをサポートする
• 特にピークトランザクションが発生する大規模なセール中に、簡単にスケールアウトできる
• サービスパフォーマンスを損なうことなくリアルタイム分析をサポート、速達便事業は時間との絶え間ない競争である

これはOLTPワークロードとOLAPワークロードが混在する一般的なHTAPシナリオです。従来のデータベースソリューションを選択する場合は、非常に複雑なアーキテクチャを導入する必要があります。代わりに、TiDBのHTAP機能は上記のすべての要件を完全に満たすことができます。下の画像は、TiDBがお客様の混合要件を処理する主なプロセスを示しています。

TiDBのメインフローはZTO Expressの様々な要件を処理

さらに加えて、TiDBはZTO Expressに役立つことになりました。

• リアルタイムの配達追跡日数が30日から45日に増加
• IT効率が300%向上
• リアルタイムレポートの応答時間が5分から1分以内に短縮
• 以前のExadataソリューションと比較して低コストで、リアルタイムデータトラッキング日数が30日から45日に増加

中国の大手インターネット企業

こちらの顧客は中国の大手インターネット企業です。彼らは包括的な広告クエリと監視サービスをサポートするためにTiDBを広告システムに展開しています。

広告データはリアルタイムでTiDBに書き込まれます。ピーク時には、TiDBは広告の詳細とレコード、インデックスフィルタリング、列ストアとMPPアーキテクチャに関連する分析クエリなど、混合リクエストを使用して最大数十万/秒 (QPS) に応答する必要があります。

同じデータに対するこのような混合タイプのクエリには、TiDBが最適です。TiDBのHTAP機能は、データ同期中の異なるシステム間のリアルタイムのデータ整合性を完全にサポートします。さらに、従来のデータベースの組み合わせを使用する場合、異なるストレージエンジン間で多様なクエリ条件を手動でルーティングすることは困難です。しかし、CBOを備えたHTAPソリューションであるTiDBは、さまざまなクエリをさまざまなストレージまたはコンピューティングエンジンに自動的に割り当てることができます。

下の画像は、TiDBがこの顧客の混合ワークロードを処理する主なフローを示しています。

TiDBのメインプロセスはこの顧客の混合ワークロードを処理

さらにTiDBはこの顧客の役に立つことができました。

• TiDBのよりシンプルなアーキテクチャにより、サーバーコストの少なくとも40%を節約
• 年間ショッピングのピーク時に記録的な250,000QPSで安定したパフォーマンスを維持
• リアルタイムレポートサービスをサポートし、詳細なデータリコールと多次元分析の両方を維持

その他のお客様の成功事例については、こちらをご覧ください。

まとめ

HTAPは厳密にはOLTPとOLAPの組み合わせではなく、ハイブリッドで独自の領域です。TiDBのHTAP機能は、ワークロードが混在する特別なシナリオ向けにしっかりと設計されており、リアルタイム、アジャイル、軽量の3つの主要な特性があります。

TiDBに新しい機能を追加するたびに、私たちは3つの特性が損なわれていないか確かめています。TiDBが従来のデータベース製品との不必要な競争に陥り、その優位性を失うことは望ましくありません。

HTAPについてもっと知りたい場合は、私たちのSlackチャンネルに参加してTiDBの専門家に相談してください。お問い合わせいただき、デモをリクエストすることもできます。