実世界のHTAP：TiDBとSingleStore、そのアーキテクチャを考察

※このブログは2022年07月26日に公開された英語ブログ「Real-World HTAP: A Look at TiDB and SingleStore and Their Architectures」の拙訳です。

著者: Ghimsim Chua (TiDB Cloudプロダクトマネージャ)
編集者: Fendy Feng、Rick Golba

HTAPの台頭

近年、HTAP (Hybrid Transactional and Analytical Processing) 対応のデータベースが増えてきています。Oracle、Microsoft、SAP HANA、MariaDBなどの有力プレイヤーは、従来の行ストア型データベースに列ストアを追加することで、HTAP機能を提供するようになりました。GoogleのAlloyDBとSnowflakeが最近発表したUnistoreも、SingleStore、TiDB、Hyper、Procella、Wildfire、Janusなど、増え続けるHTAP対応データベースの仲間入りを果たしました。

これはなぜでしょうか。理由のひとつは、古今東西の多くの産業でリアルタイムデータが爆発的に増えていることです。産業の近代化に伴い、ますます大量のデータが収集されるようになりました。データサイズは飛躍的に大きくなり、かつてないほどのスピードで成長しています。多くのサービスでは、ストリーミングデータを使用し、1秒間に数千から数百万のイベントやトランザクションを取り込む必要があります。その上、ユーザーはビジネス上の重要な決定を下すために、リアルタイムで入ってくるデータを監視し、分析することを望んでいます。数時間から数日かかるレポートや分析クエリは、競争力の高い企業にとってもはや許容できるものではありません。さらに、複数のコンポーネントやプロセスを持つ複雑なバックエンドアーキテクチャは、障害や故障が発生しやすくなります。複雑なアーキテクチャを簡潔化し、総所有コストを削減する必要性が高まっているのです。

HTAPの活躍

HTAPがこれらの問題を解決する好例が、フィンテック業界に見られます。

オンライン、モバイル、カード不要の決済アプリは、ここ数年で爆発的に普及しました。消費者は、複数のデバイスで素早く簡単に商品を注文し、決済できることを期待しています。一方、決済を受け入れる販売事業者は、購入傾向の分析に必要なトランザクションへの即時アクセスを必要とします。顧客数の増加に伴い、フィンテック企業は毎秒数千、数百万の新規取引を処理しながらテラバイト単位のデータを処理する、より高速なバックエンドシステムを求めています。さらに、これらのシステムは、熾烈な市場で競争するために、不正行為の検出と監視のための分析クエリをリアルタイムで処理しなければなりません。これは、あらゆるデータベースのバックエンドに極度の負担をかけることになります。同様の情報処理の爆発は、広告、IoT、eコマース、物流など、さまざまな業界でも見られます。

HTAPデータベースは、フィンテック開発者に、生成される大量のデータを処理するための性能と拡張性を提供し、求められるスピードでデータを処理すると同時に、アーキテクチャを大幅に簡素化します。開発者は、これまで複数の専門的なデータベースやプロセスを含んでいた複雑なインフラ配備を、単一のHTAPデータベースに統合できるようになりました。さらに重要なことは、OLTPからOLAPクエリまで、さまざまなワークロードを、今日のビジネスが求める性能、規模、並行性、かつ合理的なコストで実行可能にしたことです。

HTAPデータベースの簡略化されたアーキテクチャ

SingleStoreの沿革

HTAPデータベースの台頭に伴い、多様なHTAPの実装が普及しています。独自の「シングルストレージ」アーキテクチャを持つSingleStoreは、TiDBと比較する上で興味深いケーススタディと言えます。この分析により、それぞれの設計の長所と短所をより理解することができるのです。

SingleStoreは、2013年4月23日にMemSQLとして一般公開されました。MemSQLの初期バージョンは、トランザクションクエリのみをサポートし、すべてのデータがコンピュータのメインメモリ内に収まるようなケースに最適化されていました。また、MemSQLは、インメモリ行ストアと並行して動作する、ディスク上で列ベースのストレージ形式の一般的なサポートを追加した最も初期のデータベースの1つでした。さらに最近では、インメモリ専用のワークロードから脱却するためにアーキテクチャを大きく変更し、SingleStoreと呼ぶ新しいデータ保存方法を導入し、会社の新社名にもなっています。この新社名は、トランザクションと分析の両方のユースケースをサポートできる普遍的なストレージフォーマットの実現という目標を明確に表していました。

TiDBとSingleStoreとの比較

TiDBとSingleStoreは、MySQL互換の分散型HTAP対応データベースエンジンで、トランザクションと分析ワークロードの両方を高いパフォーマンスで実行できるように設計された汎用性の高いエンジンです。TiDBは完全にオープンソースのデータベースシステムで、その3つのカーネルコンポーネントであるTiDB、TiKV、TiFlashはすべてオープンソースプロジェクトです。さらに、TiKVはCNCF graduate projectでもあります。これに対して、SingleStoreはオープンソースではなく、オープンソース化する計画もないとのことです。

TiDBもSingleStoreも、コンピュートノードとストレージノードが分かれています。TiDBでは、返すべき結果を受け取って処理するノードがTiDBノードで、TiKVとTiFlashはデータを保存するノードです。同様にSingleStoreでは、コンピュートノードであるアグリゲーターノードがあり、リーフノードがストレージノードとなります。

アーキテクチャ設計におけるTiDBとSingleStoreの比較

データストア・アーキテクチャ

TiDBとSingleStoreの主な違いは、データストアのアーキテクチャにあります。

TiDBデータストア

TiDBは、2つの異なるデータストアにデータを格納することで、HTAP機能を実装しています。TiDBは2種類の異なるストレージノードをもち、TiKVノードは行ベースのストア、TiFlashノードは列ベースのストアとなっています。TiKVノードのデータは、Amazon Elastic Block Store (EBS) のようなブロックストレージに永続的に保存されます。スケーラビリティを確保するため、TiDBには通常複数のTiKVノードが含まれ、水平方向にスケールアウトしてデータストレージの容量を増やすことができます。

各書き込みトランザクションが確定したとみなされるには、Raftコンセンサスアルゴリズムを使用してデータを3回複製し、3つの異なるAZ (Availability Zone) のTiKVノードに保存する必要があり、これにより耐障害性と⾼い可用性が保証されます。TiFlashでは、TiFlash専用に設計された非同期のRaftレプリケーションプロセスにより、カラムストアのデータとTiKVノードのデータの整合性が保たれています。3つ目のタイプのノードであるTiDBノードは、実行コーディネータの役割を果たし、TiKVノードとTiFlashノードからデータを返すクエリと処理を分担します。

TiDBのアーキテクチャ

SingleStoreデータストア^[1]

また、SingleStoreは水平方向のスケーラビリティを確保するために、複数の分散アグリゲータとリーフノードを配置しています。データは異なるリーフノードに2回複製され、高可用性を実現しています。ただし、各リーフノードでは、インメモリの行ストアと列ストア、ディスクに保存されるログファイルやデータファイルなど、複数の異なる構造でデータを保存します。クラウド環境で実行する場合は、AWS S3のようなブロブストアに保存することも可能です。

高速な読み取りと書き込みのために、データはメモリ内の行ストアに読み取られ、書き込まれます。書き込み操作では、関係する行はローカルディスクに保存されるログにも書き込まれ、耐久性を高めるために他のリーフノードにも複製されます。メモリ内行ストアに十分な行が蓄積されると、バックグラウンドフラッシャープロセスが行ストアから行を削除し、それらの行をメモリ内列ストアセグメントに変換します。列ストアセグメント内のデータを格納するためにデータファイルが作成され、コミットされた後に非同期でブロブストレージ (クラウドで実行されている場合) にアップロードされます。ホットデータファイルはクエリで使用するためにローカルディスク上のキャッシュに保持され、コールドデータファイルはブロブストアにアップロードされた時点でローカルディスクから削除されます。ノードは、インメモリ構造やログファイルのいずれにもないデータセグメントを見つけると、ブロブストアからデータを取得します。

トランザクションはログの末尾にコミットされ、ブロブストレージなしで実行する場合は他のノードにレプリケートされます。行ストアデータのスナップショットはパーティションで取得され、ローカルディスクまたはブロブストアに直接書き込まれます。クラスタに計算能力を追加するために、新しいレプリカデータベースはブロブストレージから必要なスナップショットとログを取得し、マスターデータベースからログの末尾をレプリケートします。列ストアデータファイルは、必要に応じてブロブストアから取り出され、データファイルキャッシュに保存されます。

各ストレージアーキテクチャの意味するもの

外付けストレージ

TiDBはデータを行ストア (TiKV) と列ストア (TiFlash) の両方に保存することから、高可用性や耐久性のために必要以上にデータのコピーを保存し、ストレージ容量を無駄にしているという批判があります。さらに、データはTiKVからTiFlashに非同期でレプリケーションされるため、2つのストア間でレプリケーションラグが発生します。

SingleStoreは行ストアと列ストアの両方に同じデータを保持しないため、データストレージをより効率的に使用することができます。しかし、トランザクショナルワークロードで効率的なポイントアクセスを実現するために、SingleStoreは追加して複数のセカンダリインデックスを使用することが必要となります。インデックスを追加するたびに大きなストレージスペースを消費する可能性があり、複数のインデックスを持つことでSingleStoreの持つデータストレージの効率が低下してしまいます。

Raftレプリケーション

TiDBのTiKVノード間の同期レプリケーションには、Raftコンセンサスアルゴリズムが組み込まれています。さらに、データのコピーを常時3つ保持し、高い可用性と耐久性を維持します。SingleStoreの場合、複雑なデータ処理プロセスでは、プライマリとセカンダリのレプリカ間の整合性を保つためにRaftやPaxosのアルゴリズムは使用されません。データの一貫性を維持するRaftがなければ、ネットワーク障害によってそのデータパーティションにデータの不整合が発生し、スプリットブレインデータベースとなる可能性があります。

さらに、SingleStoreでは、ローカルディスクやメモリ上に永続的な状態を確保するために、ローカルで高性能なレプリケーションとリカバリのプロトコルが必要です。また、ホストの追加や削除の際には、耐久性と可用性を保証するために、まだブロブストレージにないローカルデータを慎重に移動させる必要があり、伸縮性に欠けます。1つのパーティションのコピーを持つすべてのノードが失われるような、複数の障害が同時に発生した場合、コミットされたデータが失われる可能性があります。

結果として、TiDBはデータの不整合が許されないミッションクリティカルなアプリケーションに適用しやすいと言えます。

ホットデータとコールドデータの分離

TiDBでは、ホットデータ、コールドデータの分離はないものの、すべてのデータがすぐに利用可能で、OLTPやOLAPクエリに最適な形で提供されます。デメリットとしては、データセットが大きい場合において、たとえ小さなデータセットのみが頻繁に使用され、残りのデータが全く触られないとしても、データセット全体を維持するために、より高価な計算およびストレージリソースを使用する必要があるということが挙げられます。

一方、SingleStoreのアーキテクチャでは、ブロックストレージよりも圧倒的に安価な長期間用ブロブストレージにデータをアップロードしています。時間が経過しても、ホットデータのみがリーフノードに保持され、コールドデータをブロブストレージに保持するために計算資源を浪費することはありません。その結果、ローカルディスクやブロックストレージよりも格段に大きなデータセットを保存することができ、コストも大幅に削減できます。さらに、新しいリーフノードでは、スナップショットの読み込みとログの再生を個別に行うだけでよいため、迅速なプロビジョニングと拡張が可能です。

この記事を書いている時点で、TiDBは近い将来、コールドデータをブロブストレージに保存する機能の搭載も予定しています。

さまざまなパーティション方式

SingleStoreがハッシュパーティショニングを採用しているのに対し、TiDBはレンジパーティショニングを採用しています。レンジパーティショニングでは、クラスタ化されたインデックスを使用することで、連続した行への高速なデータアクセスが可能になります。しかし、ハッシュパーティショニングでは、より高速なデータアクセスのために追加のインデックスを構築する必要があります。また、連続したデータ行を取得する必要があるクエリでは、インデックスとデータの追加スキャンが必要になる場合があります。

スケーリング

TiDBはTiKVとTiFlashのノード以外にはデータを保存しないため、ストレージ容量を拡張するにはTiKVとTiFlashのノード数を増やす必要があります。これらのノードにかかるコストはすぐに膨らんでしまいます。また、新しいノードを追加する際にパーティションのバランスを調整する必要があるため、高価な作業となる可能性があります。

SingleStoreの場合、クラウド上でブロブストレージを使って実行するとき、データストレージのサイズはアグリゲータノードやリーフノードの数によって制限されません。SingleStoreのクラスタは、どのようなサイズであっても、より大きなクラスタが書き込んだブロブストレージのデータを照会することができます。新しいリーフノードの追加も、ブロブストレージからスナップショットをロードし、ログを再生して最新の状態にするだけでよいので、短時間で完了します。

比較表

	TiDB	SingleStore
SQL compatibility	MySQL	MySQL
Open source	Yes	No
Data architecture	Row/column	Row/column
Storage format	Row/column	Column
Durable storage	Local, EBS	Local, EBS, blob
Hot / cold data	No	Yes
High availability	Yes / raft, 3 copies in 3 AZs	Yes, 2 copies in different AZs
Partitioning method	Range	Hash
Mission critical applications	Yes	No

まとめ

明らかなアーキテクチャの違いの他に、2つの異なる設計思想から何が推測できるでしょうか。SingleStoreのストレージアーキテクチャは、データの耐久性よりもパフォーマンスを優先しているようです。一方、TiDBのストレージアーキテクチャは、パフォーマンスよりもデータの耐久性を優先しています。データの耐久性とは、データの損失や破損のおそれを示す指標です。TiDBでは、コミットされた瞬間にすべてのトランザクションが長期耐久ストレージに記録され、リージョン全体がダウンした場合でもすべてのトランザクションが復元可能です。さらに、Raftコンセンサスプロトコルを用いて3つのデータコピーを複製することで、ネットワークパーティションに障害が発生した場合でもデータの一貫性を確保することができます。これに対しSingleStoreは、RaftやPaxosのようなクォーラムベースのアルゴリズムを用いてストア間のデータ複製を行っていないため、スプリットブレインの問題が発生する可能性があります。

しかしながら、この根本的な違いは、ある設計が他の設計より優れていることを意味するものではありません。TiDBのデータ耐久性は、銀行取引、オンライン決済、eコマース取引、物流、医療記録など、データ損失を許容できない多くのミッションクリティカルな用途やSystem of Recordで必要とされます。SingleStoreの高いデータ取り込み性能は、一部のデータの損失がシステム全体の機能に大きな影響を与えないようなケースで活躍します。数十億のイベントのうち、数百のIoTデータイベント、広告クリック、メディアイベントを失ったとしても、ダッシュボードの運用分析レポートに重大な影響を与えることはないでしょう。

TiDBとSingleStoreは、従来のOLTPデータベースやOLAPデータベースでできること以外にも、それぞれのアプリケーションシナリオで独自の優位性を持っており、開発者に素晴らしい選択肢を提供します。

TiDBを体験するには、コミュニティエディションまたはTiDB Cloud無料トライアルをお試しください。日本語ドキュメントのTiDBクイックスタートガイド、またはTiDB Cloudワークショップガイドのご利用をお勧めします。ご不明な点などございましたら、お問い合わせフォームよりご連絡ください。また、GitHubにて問題を報告することもできます。

[1] 参考：Cloud-Native Transactions and Analytics in SingleStoreDB

---

HTAPについてもっと読む

• HTAPの魅力：TiDBとAlloyDBの比較・分析
• The Long Expedition toward Making a Real-Time HTAP Database