はい、TiDB は go 言語で書かれています。 TiDB は分散 NewSQL データベースであり、水平方向の柔軟な拡張、ACID トランザクション、標準 SQL、MySQL 構文、および MySQL プロトコルをサポートし、強力なデータ一貫性と高可用性機能を備えています。 TiDB アーキテクチャの PD は、キーがどの TiKV ノード上にあるかなど、クラスターのメタ情報を保存します。PD はクラスターのロード バランシングとデータ シャーディングも担当します。 PD は etcd を組み込むことでデータ分散とフォールト トレランスをサポートしており、PD は go 言語で書かれています。
このチュートリアルの動作環境: Windows 7 システム、GO バージョン 1.18、Dell G3 コンピューター。
重量級の Go 言語プロジェクトは数多くありますが、中国で最も強力な Go オープンソース プロジェクトはおそらく TiDB でしょう。 TiDB は分散データベースですが、多くの人はそれについて何も知らないかもしれません。今日はこのテーマについてお話しさせてください。
TiDB はシンプルなデザインで、公式 Web サイトとコードが非常に読みやすいため、分散データベースを学習するための最初のオープンソース プロジェクトです。
データベース、オペレーティングシステム、コンパイラを総称して三大システムと呼び、コンピュータソフトウェア全体の根幹とも言えます。
多くの人がデータベースを使用したことがありますが、データベース、特に分散データベースを実装した人はほとんどいません。データベースの実装原理と詳細を理解することは、一方では個人のスキルを向上させ、他のシステムの構築に役立ちますが、他方では、データベースを有効に活用することにも役立ちます。
TiDB は 分散型 NewSQL データベースです。水平方向の柔軟な拡張、ACID トランザクション、標準 SQL、MySQL 構文、および MySQL プロトコルをサポートし、強力なデータ整合性 高可用性機能を備えています。OLTP シナリオに適しているだけではありません。 OLAP シナリオ用ハイブリッド データベース。
OLTP: オンライン トランザクション処理、オンライン トランザクション処理。
OLAP: オンライン分析処理、オンライン 分析処理。
TiDB は、MySQL 5.7 プロトコルである MySQL 5.7 と高い互換性があります。共通の機能と文法。 TiDB は MySQL の構文とプロトコルをサポートしていますが、TiDB は PingCAP チームによって完全に独立して開発された製品であり、MySQL に基づいて開発されたものではありません。
MySQL 5.7 エコシステムのシステム ツール (PHPMyAdmin、Navicat、MySQL Workbench、mysqldump、Mydumper、Myloader)、クライアントなどはすべて TiDB に適用できます。
TiDB は現在、トリガー、ストアド プロシージャ、カスタム関数、外部キーをサポートしていません。
TiDB は非常に使いやすく、TiDB クラスターを MySQL として使用できます。 MySQL をバックエンド ストレージ サービスとして使用するあらゆるアプリケーションで使用でき、基本的にアプリケーション コードを変更する必要はありません。同時に、最も一般的な MySQL 管理ツールを TiDB の管理に使用できます。
プログラミング言語が MySQL クライアント/ドライバーをサポートしている限り、TiDB を直接使用できます。
1 か所に複数のノードがある場合でも、複数のデータセンターにまたがる場合でも、複数のノード上で、 TiDB は ACID 分散トランザクション をサポートします。
TiDB トランザクション モデルは、Google Percolator モデルからインスピレーションを受けており、本体は 2 フェーズ コミット プロトコル であり、いくつかの実用的な最適化が施されています。作られました。このモデルは、トランザクションの競合が検出されるように、各トランザクションに単調増加するタイムスタンプを割り当てる タイムスタンプ アサイナー に依存しています。 TiDB クラスターでは、PD がタイムスタンプ ディストリビュータ の役割を引き受けます。
TiDB は、MySQL のようなクロスデータベース トランザクションを満たすために XA をサポートする必要はありません。TiDO 独自の分散トランザクション モデルは、パフォーマンスと安定性の点で XA よりもはるかに優れているため、XA をサポートする必要はありません。
従来のスタンドアロン データベースと比較して、TiDB には次の利点があります:
つまり、TiDB は次のようなシナリオに適しています。特徴:#
ワンクリックで水平方向に拡大または縮小 TiDB のストレージとコンピューティングの分離アーキテクチャの設計のおかげで、コンピューティングはオンデマンドで実行でき、ストレージはそれぞれオンラインで拡張または縮小され、拡張または縮小のプロセスはアプリケーションの運用および保守担当者にとって透過的です。
金融グレードの高可用性データは複数のコピーに保存され、データ コピーはトランザクション ログを同期します。 Multi-Raft プロトコルでは、大多数によって書き込まれた成功したトランザクションのみを送信できるため、強力なデータ一貫性が保証され、少数のレプリカの障害がデータの可用性に影響を与えることはありません。レプリカの地理的位置やレプリカの数などの戦略は、さまざまな耐災害性レベルの要件を満たすために必要に応じて構成できます。
リアルタイム HTAP 行ストレージ エンジン TiKV と列ストレージ エンジン TiFlash の 2 つのストレージ エンジンを提供します。マルチパス - Raft Learner プロトコルは TiKV からリアルタイムでデータをコピーし、行ストレージ エンジン TiKV と列ストレージ エンジン TiFlash の間の強力なデータ一貫性を確保します。 TiKV と TiFlash は、HTAP リソース分離の問題を解決するために、オンデマンドで異なるマシンに展開できます。
クラウド向けに特別に設計された分散データベース。TiDB Operator Implement 導入を通じて利用可能パブリック クラウド、プライベート クラウド、ハイブリッド クラウドのツールと自動化。
MySQL 5.7 プロトコル、MySQL 共通機能、MySQL エコシステムとの互換性, アプリケーションは、少量のコードを必要としたり変更したりすることなく、MySQL から TiDB に移行できます。アプリケーションがデータ移行を簡単に完了できるようにする豊富なデータ移行ツールを提供します。
# ご存知のとおり、金融業界はデータの一貫性、高いシステム可用性、高いシステム可用性、拡張性、災害復旧に対する高い要件を持っています。信頼性、および高いシステムの可用性、拡張性、および災害復旧の要件が高くなります。従来のソリューションは、同じ都市にある 2 つのコンピュータ ルームがサービスを提供し、別の場所にある 1 つのコンピュータ ルームがデータ ディザスタ リカバリ機能を提供しますが、サービスは提供しません。このソリューションには、リソース使用率が低い、メンテナンス コストが高い、#RTO という欠点があります。 (目標復旧時間) と
RPO (目標復旧時点)では、企業が期待する価値を真に達成することはできません。 TiDB は、マルチコピー Multi-Raft プロトコルを使用して、さまざまなコンピュータ ルーム、ラック、およびマシンにデータをスケジュールします。一部のマシンに障害が発生した場合、システムは自動的に切り替わり、システムの RTO
# 高いストレージ容量、スケーラビリティ、および同時実行要件を備えた大量のデータと同時実行性の高い OLTP シナリオ# #ビジネスの急速な発展に伴い、データは爆発的な増加を示しています。データの爆発的な増加により、従来のスタンドアロン データベースではデータベースの容量要件を満たすことができません。実現可能な解決策は、サブデータベースとサブテーブル、または NewSQL を備えたミドルウェア製品を使用することです。それらの中で最もコスト効率が高いのは、TiDB などの NewSQL データベースです。 TiDB はコンピューティングとストレージの分離アーキテクチャを採用しており、コンピューティングとストレージをそれぞれ拡張および縮小できます。コンピューティングは最大 512 ノードをサポートし、各ノードは最大 1000 の同時実行をサポートし、クラスター容量は最大 PB レベルをサポートします。
リアルタイム HTAP シナリオ5G、モノのインターネット、人工知能の急速な発展に伴い、企業 ますます多くのデータが生成され、その規模は数百 TB または PB レベルに達する可能性があります。従来のソリューションは、OLTP データベースを通じてオンライン オンライン トランザクションを処理し、ETL ツールを使用してデータを OLAP データベースに同期してデータ分析を行うことです。この処理ソリューションには、ストレージ コストが高い、リアルタイム パフォーマンスが低いなど、多くの問題があります。 TiDB は、バージョン 4.0 で列ストレージ エンジン TiFlash を導入し、行ストレージ エンジン TiKV と組み合わせて真の HTAP データベースを構築しました。ストレージ コストをわずかに増加させるだけで、オンライン トランザクション処理とリアルタイム データ分析を同じシステムで実行できます。 、企業のコストを大幅に節約します。
データ集約と二次処理のシナリオ現在、ほとんどの企業のビジネスデータは統一された概要を持たずに異なるシステムに分散しており、ビジネスの発展に伴い、企業の意思決定レベルはタイムリーな意思決定を行うために全社の経営状況を把握する必要があります。 , そのため、さまざまなシステムに点在するデータを同一システムに集め、二次処理を行ってT 0 または T 1 レポートを生成する必要があります。従来の一般的なソリューションは、ETL Hadoop を使用してそれを完了することですが、Hadoop システムは複雑すぎて、運用と保守、ストレージのコストが高すぎてユーザーのニーズを満たすことができません。 Hadoop と比較すると、TiDB ははるかにシンプルです。ビジネスでは、ETL ツールまたは TiDB 同期ツールを通じてデータを TiDB に同期します。レポートは、SQL を通じて TiDB で直接生成できます。
TiUP Playground を使用すると、上記の基本的なテスト クラスターをすばやく構築できます。手順は次のとおりです:
curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
Successfully set mirror to https://tiup-mirrors.pingcap.com Detected shell: bash Shell profile: /home/user/.bashrc /home/user/.bashrc has been modified to add tiup to PATH open a new terminal or source /home/user/.bashrc to use it Installed path: /home/user/.tiup/bin/tiup =============================================== Have a try: tiup playground ===============================================
source ${your_shell_profile}
source /home/user/.bashrc
tiup playground
MySQL と同じように TiDB を使用できるようになりました]
#新开启一个 session 以访问 TiDB 数据库。 #使用 TiUP client 连接 TiDB: tiup client #也可使用 MySQL 客户端连接 TiDB mysql --host 127.0.0.1 --port 4000 -u root #通过 http://127.0.0.1:9090 访问 TiDB 的 Prometheus 管理界面。 #通过 http://127.0.0.1:2379/dashboard 访问 TiDB Dashboard 页面,默认用户名为 root,密码为空。 #通过 http://127.0.0.1:3000 访问 TiDB 的 Grafana 界面,默认用户名和密码都为 admin。
] の階層構造と、マルチコピー フォールト トレランスを実現する方法。 ストレージ ノードTiKV サーバー
: データの保存を担当します。外部から見ると、TiKV はトランザクションを提供する分散型 Key-Value ストレージ エンジンです。データを格納するための基本単位はリージョンであり、各リージョンはキー範囲 (StartKey から EndKey までの左閉および右開の範囲) のデータを格納する責任を負い、各 TiKV ノードは複数のリージョンを担当します。 TiKV の API は、KV キーと値のペア レベルで分散トランザクションのネイティブ サポートを提供し、デフォルトで SI (スナップショット分離) の分離レベルを提供します。これは、SQL レベルでの分散トランザクションに対する TiDB のサポートの中核でもあります。 TiDB の SQL レイヤーは SQL 解析を完了すると、SQL 実行プランを TiKV API への実際の呼び出しに変換します。したがって、データは TiKV に保存されます。さらに、TiKV 内のデータは自動的に複数のコピー (デフォルトでは 3 つのコピー) を維持し、高可用性と自動フェイルオーバーを自然にサポートします。TiFlash: TiFlash は特別なタイプのストレージ ノードです。通常の TiKV ノードとは異なり、TiFlash 内ではデータが列形式で保存され、その主な機能は分析シナリオを高速化することです。
2. 書き込み速度は十分ですか?
3. データを保存した後、読みやすいですか? 4. 保存したデータを変更するにはどうすればよいですか?同時変更をサポートするにはどうすればよいですか?
5. 複数のレコードをアトミックに変更するにはどうすればよいですか?
TiKV プロジェクトは、上記の問題をうまく解決します。では、
TiKV のような高性能で信頼性の高い巨大な (分散型) マップを実装するにはどうすればよいでしょうか?
TiKV はデータ レプリケーションに Raft を使用します。各データ変更は Raft ログとして記録されます。Raft のログレプリケーション機能により、グループのほとんどのノードにデータが安全かつ確実に同期されます。
TiKV はデータをディスクに直接書き込むことを選択しませんが、データを RocksDB に保存します。RocksDB は特定のデータのランディングを担当します。 [RocksDB は、非常に優れたオープンソースのスタンドアロン ストレージ エンジン です。 】
Raft 整合性アルゴリズムを使用することにより、データは TiKV ノード間で複数のコピーにコピーされ、ノードに障害が発生した場合のデータのセキュリティが確保されます。
実際には、内部では、TiKV はレプリケーション ログ ステート マシン (ステート マシン) モデルを使用してデータをレプリケートします。書き込みリクエストの場合、データはリーダーに書き込まれ、リーダーはコマンドをログの形式でフォロワーにコピーします。クラスター内の大部分のノードがこのログを受信すると、ログはコミットされ、それに応じてステート マシンが変更されます。
KV システムの場合、複数のマシンにデータを分散するための典型的なソリューションが 2 つあります。1 つはキーによるハッシュです。ハッシュ値に応じて対応するストレージノードを選択する方法と、レンジを分割して、ある連続したキーをストレージノードに保存する方法とがあります。 範囲クエリをサポートするために 、TiKV は 2 番目の方法を選択しました。 Key-Value 空間全体を多くのセグメントに分割しました。各セグメントは一連の連続したキーであり、各セグメントを と呼びます。リージョンであり、各リージョンに保存されるデータが特定のサイズを超えないようにします(このサイズは構成可能で、現在のデフォルトは96MBです)。各領域は、StartKey から EndKey までの左閉および右開の間隔で記述することができます。
#データをリージョンに分割した後、2 つの重要な作業を行います:
データはキーに従って多数のリージョンに分割されており、各リージョンのデータは 1 つのノードにのみ保存されます。私たちのシステムには、クラスター内のすべてのノードにリージョンをできるだけ均等に分散する役割を担うコンポーネント [PD] があり、
一方でストレージ容量の水平方向の拡張を実現します(新しいノードを追加した後、リージョンは他のノードは自動的にスケジュールされます)、 一方、負荷分散も実現されます (あるノードに多くのデータがあり、他のノードに少ないデータがあるという状況は発生しません)。同時に、上位層のクライアントが必要なデータに確実にアクセスできるようにするために、システムのコンポーネント [PD] はノード上のリージョンの分布も記録します。キーがどのリージョンにあるか、およびそのリージョンが現在どのノードにあるかをクエリします。
TiKV はリージョン単位でデータをレプリケートします。つまり、リージョンのデータは複数のコピーを保存し、各コピーはレプリカと呼ばれます。レプリカはデータの一貫性を維持するために Raft を使用します (最後に Raft について説明しました)。リージョン内の複数のレプリカは異なるノードに保存され、Raft グループを形成します。 1 つのレプリカはこのグループのリーダーとして機能し、もう 1 つのレプリカはフォロワーとして機能します。すべての読み取りと書き込みはリーダーを通じて実行され、リーダーはフォロワーにコピーされます。
リージョンを理解すると、次の図が理解できるはずです。
对于同一个 Key 的多个版本,把版本号较大的放在前面,版本号小的放在后面。这样当用户通过一个 Key + Version 来获取 Value 的时候,可以将 Key 和 Version 构造出 MVCC 的 Key,也就是 Key-Version。然后可以直接 Seek(Key-Version),定位到第一个大于等于这个 Key-Version 的位置。
#简单来说,没有 MVCC 之前,可以把 TiKV 看做这样的 Key1 -> Value Key2 -> Value …… KeyN -> Value #有了 MVCC 之后,TiKV 的 Key 排列是这样的: 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 ……
TiDB 的事务的实现采用了 MVCC(多版本并发控制)机制,当新写入的数据覆盖旧的数据时,旧的数据不会被替换掉,而是与新写入的数据同时保留,并以时间戳来区分版本。Garbage Collection (GC) 的任务便是清理不再需要的旧数据。
一个 TiDB 集群中会有一个 TiDB 实例被选举为 GC leader,GC 的运行由 GC leader 来控制。
GC 会被定期触发。每次 GC 时,首先,TiDB 会计算一个称为 safe point 的时间戳,接下来 TiDB 会在保证 safe point 之后的快照全部拥有正确数据的前提下,删除更早的过期数据。每一轮 GC 分为以下三个步骤:
step1:“Resolve Locks” 【清理锁】阶段会对所有 Region 扫描 safe point 之前的锁,并清理这些锁。
step2:“Delete Ranges” 【删除区间】阶段快速地删除由于 DROP TABLE
/DROP INDEX
等操作产生的整区间的废弃数据。
step3:“Do GC”【进行GC清理】阶段每个 TiKV 节点将会各自扫描该节点上的数据,并对每一个 key 删除其不再需要的旧版本。
默认配置下,GC 每 10 分钟触发一次,每次 GC 会保留最近 10 分钟内的数据(即默认 GC life time 为 10 分钟,safe point 的计算方式为当前时间减去 GC life time)。如果一轮 GC 运行时间太久,那么在一轮 GC 完成之前,即使到了下一次触发 GC 的时间也不会开始下一轮 GC。另外,为了使持续时间较长的事务能在超过 GC life time 之后仍然可以正常运行,safe point 不会超过正在执行中的事务的开始时间 (start_ts)。
从 SQL 的角度了解了数据是如何存储,以及如何用于计算。
TiDB 在 TiKV 提供的分布式存储能力基础上,构建了兼具优异的交易处理能力与良好的数据分析能力的计算引擎。
TiDB Server:SQL 解析层,对外暴露 MySQL 协议的连接 endpoint,负责接受客户端的连接,执行 SQL 解析和优化,最终生成分布式执行计划。TiDB 层本身是无状态的,实践中可以启动多个 TiDB 实例,通过负载均衡组件(如 LVS、HAProxy 或 F5)对外提供统一的接入地址,客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。TiDB Server 本身并不存储数据,只是解析 SQL,将实际的数据读取请求转发给底层的存储节点 TiKV(或 TiFlash)。
可以将关系模型简单理解为 Table 和 SQL 语句,那么问题变为如何在 KV 结构上保存 Table 以及如何在 KV 结构上运行 SQL 语句。 SQL 和 KV 结构之间存在巨大的区别,那么如何能够方便高效地进行映射,就成为一个很重要的问题。一个好的映射方案必须有利于对数据操作的需求。
首先我们需要将计算尽量靠近存储节点,以避免大量的 RPC 调用。其次,我们需要将 Filter 也下推到存储节点进行计算,这样只需要返回有效的行,避免无意义的网络传输。最后,我们可以将聚合函数、GroupBy 也下推【计算下推】到存储节点,进行预聚合,每个节点只需要返回一个 Count 值即可,再由 tidb-server 将 Count 值 Sum 起来【并行算子】。 这里有一个数据逐层返回的示意图:
实际上 TiDB 的 SQL 层要复杂的多,模块以及层次非常多,下面这个图【SQL引擎架构】列出了重要的模块以及调用关系:
SQL クエリを返す簡単なプロセス: ユーザーの SQL リクエストは tidb-server に直接送信されるか、ロード バランサ経由で送信されます。tidb-server は MySQL プロトコル パケットを解析し、リクエストの内容を取得してから、構文分析の実行 クエリ プランの作成と最適化、データの取得と処理のためのクエリ プランの実行。すべてのデータは TiKV クラスターに保存されるため、このプロセスでは tidb-server が tikv-server と対話してデータを取得する必要があります。最後に、tidb-server はクエリ結果をユーザーに返す必要があります。
TiDB では、入力されたクエリ テキストから最終的な実行プランの実行結果までのプロセスを次の図に示します。
パーサーが元のクエリ テキストを解析し、簡単な合法性を検証した後、TiDB は最初にクエリに論理的に同等の変更をいくつか加えます——クエリ ロジックの最適化。
これらの同等の変更により、このクエリは論理実行プランでの処理が容易になります。同等の変更が完了すると、TiDB は元のクエリと同等のクエリ プラン構造を取得し、データ分散とオペレーターの特定の実行コストに基づいて最終的な実行プランを取得します - クエリの物理的な最適化 。
同時に、TiDB が PREPARE ステートメントを実行するときに、TiDB が実行計画を生成するコストを削減するためにキャッシュを有効にすることを選択できます (実行計画キャッシュ)。
PD (配置ドライバー) は TiDB クラスターの管理モジュールであり、次の役割も果たします。クラスター データのリアルタイム スケジューリング。
PD (配置ドライバー) サーバー: TiDB クラスター全体のメタ情報管理モジュール、ストレージを担当します。各 TiKV ノードとクラスターのトポロジー全体のリアルタイム データ分散を提供し、TiDB ダッシュボード管理および制御インターフェイスを提供し、分散トランザクションにトランザクション ID を割り当てます。 PD はメタ情報を保存するだけでなく、TiKV ノードからリアルタイムに報告されるデータ配信状況に基づいて、特定の TiKV ノードにデータ スケジューリング コマンドを発行する、クラスター全体の「頭脳」とも言えます。さらに、PD 自体は少なくとも 3 つのノードで構成され、高可用性を提供します。奇数の PD ノードを展開することをお勧めします。
最初のカテゴリ: 分散型高可用性ストレージ システムとして、満たさなければならない要件には次のものが含まれます。 : [ディザスタリカバリ機能]
#2 番目のカテゴリ: 優れた分散システムとして、考慮する必要がある事項は次のとおりです。: [より高く合理的なリソース使用率、優れたスケーラビリティ]
AddReplica、
RemoveReplica、
TransferLeader# を通じて上記 3 つをサポートできます。 ## 基本的な操作。 TiKV ストアのステータスは、具体的には、アップ、切断、オフライン、ダウン、および廃棄に分類されます。各ステータスの関係は次のとおりです。
PD は、ストア [つまり、TiKV ノード] またはリーダーのハートビート パケットを通じて継続的に情報を収集し、全体の情報を取得します。 PD はクラスタの詳細データを取得し、この情報とスケジューリング ポリシーに基づいてスケジューリング操作シーケンスを生成します。リージョン リーダーからハートビート パケットを受信するたびに、PD はこのリージョンに対して実行する操作があるかどうかを確認します。 PD は、ハートビート パケットのメッセージを受信すると、必要な操作をリージョン リーダーに返し、実行結果を後続のハートビート パケットで監視します。なお、ここでの運用はリージョンリーダーへの提案であり、実行されることを保証するものではなく、実行するか否か、いつ実行するかはリージョンリーダーの現状に応じて自ら判断するものとします。
TiDB のベスト プラクティスは、その実装原則と密接に関連しています。最初にいくつかの基本的な実装メカニズムを理解することをお勧めします。 Raft、分散トランザクション、データ シャーディング、ロード バランシング、SQL から KV へのマッピング スキーム、セカンダリ インデックスの実装方法、分散実行エンジンが含まれます。
Raft は、強力な整合性データ レプリケーション保証を提供できる整合性プロトコルであり、TiDB の最下層は Raft を使用してデータを同期します。 。各書き込みでは、成功を外部に返す前に大部分のコピーに書き込む必要があるため、たとえ少数のコピーが失われたとしても、システム内で最新のデータが確保されます。たとえば、コピーが最大 3 つある場合、2 つのコピーへの書き込みはそれぞれ成功したとみなされ、コピーが 1 つだけ失われた場合でも、残っている 2 つのコピーのうち少なくとも 1 つは最新のデータを持つことになります。
同様に 3 つのコピーを保存するマスター/スレーブ同期方式と比較すると、Raft 方式は、書き込み遅延が最も遅いコピーではなく 2 つの最も速いコピーに依存するため、より効率的です。したがって、Raft 同期を使用すると、複数の場所に住むことが可能になります。 2 か所に 3 つのセンターがある一般的なシナリオでは、データの整合性を確保するために、各書き込みはローカル データ センターと近くのデータ センターでのみ成功する必要があり、3 つのデータ センターすべてで成功する必要はありません。
TiDB は完全な分散トランザクションを提供し、トランザクション モデルは Google Percolator に基づいて最適化されています。
オプティミスティック ロック
TiDB のオプティミスティック トランザクション モデルは、実際に送信されたときにのみ競合検出を実行します。競合がある場合は、再試行する必要があります。このモデルは、再試行前の操作は無効であり、繰り返す必要があるため、深刻な競合があるシナリオでは比較的非効率的になります。極端な例として、データベースをカウンターとして使用すると、アクセスの同時実行性が比較的高い場合、深刻な競合が発生し、多数の再試行が発生したり、タイムアウトが発生したりすることがあります。ただし、アクセス競合がそれほど深刻でない場合は、楽観的ロック モデルの方が効率的です。深刻な競合が発生するシナリオでは、悲観的ロックを使用するか、Redis にカウンターを配置するなど、システム アーキテクチャ レベルで問題を解決することをお勧めします。
悲観的ロック
TiDB の悲観的トランザクション モード、悲観的トランザクションの動作は基本的に MySQL と同じで、実行フェーズ中にロックされます (先着順)。 、競合を回避するために、特定の状況下で再試行すると、競合が多いトランザクションの成功率を確保できます。悲観的ロックは、select for update
を通じて事前にデータをロックするシナリオも解決します。ただし、ビジネス シナリオ自体の競合が少ない場合は、楽観的ロックのパフォーマンスがより有利になります。
トランザクション サイズ制限
分散トランザクションには 2 段階のコミットが必要であり、最下層にも Raft レプリケーションが必要であるため、トランザクションが非常に大きい場合、送信プロセスはこれは遅く、以下の Raft コピー プロセスをブロックします。システムがスタックするのを防ぐために、トランザクションのサイズを制限しました [1 つのトランザクションに含まれる SQL ステートメントは 5,000 個以下 (デフォルト)]。
TiKV は、キーの範囲に従って基になるデータを自動的に断片化します。各リージョンはキーの範囲であり、StartKey
から EndKey
までの左閉および右開の間隔です。リージョン内の Key-Value の総数が一定の値を超えると、自動的に分割されます。この部分はユーザーには透過的です。
PD は、TiKV クラスター全体のステータスに基づいてクラスターの負荷をスケジュールします。スケジューリングはリージョン単位で、PDで設定したポリシーをスケジューリングロジックとして使用し、自動で完了します。
TiDB は、SQL 構造を KV 構造に自動的にマップします。簡単に言えば、TiDB は次の操作を実行します:
TableID
を使用して構築され、行 ID はサフィックスになります。TableID IndexID
で構築されます。 プレフィックスを構築し、インデックス値を使用してサフィックスを構築します。 テーブル内のデータまたはインデックスは次のようになります。同じプレフィックスなので、TiKV キー空間では、これらの Key-Value は隣接する位置になります。そして、書き込み量が多くテーブルに集中している場合、特に継続的に書き込まれるデータ内の一部のインデックス値も連続している場合(更新時間、時間とともに増加するフィールドなど)、書き込みホットスポットが発生します。 、いくつかのリージョンに書き込みホットスポットが形成され、システム全体のボトルネックになります。同様に、すべてのデータ読み取り操作が狭い範囲 (連続したデータの数万行または数十万行など) に集中している場合、データ アクセス ホットスポットが発生する可能性があります。
TiDB は完全なセカンダリ インデックスをサポートしており、グローバル インデックスであり、インデックスを通じて多くのクエリを最適化できます。セカンダリ インデックスを上手に利用する場合、それはビジネスにとって非常に重要です。MySQL での多くの経験が TiDB にもそのまま当てはまります。ただし、TiDB には注意が必要な独自の特性もいくつかあります。このセクションでは主に次の点について説明します。 TiDB でセカンダリ インデックスを使用する場合の注意事項。
セカンダリ インデックスは多いほど良いです。
識別度 [カーディナリティ] が比較的大きい列にインデックスを作成する方が適切です。複数のクエリ条件がある場合は、結合されたインデックスを選択し、左端のプレフィックスの原則に注意を払うことができます。
インデックスによるクエリとテーブルの直接スキャンの違い。
#クエリの同時実行性。
データは多くのリージョンに分散しているため、TiDB はクエリを同時に実行します。同時実行数が高すぎると大量のシステム リソースが消費されるため、デフォルトの同時実行数は比較的控えめです。 OLTP タイプのクエリの場合、多くの場合、大量のデータが関与しないため、同時実行性が低くてもすでにニーズを満たすことができます。 OLAP タイプのクエリの場合、多くの場合、より高度な同時実行性が必要になります。
プログラミング ビデオをご覧ください。 !
以上がtidb は Go 言語ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。