devkuma – TiDB

TiDBのソフトウェアおよびハードウェア推奨事項

kc@example.com (kc kim) — Fri, 02 Sep 2022 15:38:00 +0900

ネットワーク要件

オープンソースの分散NewSQLデータベースであるTiDBを実行するには、次のネットワークポート構成が必要である。実際のTiDBデプロイ環境に基づいて、管理者はネットワーク側およびホスト側で関連ポートを開放できる。

コンポーネント	デフォルトポート	説明
TiDB	4000	アプリケーションおよびDBAツール用の通信ポート
TiDB	10080	TiDBの状態を報告するための通信ポート
TiKV	20160	TiKV通信ポート
TiKV	20180	TiKVの状態を報告するための通信ポート
PD	2379	TiDBとPD間の通信ポート
PD	2380	PDクラスターのノード間通信ポート
TiFlash	9000	TiFlash TCPサービスポート
TiFlash	8123	TiFlash HTTPサービスポート
TiFlash	3930	TiFlash RAFTおよびコプロセッササービスポート
TiFlash	20170	TiFlashプロキシサービスポート
TiFlash	20292	PrometheusがTiFlash Proxyメトリクスを取得するポート
TiFlash	8234	PrometheusがTiFlashメトリクスを取得するポート
Pump	8250	Pump通信ポート
Drainer	8249	Drainer通信ポート
TiCDC	8300	TiCDC通信ポート
Monitoring	9090	Prometheusサービスの通信ポート
Monitoring	20120	NgMonitoringサービスの通信ポート
Node_exporter	9100	すべてのTiDBクラスターノードのシステム情報を報告するための通信ポート
Blackbox_exporter	9115	Blackbox_exporter通信ポート。TiDBクラスターのポート監視に使用される。
Grafana	3000	外部Web監視サービスおよびクライアント（ブラウザー）アクセス用ポート
Alertmanager	9093	アラートWebサービスポート
Alertmanager	9094	アラート通信ポート

TiDBの概要

kc@example.com (kc kim) — Mon, 08 Aug 2022 14:32:00 +0900

TiDB(/’taɪdiːbi:/、「Ti」はTitaniumを表す)は、ハイブリッドトランザクション/分析処理（HTAP）ワークロードをサポートするオープンソースのNewSQLデータベースである。MySQLと互換性があり、水平スケーラビリティ、強い一貫性、高可用性を提供する。TiDBの目標は、OLTP（オンライン・トランザクション処理）、OLAP（オンライン分析処理）、HTAPサービスを扱うワンストップのデータベースソリューションをユーザーに提供することである。TiDBは、高可用性と大規模データの強い一貫性を必要とするさまざまなユースケースに適している。

主な機能

水平スケールアウトとシンプルなスケールイン

コンピューティングとストレージを分離するTiDBのアーキテクチャ設計により、必要に応じてコンピューティング容量またはストレージ容量をオンラインで個別にスケールアウトまたはスケールインできる。スケーリング処理は、アプリケーションの運用・保守担当者に対して透過的である。
金融グレードの高可用性

データは複数のレプリカに保存される。データレプリカはMulti-Raftプロトコルを使用してトランザクションログを複製する。トランザクションは、データが大多数のレプリカに正常に書き込まれた場合にのみコミットできる。これにより、少数のレプリカが停止しても強い一貫性と可用性を保証できる。さまざまな災害耐性レベルの要件を満たすため、必要に応じて地理的位置とレプリカ数を構成できる。
リアルタイムHTAP

TiDBは2つのストレージエンジンを提供する。TiKVは行ベースのストレージエンジンであり、TiFlashは列ベースのストレージエンジンである。TiFlashはMulti-Raft Learnerプロトコルを使用してTiKVのデータをリアルタイムに複製し、TiKVの行ベースストレージエンジンとTiFlashの列ベースストレージエンジン間のデータ一貫性を保証する。TiKVとTiFlashは、HTAPのリソース分離の問題を解決するため、必要に応じて別々のシステムにデプロイできる。

HTAP（Hybrid Transaction/Analytical Processing）
HTAP（Hybrid Transaction/Analytical Processing）は、調査会社Gartnerが名付けた用語である。データ複製なしでOLTP（Online Transaction Processing）とOLAP（Online Analytical Processing）を実現できる次世代データプラットフォームを意味する。原文: [「ビッグデータ倹約イノベーション」··· MapRが伝える8つの融合のコツ](https://www.ciokorea.com/t/544/12200/30801?page=0,1#csidxd92aa7fca28b93089f3d5aea81955b0)
クラウドネイティブ分散データベース

TiDBはクラウド向けに設計された分散データベースであり、クラウドプラットフォームに柔軟なスケーラビリティ、信頼性、セキュリティを提供する。ユーザーは変化するワークロード要件に合わせてTiDBを柔軟に拡張できる。TiDBでは、各データに少なくとも3つのレプリカがあり、データセンター全体の停止に耐えられるように異なるクラウド可用性ゾーンに配置できる。TiDB OperatorはKubernetes上でのTiDB管理を支援し、TiDBクラスター運用に関連する作業を自動化する。これにより、マネージドKubernetesを提供するクラウドにTiDBを簡単にデプロイできる。完全マネージド型TiDBサービスであるTiDB Cloudは、クラウドでTiDBの力を活用する最も簡単で経済的、かつ弾力的な方法であり、数回のクリックだけでTiDBクラスターをデプロイして実行できる。
MySQL 5.7プロトコルおよびMySQLエコシステムとの互換性

TiDBはMySQL 5.7プロトコル、MySQLの一般的な機能、MySQLエコシステムと互換性がある。アプリケーションをTiDBへ移行する際、多くの場合はコードを1行も変更する必要がなく、必要であっても少量のコード変更だけで済む。また、TiDBはアプリケーションデータをTiDBへ簡単に移行するための一連のデータ移行ツールを提供する。

ユースケース

データの一貫性、信頼性、可用性、スケーラビリティ、耐障害性に対する高い要件がある金融業界のシナリオ

よく知られているように、金融業界ではデータの一貫性、信頼性、可用性、スケーラビリティ、耐障害性に対して高い要件がある。従来のソリューションでは、同一都市の2つのデータセンターでサービスを提供し、別都市の3つ目のデータセンターは災害復旧用のデータを保持するがサービスは提供しない。このソリューションには、リソース使用率が低く保守コストが高いという欠点があり、RTO（Recovery Time Objective、目標復旧時間）とRPO（Recovery Point Objective、目標復旧時点）も期待を満たしていない。TiDBは複数のレプリカとMulti-Raftプロトコルを使用して、異なるデータセンター、ラック、機器にデータをスケジューリングする。一部の機器で障害が発生すると、システムが自動的に切り替わり、RTO ≤ 30秒、RPO = 0を実現する。
ストレージ容量、スケーラビリティ、同時実行性に対する要件が高い、大量データかつ高同時実行のシナリオ

アプリケーションが急速に成長すると、データも急増する。従来のスタンドアロンデータベースでは、データ容量の要件を満たせない。解決策は、シャーディングミドルウェアまたはTiDBのようなNewSQLデータベースを使用することである。後者は費用対効果が高い。TiDBはコンピューティングとストレージを分離したアーキテクチャを使用するため、コンピューティング容量またはストレージ容量を個別にスケールアウトまたはスケールインできる。コンピューティングレイヤーは最大512ノードをサポートし、各ノードは最大1,000の同時実行をサポートし、クラスターの最大容量はPB（ペタバイト）レベルに達する。
リアルタイムHTAPシナリオ

5G、モノのインターネット、人工知能の急速な成長に伴い、企業が生成するデータは大幅に増加し、数百TB（テラバイト）またはPB規模に達している。従来のソリューションは、OLTPデータベースでオンライントランザクションアプリケーションを処理し、ETL（抽出、変換、ロード）ツールを使用してデータ分析用にOLAPデータベースへデータを複製することである。このソリューションには、ストレージコストが高くリアルタイム性が低い可能性があるという欠点がある。TiDBはv4.0でTiFlash列指向ストレージエンジンを導入した。これはTiKV行ベースストレージエンジンと組み合わせることで、TiDBを真のHTAPデータベースにする。少量の追加ストレージコストで、オンライントランザクション処理とリアルタイムデータ分析の両方を同じシステムで処理できるため、コストを大幅に削減できる。
データ集約および二次処理シナリオ

ほとんどの企業アプリケーションデータは、さまざまなシステムに分散している。アプリケーションが成長するにつれて、意思決定者は会社全体のビジネス状況を把握し、適切なタイミングで意思決定を下す必要がある。この場合、企業は分散したデータを同じシステムに集約し、二次処理を行ってT+0またはT+1レポートを生成する必要がある。従来のソリューションはETLとHadoopを使用することだが、Hadoopシステムは複雑で、運用・保守およびストレージコストが高い。Hadoopと比較すると、TiDBははるかにシンプルである。TiDBが提供するETLまたはデータ移行ツールを使用して、データをTiDBに複製できる。レポートはSQL文を使用して直接生成できる。

TiDB Introduction 最終更新日 2022年8月11日 18:22:49: overview: refine the size of the intro video (#9938) (#9940)

TiDBの実験的機能

kc@example.com (kc kim) — Thu, 01 Sep 2022 18:06:00 +0900

この文書では、TiDBのさまざまなバージョンにおける実験的機能を紹介する。これらの機能を本番環境で使用することは推奨しない。

パフォーマンス

PREDICATE COLUMNS統計の収集をサポート（v5.4で導入）
統計の同期ロードをサポート（v5.4で導入）
統計収集のためのメモリクォータ制御（v6.1.0で導入）
統計を素早く作成するため、約10,000行のデータをランダムにサンプリング（v3.0で導入）

安定性

オプティマイザーが選択するインデックスの安定性を向上させる。複数列の順序依存情報を収集することで、統計機能を拡張する（v5.0で導入）。
TiKVが限られたリソースでデプロイされている場合、TiKVのフォアグラウンドで処理する読み書きリクエストが多すぎると、バックグラウンドでこれらのリクエストを処理するために使用されるCPUリソースが占有され、TiKVの性能安定性に影響する。この状況を避けるには、クォータリミッターを使用してフォアグラウンドで使用されるCPUリソースを制限する。（v6.0で導入）

スケジューリング

エラスティックスケジューリング機能。これにより、TiDBクラスターはリアルタイムのワークロードに基づいてKubernetes上で動的にスケールアウトおよびスケールインできる。これにより、アプリケーションのピーク時の負荷を効果的に軽減し、オーバーヘッドを節約できる。詳細については、TidbClusterの自動スケーリングの使用を参照する。（v4.0で導入）

SQL

式インデックス機能。式インデックスは関数ベースインデックスとも呼ばれる。インデックスを作成する際、インデックスフィールドは特定の列である必要はなく、1つ以上の列から計算された式にすることができる。この機能は、計算ベースのテーブルへ高速にアクセスするのに役立つ。詳細については、式インデックスを参照する。（v4.0で導入）
生成列（v2.1で導入）
ユーザー定義変数（v2.1で導入）
JSONデータ型およびJSON関数（v2.1で導入）
Cascades Planner: Cascadesフレームワークに基づくトップダウン型クエリオプティマイザー（v3.0で導入）
ALTER TABLE ... COMPACT（v6.1.0で導入）
ALTER TABLEを使用した複数列またはインデックスの変更（v5.0.0で導入）

ストレージ

Titanの無効化（v4.0で導入）
Titanレベルマージ（v4.0で導入）
パーティションはバケットに分割される。バケットは同時クエリの単位として使用され、スキャンの同時実行性を向上させる。（v6.1.0で導入）
TiKVはAPI V2を導入する。（v6.1.0で導入）

バックアップと復元

RawKVのバックアップと復元（v3.1で導入）

データ移行

DMで移行タスクを管理するためにWebUIを使用する。（v6.0で導入）

ガベージコレクション

Green GC（v5.0で導入）

診断

SQL診断（v4.0で導入）
クラスター診断（v4.0で導入）

TiDB Experimental Features 最終更新日 2022年8月11日 18:36:36: Add Cascades Planner to experimental-features (#9854) (#9934)

TiDBの制限事項

kc@example.com (kc kim) — Fri, 02 Sep 2022 14:49:00 +0900

この文書では、識別子の最大長、サポートされるデータベース、テーブル、インデックス、パーティションテーブル、シーケンスの最大数など、TiDBの一般的な使用制限について説明する。

識別子の長さ制限

識別子タイプ	最大長（許可される文字数）
Database	64
Table	64
Column	64
Index	64
View	64
Sequence	64

データベース、テーブル、ビュー、接続の総数に関する制限

識別子タイプ	最大数
Databases	無制限
Tables	無制限
Views	無制限
Connections	無制限

単一データベースの制限

タイプ	上限
テーブル	無制限

単一テーブルの制限

タイプ	上限（デフォルト）
Columns	デフォルトは1017で、最大4096まで調整できる。
Indexes	デフォルトは64で、最大512まで調整できる。
Rows	無制限
Size	無制限
Partitions	8192

Columnsの上限はtable-column-count-limitで変更できる。
Indexesの上限はindex-limitで変更できる。

1行の制限

タイプ	上限
サイズ	6MB
`txn-entry-size-limit`設定項目でサイズ制限を調整できる。

単一列の制限

タイプ	上限
サイズ	6MB

文字列型の制限

タイプ	上限
CHAR	256文字
BINARY	256文字
VARBINARY	65535文字
VARCHAR	16383文字
TEXT	6MB
BLOB	6MB

SQL文の制限

タイプ	上限
単一トランザクション内のSQL文の最大数	楽観的トランザクションを使用し、トランザクション再試行を使用する場合、上限は5000である。

stmt-count-limit設定項目で制限を変更できる。

Credits 最終更新日 2022年4月7日 14:42:32: Add TiFlash to the credits.md (#8080)

TiDB

kc@example.com (kc kim) — Wed, 03 Aug 2022 15:06:00 +0900

このページには、原文の一部の翻訳が含まれている。

TiDBについて

kc@example.com (kc kim) — Thu, 01 Sep 2022 17:59:00 +0900

TiDBのインストール

kc@example.com (kc kim) — Wed, 03 Aug 2022 15:06:00 +0900

クイックスタート

kc@example.com (kc kim) — Fri, 02 Sep 2022 15:18:00 +0900

TiDB Operator - 自動フェイルオーバー

kc@example.com (kc kim) — Tue, 01 Nov 2022 01:25:00 +0900

自動フェイルオーバーとは

TiDBクラスター内のノードが何らかの理由で動作しない障害が発生した場合、TiDBが自動的に新しいノードを追加し、クラスターの可用性を保証するようである。

自動フェイルオーバーテスト

テストでは、2つのTiDBサーバープロセスのうち1つをKillし、自動復旧するか確認してみる。

まず、tidb-serverプロセスを確認する。

]$ ps -ef | grep tidb-server | grep -v grep
kimkc    14506 14429  0 11:53 pts/0    00:00:22 /home/kimkc/.tiup/components/tidb/v6.1.0/tidb-server -P 4000 --store=tikv --host=127.0.0.1 --status=10080 --path=127.0.0.1:2379,127.0.0.1:2382,127.0.0.1:2384 --log-file=/home/kimkc/.tiup/data/TLr4XQE/tidb-0/tidb.log
kimkc    14508 14429  0 11:53 pts/0    00:00:26 /home/kimkc/.tiup/components/tidb/v6.1.0/tidb-server -P 4001 --store=tikv --host=127.0.0.1 --status=10081 --path=127.0.0.1:2379,127.0.0.1:2382,127.0.0.1:2384 --log-file=/home/kimkc/.tiup/data/TLr4XQE/tidb-1/tidb.log

ポート番号4001のプロセスを強制終了してみる。

$ kill -9 14508
[kimkc@localhost ~]$ ps -ef | grep tidb-server | grep -v grep
kimkc    14506 14429  0 11:53 pts/0    00:00:22 /home/kimkc/.tiup/components/tidb/v6.1.0/tidb-server -P 4000 --store=tikv --host=127.0.0.1 --status=10080 --path=127.0.0.1:2379,127.0.0.1:2382,127.0.0.1:2384 --log-file=/home/kimkc/.tiup/data/TLr4XQE/tidb-0/tidb.log
[kimkc@localhost ~]$

TiDBサーバープロセスの1つが停止し、1つだけ残っていることが確認できる。少し待ってみる。

しばらく待っても復旧しない。

[kimkc@localhost ~]$ ps -ef | grep tidb-server | grep -v grep
kimkc    14506 14429  0 11:53 pts/0    00:00:27 /home/kimkc/.tiup/components/tidb/v6.1.0/tidb-server -P 4000 --store=tikv --host=127.0.0.1 --status=10080 --path=127.0.0.1:2379,127.0.0.1:2382,127.0.0.1:2384 --log-file=/home/kimkc/.tiup/data/TLr4XQE/tidb-0/tidb.log
[kimkc@localhost ~]$

単純に、基本機能だけでは復旧しないことが分かる。

TiDB Operator

自動フェイルオーバーには、TiDB Operatorという別のツールが追加で必要である。

TiDBクラスターをKubernetesクラスターで管理し、関連作業を自動化するツールのようである。これがあることで、TiDBは真のクラウドネイティブになれるようである。

クラスターアーキテクチャ

kc@example.com (kc kim) — Thu, 01 Sep 2022 17:59:00 +0900

TiDBの自動フェイルオーバー

kc@example.com (kc kim) — Tue, 01 Nov 2022 01:25:00 +0900

TiDBの大きな特徴の一つとして、高可用性（High Availability）が挙げられる。

高可用性とは、サーバー、ネットワーク、プログラムなどの情報システムが、かなり長い期間にわたって継続的に正常稼働できる性質を指す。高可用性とは「可用性が高い」という意味であり、「絶対に故障しない」ことを意味するものではない。