多くの企業が、大量のデータをリアルタイムで分析する必要があります。これにより、将来のリスクを特定し、リソースを効果的に配分し、顧客に商品・サービスを迅速に提供することができます。しかし、DBMSに保存するデータ量が増加するにつれ、データの取得や処理にかかる時間が長くなります。データを蓄積すればするほど、それをリアルタイムで処理することがますます難しくなってきます。

PingCAPは、ハイブリッドトランザクション/分析処理（HTAP）の優れたワンストップサービスを提供するため、オープンソースの分散型SQLデータベースであるTiDBのバージョン5.0をリリースしました。この記事では以下の項目を説明します。

• 現行のテクノロジースタックでは、なぜビジネスニーズに対応できないのか
• TiDB 5.0のHTAPアーキテクチャでは、何が新しくなったのか
• TiDB 5.0はどのようにして、単一のスタックでさまざまなシナリオに対応するのか

現行のテクノロジースタックでは対応できない

企業は大量のデータをリアルタイムで処理する能力を切望していますが、これはそれほど単純ではなく、実際のところ難しい課題です。

この課題に対応する目的で、多くのリソースをたやすく投入できる企業もあります。インターネット企業ならば、洗練されたデータシステムを構築し維持するための、大規模なエンジニアリングチームを組織することができるでしょう。しかし、こうした対応は、従来型企業にはまず無理だと思われます。

さらに悪いことに、現行のビッグデータスタックではこの課題に対処できません。ビジネスが驚異的なスピードで進化し、データが飛躍的に増加する中、既存のビッグデータツールではビジネス要件に応えられないケースが増えています。

シームレスなビッグデータアーキテクチャがない

ビッグデータの照会や分析をリアルタイムで行うのが難しい理由の1つは、フォアグラウンドアプリケーションとオフラインデータウェアハウス間でシームレスな接続を構築するのが難しいことです。

ハイブリッドワークロードのシナリオを考えてみます。ERPシステム、CRMシステム、MESシステムは、さまざまなパターンでデータにアクセスする必要がありますが、これらのパターンはオンライントランザクション処理（OLTP）またはオンライン分析処理（OLAP）として単純に分類できるものではありません。データ量が急増した場合、これまでスタンドアロンデータベースでアプリケーションを実行してきた企業には、アプリケーションアーキテクチャをリファクタリングする以外に選択肢はありません。しかも、リファクタリングにはかなりの時間と人的資源が必要になります。

例えばオンライントランザクションデータは、OLTPデータベースに送られた後、データレポートを行うためにその一部がオフラインデータウェアハウスに転送されます。この場合のデータ転送プロセスは、以下のような複雑なものになります。

• まず、アプリケーションサーバーは、OLTPデータベースとOLAPデータベース（データウェアハウス）に同時に接続する必要があります。
• OLTPデータベースとOLAPデータベースは、ETLパイプラインによって接続されます。
• 場合によっては、オンラインアプリケーションは、アプリケーションサーバーとビッグデータスタックの両方と連携する必要があります。

従来のハイブリッドワークロードシナリオ

ストリームコンピューティングのシナリオを考えてみます。各アプリケーションは多くの場合、ログ分析や動作分析を行うため、ログをバックエンドサーバーに送信する必要があります。ストリームコンピューティングを利用している従来型企業の場合、通常、フロントエンドはOLTPデータベースになり、「delete」操作や「update」操作のログは、変更データキャプチャ（CDC）コンポーネントを介してダウンストリームに転送されます。従来型アーキテクチャのテクノロジースタックではこれらのログを効率的に処理できません。ダウンストリームのデータ処理では、複数の種類のデータリクエストに対応するためにさまざまなデータストレージが必要になります。

• CDCログを受信し、ダウンストリームデータベースにリアルタイムの「delete」と「update」を実装する場合は、MySQLを試すことができます。ただし、大量のデータを保存する必要が生じた場合、自由にスケールアウトできない場合があります。
• 水平方向の拡張性とデータ操作が必要な場合は、NoSQLデータベースの導入を検討してもいいかもしれません。しかし、通常、NoSQLデータベースでは複雑なデータ分析を行うことができません。
• Elasticsearchも選択肢として考えられます。しかし、Elasticsearchは本質的にデータベースではなく検索エンジンです。そのため、アグリゲーション目的に使用した場合、その柔軟性が犠牲になる可能があります。
• 従来型の超並列処理（MPP）データベースは、分析ワークロードには適していますが、もともとバッチ処理とデータウェアハウジング向けに設計されたものです。したがって、リアルタイムでのデータ更新には適していません。

従来のストリームコンピューティングシナリオ

要約すると、データ転送プロセスもダウンストリームデータベースも、リアルタイムデータ分析を行うための十分な機能を持ち合わせていないということです。この問題に対処するため、データアーキテクトは複数のテクノロジーを組み合わせることによって、各アプリケーションの要求を満たします。その結果、データアーキテクチャの複雑性が増します。データは複数のスタック間でサイロ化され、データの鮮度と整合性を確保するのが難しくなります。

企業は理想的なソリューションを求めている

インターネットの波が到来する前、大部分の企業は前世代のデジタルトランスフォーメーションをすでに経験しており、そこではデータベースが重要な役割を果たしていました。スタンドアロンデータベースは、さまざまなデータアクセスリクエストを処理することができ、ほとんどのビジネスニーズを満たすことができました。この頃は複雑なコンポーネントは必要ありませんでした。

そしてビッグデータ時代が到来しました。従来型企業はデジタルトランスフォーメーションを実現するため、これまでと同様に、すべてに対応できる万能なアプローチを求めています。Hadoopのような既存のビッグデータテクノロジーは、きわめて成熟したソリューションですが、従来型データベースと同様のユーザーエクスペリエンスを提供することはできません。このため、多くの企業が理想的な代替手段を模索しています。

現行のビッグデータテクノロジーの理想的な代替手段には、以下の特徴が求められます。

• 拡大するデータセットに合わせてスケールアウトできること
• 多様なアプリケーションのさまざまなワークロードを処理できること
• 従来型データベースのようにシンプルかつセキュアであること、および利用とメンテナンスが容易であること

TiDBのHTAPアーキテクチャの進化

HTAP機能は、TiDBのバージョン4.0で導入されました。これは、行ベースのストレージエンジンであるTiKVとカラム型ストレージエンジンであるTiFlashで構成されたハイブリッドストレージアーキテクチャでした。この2つのストレージエンジンは、共有SQLレイヤーとしてTiDBを使用し、同一の権限管理を実装していました。オプティマイザーは実行プランのコストに基づき、いずれかのエンジンを選択していました。

このアーキテクチャは高性能のストレージシステムを備えていましたが、大規模で複雑なクエリを処理するコンピューティング能力が不足していました。TiDB 4.0は頭の小さなクマのようなもので、その頭（コンピューティング能力）に比べて体（卓越したストレージパフォーマンス）が大きくなりすぎていました。

頭の小さなクマ

TiDB 5.0で状況は変わりました。新しいMPPアーキテクチャにより、TiFlashは単なるTiDBストレージノードではなく、完全に機能する分析エンジンに生まれ変わりました。これまで通り、TiDBは単一のSQLエントランスとして機能し、オプティマイザーはコストに基づいて最も効率的なクエリ実行プランを選択しますが、もう1つのオプション、すなわちMPPエンジンが加わりました。

TiDB 5.0の詳細

下図は、TiDB 5.0のアーキテクチャを示しています。ストレージクラスタはTiKVおよびTiFlashで構成されており、これがTiDBクラスタ全体のストレージエンジンになります。

TiDB 5.0のHTAPアーキテクチャ

それぞれのストレージは通常、異なる種類のワークロードに対応しています。

• OLTPワークロードの場合は、通常、クエリは数行を一度に読み取りまたは更新します。この種のクエリには、行ベースのストレージが最も適しています。
• レポーティングやビジネスインテリジェンス（BI）などのOLAPワークロードの場合、通常、クエリはワイドテーブル内のいくつかのカラムを選択し、そのデータのフィルタリングやアグリゲーションを行います。その際に他のカラムに干渉することはありません。この種のクエリには、カラム型ストレージが最も適しています。
• 加えて、カラム型ストレージエンジンは、ベクトルエンジンと連携することによって、BIクエリや分析クエリを高速化することができます。

TiDBのMPPモードでは、TiFlashがTiDBのコンピューティング機能を補完します。OLAPワークロードを処理するときは、TiDBはマスターノードに戻ります。ユーザーがTiDBサーバーにリクエストを送信すると、すべてのTiDBサーバーがテーブル結合を実行し、その結果をオプティマイザーに送信し、その決定に委ねます。オプティマイザーは、考えられる実行プラン（行ベース、列ベース、インデックス、単一サーバーエンジン、MPPエンジン）をすべて査定し、その中から最適なものを選択します。

TiDBのMPPモード

以下の図は、TiDBのMPPモードにおいて、分析エンジンが実行プランをどのように分析および処理するのかを示しています。それぞれの点線ボックスは、ノードの物理的な境界線を表しています。

MPPモードでのクエリ実行プラン

例えば右上隅のクエリでは、2つのテーブルを結合し、指定された順序で結果をソートする必要があります。このクエリは、2つのノードがスキャン操作を行う実行プランに分割されます。一方のノードは左側のテーブルをスキャンし、もう一方のノードは右側のテーブルをスキャンします。この2つのノードは、結合条件に従って「結合」作業を単独で行い、結合に関連するデータは各ノードにまとめて割り当てられます。同一のシャードに属するデータは1つのノード（または1つのノードグループ）に移動し、各ノードはローカル計算を実行します。最後に、各ノードからの結果はマージされ、クライアントに返されます。この点がMPPモードのメリットです。つまり、複数のノードを使って、JOIN（結合）のような大規模なクエリを並行して実行することができます。

TiDB MPP、Greenplum、Sparkの比較

以下のベンチマークが示すとおり、TiDB 5.0のパフォーマンスは、MPPによって大幅に上昇します。

TiDB、Greenplum、Sparkの比較

3つのノード上にあるTPC-H 100 GB環境で、1億以上のレコードを持つテーブルに対するさまざまなクエリの所要時間を計測しました。TiDB 5.0、Greenplum 6.15.0、Apache Spark 3.1.1のテストでは、同一のハードウェアリソースを使用しました。

上のグラフから、TiDBのパフォーマンスは他のものよりも高いことがわかります。平均して、TiDBのパフォーマンスはGreenplumやApache Sparkよりも2～3倍速くなっています。一部のクエリでは、TiDBは8倍のパフォーマンスを発揮しています。

TiDB 5.0：単一のスタックであらゆるシナリオに対応

TiDB 4.0とは異なり、TiDB 5.0は、従来型データベースと同じようにOLTPサービスやOLAPサービスを単一インターフェイスで利用できる完全なHTAPデータベースプラットフォームです。

TiDB 5.0で必要となる作業は、SQLの記述だけです。細かいことに注意を払う必要はありません。読み取りリクエストであれ、書き込みリクエストであれ、OLTPワークロードであれ、OLAPワークロードであれ、可能な限り最も効率的な方法で処理がなされ、結果が返ってきます。

ハイブリッドワークロードシナリオ

ハイブリッドワークロードシナリオでは、TiDBはOLTPリクエストとOLAPリクエストの両方を効率的に処理することができます。ユーザーには、1か所にすべてのデータが送られているように見えます。アプリケーションサーバーは、すべての種類のリクエストを受け取り、それをTiDBサーバーに送信します。その後、TiDBサーバーはそれらのリクエストを各ストレージエンジンに割り当てます。このアーキテクチャは、以下のとおりシンプルかつ洗練されたものになっています。

ストリームコンピューティングシナリオ

ストリームコンピューティングも喫緊のニーズとなっています。ビッグデータツールは、ログストリームのリアルタイム分析のための成熟したソリューションです。しかし、データ削除、データ更新、テーブル結合を行う必要がある場合は、現在のデータベース市場で選択できる理想的なソリューションはTiDBです。

その最初の理由は、TiDBは真の分散型HTAPデータベースであるということです。TiDBは、Kafka等のデータパイプラインを使用することによって、複製先としてのOracleに接続させたり、複製としてのMySQLに接続させたりすることができます。また、アプリケーションでデータを処理する必要が生じた場合は、従来型データベースアーキテクチャに戻すことができます。

次に、TiDBはOLTPデータベースでもあり、作成、読み取り、更新、削除（CRUD）にリアルタイムで対応できます。TiDBはハイブリッドストレージエンジンを備えているため、ポイントクエリと集計クエリの両方を処理できます。

データハブシナリオ

ファイナンシング、ERP、販売、ウェアハウス、クリックストリーム、ユーザープロファイルなど複数のデータソースがフォアグラウンドにある場合、各データソースのデータはそれぞれ固有のデータベースに保存される可能性があります。この場合、ホットデータについて、信頼できる唯一のリアルタイムデータソースを得るには、CDCやKafkaを介してデータをTiDBに統合し、データハブレイヤーを構築します。

データハブは、アプリケーションとデータウェアハウスの間にあるレイヤーです。データウェアハウスが過去のデータをすべて保存するのに対し、データハブは一時的にデータを保存します。データハブでは通常、リアルタイムクエリのためのホットデータが保存したり、同時実行性の高いリクエストを処理したりします。一方、オフラインデータウェアハウスやデータレイクは多くの場合、レポートクエリやBIクエリ向けの鮮度が高くないデータを提供します。

TiDBは、データプラットフォームに統合された後、すべてのデータのセントラルハブとして機能します。既存のオフラインデータウェアハウスやHadoopプラットフォームがあっても、リアルタイムデータを保存および管理するために、アプリケーションレイヤー、Hadoopレイヤー、データウェアハウスの間にTiDBを配置することができます。ビジネスがさらに複雑化し、より厳格なセキュリティ基準が適用される場合でも、TiDBはデータ関係とライフサイクル管理のための統一されたセントラルデータハブとなり、企業の長期的成長をサポートするための基盤となります。

ワンストップのデータサービスエコシステムを目指して

MPPエンジンとエンタープライズグレードの新機能を備えたことで、TiDB 5.0は単なる分散型データベースではなく、ワンストップのデータサービスエコシステムになりました。「単一スタックですべてを処理」することができます。

ところで、このエコシステムは、PingCAPのみによって構築されているわけではありません。TiDBコミュニティ全体によって構築および維持されています。このマイルストーンリリースでは、538のコントリビューターがGitHubで12,513件のプルリクエストを送信し、開発に参加しました。例えばZhihuは、複数のビッグデータコンポーネントとツールを提供し、大規模アプリケーションの価値を高めてくれました。

当社は、オープンかつ透明性のあるコラボレーションを通じ、TiDBから無限の可能性を引き出せると信じています。コントリビューターのおかげで、究極のワンストップデータサービスエコシステムに向かってまた一歩前進することができました。