- TiDBについて
- クイックスタート
- 発展させる
- 概要
- クイックスタート
- TiDB Cloud(開発者層) で TiDB クラスターを構築する
- TiDB の CRUD SQL
- TiDB でシンプルな CRUD アプリを構築する
- 応用例
- TiDB に接続する
- データベース スキーマの設計
- 書き込みデータ
- データの読み取り
- 取引
- 最適化
- トラブルシューティング
- 参照
- 書店のサンプル アプリケーション
- ガイドライン
- アーカイブされたドキュメント
- クラウドネイティブ開発環境
- サードパーティのサポート
- デプロイ
- 移行する
- 管理
- 監視と警告
- トラブルシューティング
- TiDB トラブルシューティング マップ
- 遅いクエリを特定する
- 遅いクエリを分析する
- SQL 診断
- Top SQLを使用して高価なクエリを特定する
- ログを使用して高価なクエリを特定する
- ステートメント要約表
- ホットスポットの問題のトラブルシューティング
- 増加した読み取りおよび書き込み遅延のトラブルシューティング
- クラスターのオンサイト情報の保存と復元
- クラスタ セットアップのトラブルシューティング
- 高いディスク I/O 使用率のトラブルシューティング
- ロック競合のトラブルシューティング
- TiFlash のトラブルシューティング
- オプティミスティック トランザクションでの書き込み競合のトラブルシューティング
- データとインデックス間の不一致のトラブルシューティング
- 性能チューニング
- チューニングガイド
- Configuration / コンフィグレーションのチューニング
- システムのチューニング
- ソフトウェアのチューニング
- Configuration / コンフィグレーション
- コプロセッサ キャッシュ
- SQL チューニング
- チュートリアル
- TiDB ツール
- 概要
- ユースケース
- ダウンロード
- TiUP
- ドキュメンテーション マップ
- 概要
- 用語と概念
- TiUP コンポーネントの管理
- FAQ
- トラブルシューティングガイド
- コマンドリファレンス
- 概要
- TiUP コマンド
- TiUP クラスタ コマンド
- 概要
- tiup cluster audit
- tiup cluster check
- tiup cluster clean
- tiup cluster deploy
- tiup cluster destroy
- tiup cluster disable
- tiup cluster display
- tiup cluster edit-config
- tiup cluster enable
- tiup cluster help
- tiup cluster import
- tiup cluster list
- tiup cluster patch
- tiup cluster prune
- tiup cluster reload
- tiup cluster rename
- tiup cluster replay
- tiup cluster restart
- tiup cluster scale-in
- tiup cluster scale-out
- tiup cluster start
- tiup cluster stop
- tiup cluster template
- tiup cluster upgrade
- TiUP DMコマンド
- TiDB クラスター トポロジ リファレンス
- DM クラスタ トポロジ リファレンス
- ミラー リファレンス ガイド
- TiUP コンポーネント
- PingCAPクリニック診断サービス
- TiDB Operator
- Dumpling
- TiDB Lightning
- TiDB データ移行
- バックアップと復元 (BR)
- Binlog
- TiCDC
- Dumpling
- 同期差分インスペクター
- ティスパーク
- 参照
- クラスタ アーキテクチャ
- 主な監視指標
- セキュリティ
- 権限
- SQL
- SQL 言語の構造と構文
- SQL ステートメント
ADD COLUMN
ADD INDEX
ADMIN
ADMIN CANCEL DDL
ADMIN CHECKSUM TABLE
ADMIN CHECK [TABLE|INDEX]
ADMIN SHOW DDL [JOBS|QUERIES]
ADMIN SHOW TELEMETRY
ALTER DATABASE
ALTER INDEX
ALTER INSTANCE
ALTER PLACEMENT POLICY
ALTER TABLE
ALTER TABLE COMPACT
ALTER USER
ANALYZE TABLE
BACKUP
BATCH
BEGIN
CHANGE COLUMN
COMMIT
CHANGE DRAINER
CHANGE PUMP
CREATE [GLOBAL|SESSION] BINDING
CREATE DATABASE
CREATE INDEX
CREATE PLACEMENT POLICY
CREATE ROLE
CREATE SEQUENCE
CREATE TABLE LIKE
CREATE TABLE
CREATE USER
CREATE VIEW
DEALLOCATE
DELETE
DESC
DESCRIBE
DO
DROP [GLOBAL|SESSION] BINDING
DROP COLUMN
DROP DATABASE
DROP INDEX
DROP PLACEMENT POLICY
DROP ROLE
DROP SEQUENCE
DROP STATS
DROP TABLE
DROP USER
DROP VIEW
EXECUTE
EXPLAIN ANALYZE
EXPLAIN
FLASHBACK TABLE
FLUSH PRIVILEGES
FLUSH STATUS
FLUSH TABLES
GRANT <privileges>
GRANT <role>
INSERT
KILL [TIDB]
LOAD DATA
LOAD STATS
MODIFY COLUMN
PREPARE
RECOVER TABLE
RENAME INDEX
RENAME TABLE
REPLACE
RESTORE
REVOKE <privileges>
REVOKE <role>
ROLLBACK
SELECT
SET DEFAULT ROLE
SET [NAMES|CHARACTER SET]
SET PASSWORD
SET ROLE
SET TRANSACTION
SET [GLOBAL|SESSION] <variable>
SHOW ANALYZE STATUS
SHOW [BACKUPS|RESTORES]
SHOW [GLOBAL|SESSION] BINDINGS
SHOW BUILTINS
SHOW CHARACTER SET
SHOW COLLATION
SHOW [FULL] COLUMNS FROM
SHOW CONFIG
SHOW CREATE PLACEMENT POLICY
SHOW CREATE SEQUENCE
SHOW CREATE TABLE
SHOW CREATE USER
SHOW DATABASES
SHOW DRAINER STATUS
SHOW ENGINES
SHOW ERRORS
SHOW [FULL] FIELDS FROM
SHOW GRANTS
SHOW INDEX [FROM|IN]
SHOW INDEXES [FROM|IN]
SHOW KEYS [FROM|IN]
SHOW MASTER STATUS
SHOW PLACEMENT
SHOW PLACEMENT FOR
SHOW PLACEMENT LABELS
SHOW PLUGINS
SHOW PRIVILEGES
SHOW [FULL] PROCESSSLIST
SHOW PROFILES
SHOW PUMP STATUS
SHOW SCHEMAS
SHOW STATS_HEALTHY
SHOW STATS_HISTOGRAMS
SHOW STATS_META
SHOW STATUS
SHOW TABLE NEXT_ROW_ID
SHOW TABLE REGIONS
SHOW TABLE STATUS
SHOW [FULL] TABLES
SHOW [GLOBAL|SESSION] VARIABLES
SHOW WARNINGS
SHUTDOWN
SPLIT REGION
START TRANSACTION
TABLE
TRACE
TRUNCATE
UPDATE
USE
WITH
- データ型
- 関数と演算子
- クラスタ化インデックス
- 制約
- 生成された列
- SQL モード
- テーブル属性
- 取引
- ガベージ コレクション (GC)
- ビュー
- パーティショニング
- 一時テーブル
- キャッシュされたテーブル
- 文字セットと照合順序
- SQL の配置規則
- システム テーブル
mysql
- 情報_スキーマ
- 概要
ANALYZE_STATUS
CLIENT_ERRORS_SUMMARY_BY_HOST
CLIENT_ERRORS_SUMMARY_BY_USER
CLIENT_ERRORS_SUMMARY_GLOBAL
CHARACTER_SETS
CLUSTER_CONFIG
CLUSTER_HARDWARE
CLUSTER_INFO
CLUSTER_LOAD
CLUSTER_LOG
CLUSTER_SYSTEMINFO
COLLATIONS
COLLATION_CHARACTER_SET_APPLICABILITY
COLUMNS
DATA_LOCK_WAITS
DDL_JOBS
DEADLOCKS
ENGINES
INSPECTION_RESULT
INSPECTION_RULES
INSPECTION_SUMMARY
KEY_COLUMN_USAGE
METRICS_SUMMARY
METRICS_TABLES
PARTITIONS
PLACEMENT_POLICIES
PROCESSLIST
REFERENTIAL_CONSTRAINTS
SCHEMATA
SEQUENCES
SESSION_VARIABLES
SLOW_QUERY
STATISTICS
TABLES
TABLE_CONSTRAINTS
TABLE_STORAGE_STATS
TIDB_HOT_REGIONS
TIDB_HOT_REGIONS_HISTORY
TIDB_INDEXES
TIDB_SERVERS_INFO
TIDB_TRX
TIFLASH_REPLICA
TIKV_REGION_PEERS
TIKV_REGION_STATUS
TIKV_STORE_STATUS
USER_PRIVILEGES
VIEWS
METRICS_SCHEMA
- UI
- TiDB ダッシュボード
- 概要
- 管理
- アクセス
- 概要ページ
- クラスター情報ページ
- Top SQLページ
- キー ビジュアライザー ページ
- メトリクス関係グラフ
- SQL ステートメントの分析
- スロークエリページ
- クラスタ診断
- 検索ログ ページ
- インスタンスのプロファイリング
- セッションの管理とConfiguration / コンフィグレーション
- FAQ
- CLI
- コマンド ライン フラグ
- Configuration / コンフィグレーションファイルのパラメーター
- システム変数
- ストレージ エンジン
- テレメトリー
- エラーコード
- テーブル フィルター
- トポロジ ラベルごとにレプリカをスケジュールする
- よくある質問
- リリースノート
- すべてのリリース
- リリースのタイムライン
- TiDB のバージョニング
- v6.1
- v6.0
- v5.4
- v5.3
- v5.2
- v5.1
- v5.0
- v4.0
- v3.1
- v3.0
- v2.1
- v2.0
- v1.0
- 用語集
TiDBストレージ
このドキュメントでは、 TiKVのいくつかの設計アイデアと重要な概念を紹介します。
キーと値のペア
データストレージシステムを最初に決定するのは、データストレージモデル、つまり、データがどのような形式で保存されるかです。 TiKVの選択はキー値モデルであり、順序付きトラバーサル方法を提供します。 TiKVデータストレージモデルには、次の2つの重要なポイントがあります。
- これは、キーと値のペアを格納する巨大なマップ(C ++の
std::Map
に類似)です。 - マップ内のキーと値のペアは、キーのバイナリ順序に従って順序付けられます。つまり、特定のキーの位置をシークしてからNextメソッドを呼び出して、このキーよりも大きいキーと値のペアを増分順に取得できます。
このドキュメントで説明されているTiKVのKVストレージモデルは、SQLのテーブルとは関係がないことに注意してください。このドキュメントでは、SQLに関連する概念については説明せず、TiKVなどの高性能で信頼性の高い分散型Key-Valueストレージを実装する方法にのみ焦点を当てています。
ローカルストレージ(RocksDB)
永続ストレージエンジンの場合、データは最終的にディスクに保存され、TiKVも例外ではありません。 TiKVはディスクに直接データを書き込みませんが、データの保存を担当するRocksDBにデータを保存します。その理由は、スタンドアロンストレージエンジン、特に注意深い最適化を必要とする高性能スタンドアロンエンジンの開発には多くの費用がかかるためです。
RocksDBは、Facebookによってオープンソース化された優れたスタンドアロンストレージエンジンです。このエンジンは、単一エンジンのTiKVのさまざまな要件を満たすことができます。ここでは、RocksDBを単一の永続的なKey-Valueマップと見なすことができます。
Raftプロトコル
さらに、TiKVの実装は、1台のマシンに障害が発生した場合にデータの安全性を確保するという、より困難な問題に直面しています。
簡単な方法は、データを複数のマシンに複製することです。これにより、1つのマシンに障害が発生した場合でも、他のマシンのレプリカを引き続き使用できます。つまり、信頼性が高く、効率的で、失敗したレプリカの状況を処理できるデータ複製スキームが必要です。これらはすべて、 Raftアルゴリズムによって可能になります。
Raftはコンセンサスアルゴリズムです。このドキュメントでは、 Raftについて簡単に紹介します。詳細については、 理解できるコンセンサスアルゴリズムを求めてを参照してください。Raftにはいくつかの重要な機能があります。
- リーダー選出
- メンバーシップの変更(レプリカの追加、レプリカの削除、リーダーの転送など)
- ログレプリケーション
TiKVはRaftを使用してデータ複製を実行します。各データ変更は、 Raftログとして記録されます。 Raftログレプリケーションを通じて、データはRaftグループの複数のノードに安全かつ確実にレプリケートされます。ただし、 Raftプロトコルによれば、書き込みが成功するために必要なのは、データが大部分のノードに複製されることだけです。
要約すると、TiKVはスタンドアロンマシンRocksDBを介してデータをディスクにすばやく保存し、マシンに障害が発生した場合にRaftを介してデータを複数のマシンに複製できます。データは、RocksDBではなくRaftのインターフェースを介して書き込まれます。 Raftの実装により、TiKVは分散型Key-Valueストレージになります。いくつかのマシン障害が発生した場合でも、TiKVは、アプリケーションに影響を与えないネイティブRaftプロトコルにより、レプリカを自動的に完成させることができます。
リージョン
理解しやすくするために、すべてのデータにレプリカが1つしかないものと想定します。前述のように、TiKVは大きくて整然としたKVマップと見なすことができるため、水平方向のスケーラビリティを実現するためにデータが複数のマシンに分散されます。 KVシステムの場合、複数のマシンにデータを分散するための2つの一般的なソリューションがあります。
- ハッシュ:キーでハッシュを作成し、ハッシュ値に従って対応するストレージノードを選択します。
- 範囲:範囲をキーで除算します。ここで、シリアルキーのセグメントがノードに格納されます。
TiKVは、Key-Valueスペース全体を一連の連続するKeyセグメントに分割する2番目のソリューションを選択します。各セグメントはリージョンと呼ばれます。データを保存する各リージョンにはサイズ制限があります(デフォルト値は96 MBで、サイズを構成できます)。各リージョンは、左閉と右開の間隔である[StartKey, EndKey)
で表すことができます。
ここでのリージョンは、SQLのテーブルとは何の関係もないことに注意してください。このドキュメントでは、SQLを忘れて、今のところKVに焦点を当てます。データをリージョンに分割した後、TiKVは2つの重要なタスクを実行します。
- クラスタのすべてのノードにデータを配布し、 リージョンを基本単位として使用します。各ノードのリージョンの数がほぼ同じになるように最善を尽くしてください。
- リージョンでRaftレプリケーションとメンバーシップ管理を実行します。
これらの2つのタスクは非常に重要であり、1つずつ紹介されます。
まず、データはキーに従って多くのリージョンに分割され、各リージョンのデータは1つのノードにのみ保存されます(複数のレプリカは無視されます)。 TiDBシステムには、クラスタのすべてのノードにリージョンをできるだけ均等に分散させるPDコンポーネントがあります。このようにして、一方で、ストレージ容量は水平方向にスケーリングされます(他のノードのリージョンは、新しく追加されたノードに自動的にスケジュールされます)。一方、負荷分散は実現されます(1つのノードに大量のデータがあり、他のノードにはほとんどデータがないという状況は発生しません)。
同時に、上位クライアントが必要なデータにアクセスできるようにするために、システムには、ノード上のリージョンの分布、つまりキーの正確なリージョンとキーの正確なリージョンを記録するコンポーネント(PD)があります。任意のキーを介して配置されたそのリージョンのノード。
2番目のタスクでは、TiKVはリージョン内のデータを複製します。つまり、1つのリージョン内のデータには、「レプリカ」という名前の複数のレプリカがあります。リージョンの複数のレプリカが異なるノードに保存されてRaftグループを形成します。ラフトグループは、Raftアルゴリズムによって一貫性が保たれます。
レプリカの1つはグループのリーダーとして機能し、もう1つはフォロワーとして機能します。デフォルトでは、すべての読み取りと書き込みはリーダーを介して処理され、読み取りが行われ、書き込みがフォロワーに複製されます。次の図は、 リージョンとRaftグループの全体像を示しています。
リージョンでデータを分散および複製すると、ある程度のディザスタリカバリ機能を備えた分散キーバリューシステムが実現します。容量や、ディスク障害やデータ損失について心配する必要はもうありません。
MVCC
多くのデータベースはマルチバージョン同時実行制御(MVCC)を実装しており、TiKVも例外ではありません。 2つのクライアントが同時にキーの値を変更する状況を想像してみてください。 MVCCがない場合、データをロックする必要があります。分散シナリオでは、パフォーマンスとデッドロックの問題が発生する可能性があります。 TiKVのMVCC実装は、キーにバージョン番号を追加することによって実現されます。つまり、MVCCがない場合、TiKVのデータレイアウトは次のようになります。
Key1 -> Value
Key2 -> Value
……
KeyN -> Value
MVCCの場合、TiKVのキー配列は次のようになります。
Key1_Version3 -> Value
Key1_Version2 -> Value
Key1_Version1 -> Value
……
Key2_Version4 -> Value
Key2_Version3 -> Value
Key2_Version2 -> Value
Key2_Version1 -> Value
……
KeyN_Version2 -> Value
KeyN_Version1 -> Value
……
同じキーの複数のバージョンでは、番号の大きいバージョンが最初に配置されるため(キーが順番に配置されているキーバリューセクションを参照)、キー+バージョンで値を取得するときに、MVCCのキーをキーで構築できることに注意してください。およびバージョンはKey_Version
です。次に、RocksDBのSeekPrefix(Key_Version)
APIを使用して、このKey_Version
以上の最初の位置を直接見つけることができます。
分散ACIDトランザクション
TiKVのトランザクションは、GoogleがBigTableで使用しているモデルを採用しています: パーコレーター 。 TiKVの実装は、多くの最適化を行ったこのペーパーに触発されています。詳細については、 取引概要を参照してください。