導入

TiDBは、PingCAPが独自に設計・開発したオープンソースの分散リレーショナルデータベースです。水平スケーリング、金融グレードの高可用性、リアルタイムHTAP、クラウドネイティブ分散データベース機能、MySQL 5.7プロトコルおよびMySQLエコシステムとの互換性を特徴とする、ハイブリッドトランザクションおよび分析処理（HTAP）を同時にサポートする統合型分散データベース製品です。OLTP（オンライントランザクション処理）、OLAP（オンライン分析処理）、HTAPをワンストップで実現するソリューションをユーザーに提供することを目指しています。TiDBは、高可用性、強力な一貫性、大容量データを必要とする様々なアプリケーションシナリオに適しています。

特徴

• ワンクリックの水平スケールアップまたはスケールダウン: TiDB のストレージとコンピューティングの分離アーキテクチャにより、コンピューティングとストレージを必要に応じてオンラインでスケールアップまたはスケールダウンでき、スケールアップまたはスケールダウンのプロセスはアプリケーション保守担当者に対して透過的です。
• 金融グレードの高可用性：データは複数のレプリカを使用して保存されます。これらのレプリカは、Multi-Raftプロトコルを介してトランザクションログを同期します。トランザクションは、レプリカの過半数への書き込みが成功した場合にのみコミットされるため、強力なデータ整合性が確保され、少数のレプリカの障害によってデータの可用性が損なわれることはありません。レプリカの地理的な配置と数に関する戦略は、さまざまな災害復旧レベルに合わせて必要に応じて設定できます。
• リアルタイムHTAP：TiKV（行ストレージエンジン）とTiFlash（列ストレージエンジン）という2つのストレージエンジンを提供します。TiFlashは、Multi-Raft Learnerプロトコルを介してTiKVからデータをリアルタイムに複製し、TiKVとTiFlash間の強力なデータ整合性を確保します。TiKVとTiFlashは必要に応じて異なるマシンにデプロイできるため、HTAPにおけるリソース分離の問題を解決します。
• クラウドネイティブ分散データベース: クラウド専用に設計された分散データベースで、TiDB Operator を通じてパブリック クラウド、プライベート クラウド、ハイブリッド クラウドに導入および自動化できます。
• MySQL 5.7プロトコルおよびMySQLエコシステムとの互換性：TiDBはMySQL 5.7プロトコル、一般的に使用されるMySQL関数、そしてMySQLエコシステムと互換性があるため、アプリケーションをMySQLからTiDBに移行する際に、コードの変更をほとんど、あるいは全く必要としません。豊富なデータ移行ツールセットが提供されており、アプリケーションによるデータ移行を容易に完了できます。

従来のスタンドアロン データベースと比較して、TiDB には次の利点があります。

• 優れたスケーラビリティを備えた純粋に分散されたアーキテクチャを特徴としており、弾力的なスケールアップとスケールダウンをサポートします。
• これは SQL をサポートし、MySQL のネットワーク プロトコルを公開し、ほとんどの MySQL 構文と互換性があるため、ほとんどのシナリオで MySQL の直接的な代替品になります。
• 高可用性はデフォルトでサポートされています。レプリカに障害が発生した場合でも、データベース自体が自動的にデータの修復とフェイルオーバーを実行するため、ビジネスへの影響は意識する必要がありません。
• ACID トランザクションをサポートしているため、銀行振込など、強力な一貫性が求められるシナリオに適しています。
• 豊富なツールチェーン エコシステムを備えており、データの移行、同期、バックアップなどのさまざまなシナリオをカバーします。

シーン

• 高いデータ一貫性、信頼性、可用性、スケーラビリティ、および災害復旧を必要とする金融業界のシナリオ。

周知のとおり、金融業界ではデータの一貫性と信頼性、システムの高可用性、拡張性、そして災害復旧に対する高い要件が求められています。従来のソリューションでは、同じ都市にある2つのデータセンターでサービスを提供し、別の場所に別のデータセンターを開設してデータの災害復旧機能を提供するものの、サービスは提供していませんでした。このソリューションには、リソース使用率の低さ、メンテナンスコストの高さ、そしてRTO（目標復旧時間）とRPO（目標復旧時点）が企業の期待に真に応えられないという欠点がありました。TiDBは、マルチレプリカ+マルチRaftプロトコルを用いて、異なるデータセンター、ラック、マシンにデータを分散させます。一部のマシンに障害が発生した場合、システムは自動的に切り替えを行い、RTO <= 30秒、RPO = 0を実現します。

• ストレージ容量、スケーラビリティ、同時実行性に対する要件が高い、大量のデータと高同時実行性の OLTP シナリオ向け。

ビジネスの急速な発展に伴い、データは爆発的に増加しています。従来の単一マシンデータベースでは、この爆発的な増加に伴う容量要件を満たすことができません。実現可能な解決策としては、データベースシャーディングやテーブルパーティショニング機能を備えたミドルウェア製品の使用、NewSQLデータベースへの置き換え、ハイエンドストレージデバイスの使用などが挙げられます。これらの中で、TiDBなどのNewSQLデータベースは、最も優れたコストパフォーマンスを提供します。TiDBは、コンピューティングとストレージを分離したアーキテクチャを採用しており、コンピューティングとストレージを個別にスケールアップおよびスケールダウンできます。最大512のコンピューティングノードをサポートし、各ノードは最大1000の同時接続をサポートし、最大クラスター容量はPBです。

• リアルタイムHTAPシナリオ

5G、IoT、AIの急速な発展に伴い、企業が生成するデータはますます膨大になり、数百テラバイト（TB）、さらにはペタバイト（PB）に達する可能性があります。従来のソリューションでは、オンライントランザクションの処理にはOLTPデータベースを使用し、分析のためにデータをOL​​APデータベースに同期させるETLツールが用いられてきました。しかし、このアプローチはストレージコストが高く、リアルタイム性が低いという問題がありました。TiDBバージョン4.0では、列指向ストレージエンジンTiFlashと行指向ストレージエンジンTiKVを組み合わせることで、真のHTAPデータベースを構築できます。ストレージコストをわずかに増加させるだけで、同一システム内でオンライントランザクション処理とリアルタイムデータ分析を実現し、企業のコストを大幅に削減します。

• データ集約と二次処理のシナリオ

現在、多くの企業の業務データは、統一された集約が行われていないため、さまざまなシステムに散在しています。ビジネスが成長するにつれて、企業の意思決定者はタイムリーな意思決定を行うために、ビジネス全体の状況を把握する必要があります。そのため、さまざまなシステムに散在するデータを単一のシステムに集約し、二次処理を行ってT+0またはT+1レポートを生成する必要があります。従来の一般的なソリューションはETL + Hadoopを使用することですが、Hadoopシステムは複雑すぎて、運用、保守、およびストレージのコストが高すぎてユーザーのニーズを満たせません。Hadoopと比較して、TiDBははるかにシンプルです。企業はETLツールまたはTiDBの同期ツールを使用してデータをTiDBに同期し、SQLを使用してTiDBで直接レポートを生成できます。

建築

TiDB分散データベースのカーネル設計では、全体的なアーキテクチャを複数のモジュールに分割し、それらが相互に通信することで完全なTiDBシステムを形成します。対応するアーキテクチャ図は以下のとおりです。

• TiDBサーバー： SQL層はMySQLプロトコル接続エンドポイントを公開し、クライアント接続の受け入れ、SQLの解析と最適化、そして最終的には分散実行プランの生成を担います。TiDB層自体はステートレスです。実際には、複数のTiDBインスタンスを起動し、負荷分散コンポーネント（LVS、HAProxy、F5など）を介して外部から統一されたアクセスアドレスを提供できます。クライアント接続は複数のTiDBインスタンスに均等に分散され、負荷分散を実現します。TiDBサーバー自体はデータを保存せず、SQLを解析し、実際のデータ読み取り要求を基盤となるストレージノードTiKV（またはTiFlash）に転送するだけです。
• 配置ドライバ（PD）サーバー： TiDBクラスタ全体のメタデータ管理モジュールです。各TiKVノードのリアルタイムデータ分布とクラスタ全体のトポロジを保存し、TiDBダッシュボード管理インターフェースを提供し、分散トランザクションにトランザクションIDを割り当てます。PDはメタデータを保存するだけでなく、TiKVノードから報告されるリアルタイムデータ分布状況に基づいて、特定のTiKVノードにデータスケジューリングコマンドを発行し、クラスタ全体の「頭脳」として機能します。さらに、PD自体は少なくとも3つのノードで構成され、高可用性を実現します。奇数個のPDノードを導入することをお勧めします。
• TiKVサーバー：データストレージを担当します。外部から見ると、TiKVは分散型のトランザクション型キーバリューストレージエンジンとして機能します。データ保存の基本単位はリージョンです。各リージョンは、キーレンジ（StartKeyからEndKeyまでの左閉じ、右開きの区間）内のデータを保存し、各TiKVノードは複数のリージョンを管理します。TiKVのAPIは、キーバリューペアレベルでの分散トランザクションをネイティブサポートし、デフォルトでSI（スナップショット分離）を提供します。これは、TiDBのSQLレベルでの分散トランザクションサポートの中核です。SQLを解析した後、TiDBのSQLレイヤーはSQL実行プランをTiKV APIへの実際の呼び出しに変換します。したがって、すべてのデータはTiKVに保存されます。さらに、TiKV内のデータは複数のレプリカ（デフォルトでは3つのレプリカ）で自動的に維持されるため、高可用性と自動フェイルオーバーが自然にサポートされます。
• TiFlash: TiFlashは特殊なタイプのストレージノードです。通常のTiKVノードとは異なり、データはTiFlash内に列形式で保存され、その主な機能は分析シナリオの高速化です。

ストレージ

TiKVはデータを直接ディスクに書き込むのではなく、RocksDBに保存し、RocksDBが実際のデータの永続化を処理します。これは、単一マシンストレージエンジンの開発、特に高性能なエンジンの開発には、様々な綿密な最適化が必要となるため、非常に手間がかかるためです。Facebookがオープンソース化した優れた単一マシンKVストレージエンジンであるRocksDBは、TiKVの単一マシンエンジンに対する様々な要件を満たすことができます。簡単に言えば、RocksDBは単一マシン永続キーバリューマップと考えることができます。

TiKVはデータレプリケーションにRaftを使用します。すべてのデータ変更はRaftのログエントリとして記録されます。Raftのログレプリケーション機能により、データはレプリケーショングループ内のすべてのノードに安全かつ確実に同期されます。ただし、実際の書き込み操作では、Raftプロトコルに従って、データが過半数のノードに同期されている限り、正常に書き込みが完了したと安全に判断できます。

要約すると、TiKVは単一マシンのRocksDBを使用してデータをディスクに迅速に保存し、Raftを介して複数のマシンにデータを複製することで、単一マシンの障害を回避できます。データはRocksDBに直接書き込まれるのではなく、Raftインターフェースを介して書き込まれます。Raftを実装することで、TiKVは分散キーバリューストアになります。たとえ数台のマシンに障害が発生しても、ネイティブのRaftプロトコルによって自動的にレプリカが復元されるため、ビジネスオペレーションはシームレスに行えます。

取引

TiDB は分散トランザクションをサポートし、楽観的トランザクション モードと悲観的トランザクション モードの両方を提供します。TiDB バージョン 3.0.8 以降では、デフォルトで悲観的トランザクション モードに設定されます。TiDB では、トランザクションを明示的に使用すること (`[BEGIN|START TRANSACTION]/COMMIT` ステートメントで定義) も暗黙的に使用することも (`SET autocommit = 1`) できます。TiDB では、ステートメント実行失敗後のアトミック ロールバックがサポートされます。ステートメントでエラーが発生した場合、変更は有効になりません。トランザクションは開いたままになり、`COMMIT` または `ROLLBACK` ステートメントが発行される前にさらに変更を加えることができます。基盤となるストレージ エンジンの制限により、TiDB では 1 行が 6 MB を超えないようにする必要があります。1 行のサイズは、行のすべての列をその型に基づいてバイト数に変換し、その結果を合計することで見積もることができます。

TiDBは楽観的トランザクションと悲観的トランザクションの両方をサポートしており、楽観的トランザクションは悲観的トランザクションの基礎となります。楽観的トランザクションは変更をプライベートメモリにキャッシュするため、TiDBは単一トランザクションのサイズを制限します。

TiDBでは、1つのトランザクションの合計サイズはデフォルトで100MBに制限されています。このデフォルト値は、設定ファイルの「txn-total-size-limit」設定オプションを使用して変更でき、最大10GBまでサポートされます。1つのトランザクションの実際のサイズ制限は、サーバー上で利用可能なメモリの残量にも依存します。トランザクション実行時、TiDBプロセスのメモリ消費量はトランザクションサイズに応じて増加し、コミットされたトランザクションのサイズの6倍以上に達する可能性があります。

バージョン4.0より前のTiDBでは、単一トランザクション内のキーと値のペアの総数が300,000個以下に制限されていました。バージョン4.0以降、この制限は解除されました。

互換性

TiDBは、MySQL 5.7プロトコル、MySQL 5.7で一般的に使用される機能、および構文と高い互換性があります。MySQL 5.7エコシステムのシステムツール（PHPMyAdmin、Navicat、MySQL Workbench、mysqldump、Mydumper/Myloader）、クライアントなどはすべてTiDBと互換性があります。ただし、TiDBはまだ一部のMySQL機能をサポートしていません。これは、以下の理由が考えられます。

• XML 関数の代わりに JSON を使用するなど、より良い解決策があります。
• 現在、ストアド プロシージャや関数などの機能に対する需要はそれほど高くありません。
• 一部の機能は分散システムでは実装が困難です。

さらに、TiDB は MySQL レプリケーション プロトコルをサポートしていませんが、MySQL でデータを複製するための専用ツールを提供しています。

• MySQL からのコピー: TiDB データ移行 (DM) は、MySQL/MariaDB から TiDB にデータを移行するためのツールであり、増分データレプリケーションに使用できます。
• MySQL へのレプリケーション: TiCDC は、TiKV 変更ログを取得し、MySQL シンク経由で TiDB 増分データを MySQL に複製できる TiDB 増分データ同期ツールです。