Heim > Artikel > Backend-Entwicklung > Ist TIDB die Go-Sprache?

Ist TIDB die Go-Sprache?

青灯夜游Original: 2022-12-02 18:24:175995Durchsuche

Ja, TiDB ist in der Go-Sprache geschrieben. TiDB ist eine verteilte NewSQL-Datenbank; sie unterstützt horizontale elastische Erweiterung, ACID-Transaktionen, Standard-SQL, MySQL-Syntax und MySQL-Protokoll und verfügt über starke Datenkonsistenz und Hochverfügbarkeitsfunktionen. Der PD in der TiDB-Architektur speichert die Metainformationen des Clusters, z. B. auf welchem TiKV-Knoten sich der Schlüssel befindet; der PD ist auch für den Lastausgleich und das Daten-Sharding des Clusters verantwortlich. PD unterstützt die Datenverteilung und Fehlertoleranz durch die Einbettung von etcd; PD ist in der Go-Sprache geschrieben.

Die Betriebsumgebung dieses Tutorials: Windows 7-System, GO Version 1.18, Dell G3-Computer.

Es gibt viele Schwergewichtsprojekte in der Go-Sprache, und das leistungsstärkste Go-Open-Source-Projekt in China ist wahrscheinlich TiDB. TiDB ist eine verteilte Datenbank, von der viele Menschen möglicherweise nichts wissen. Lassen Sie mich heute mit Ihnen über dieses Thema sprechen.

TiDB hat ein einfaches Design und seine offizielle Website und sein Code sind sehr einfach zu lesen. Es ist das Open-Source-Projekt erster Wahl zum Erlernen verteilter Datenbanken.

Datenbank, Betriebssystem und Compiler werden zusammen als die drei Hauptsysteme bezeichnet, die als Eckpfeiler der gesamten Computersoftware gelten können.

Viele Menschen haben Datenbanken verwendet, aber nur wenige haben eine Datenbank implementiert, insbesondere eine verteilte Datenbank. Das Verständnis der Implementierungsprinzipien und Details der Datenbank kann einerseits die persönlichen Fähigkeiten verbessern und beim Aufbau anderer Systeme helfen, andererseits kann es auch dazu beitragen, die Datenbank sinnvoll zu nutzen.

1. Einführung in TiDB

TiDB ist eine verteilte NewSQL-Datenbank. Sie unterstützt horizontale elastische Erweiterung, ACID-Transaktionen, Standard-SQL, MySQL-Syntax und MySQL-Protokoll und verfügt über die Hochverfügbarkeitsfunktion einer starken Datenkonsistenz. Es handelt sich um eine Hybriddatenbank, die nicht nur für OLTP-Szenarien, sondern auch für OLAP geeignet ist Szenarien. OLTP: Online-Transaktionsverarbeitung, Online-Transaktionsverarbeitung

OLAP: Online-Analyseverarbeitung, Online-
analytische Verarbeitung.

Hohe Kompatibilität mit MySQL 5.7

TiDB ist hochkompatibel mit dem MySQL 5.7-Protokoll, den allgemeinen Funktionen und der Syntax von MySQL 5.7. Obwohl TiDB die MySQL-Syntax und das MySQL-Protokoll unterstützt, handelt es sich bei TiDB um ein völlig unabhängig vom PingCAP-Team entwickeltes Produkt, das nicht auf MySQL basiert.

TiDB unterstützt derzeit keine Trigger, gespeicherten Prozeduren, benutzerdefinierten Funktionen und Fremdschlüssel.

Benutzerfreundlichkeit

TiDB ist sehr einfach zu verwenden. Sie können TiDB in jeder Anwendung verwenden, die MySQL als Backend-Speicherdienst verwendet Wenn Sie Code anwenden, können Sie die gängigsten MySQL-Verwaltungstools zur Verwaltung von TiDB verwenden.

Solange die Programmiersprache MySQL-Client/-Treiber unterstützt, können Sie TiDB direkt verwenden

Unterstützt verteilte Transaktionen

Ob es sich um ein paar Knoten an einem Ort oder mehrere Knoten über mehrere Rechenzentren handelt, TiDB unterstützt verteilte ACID-Transaktionen

TiDB-Transaktionsmodell ist vom Percolator-Modell von Google inspiriert. Der Hauptteil ist ein

Zwei-Phasen-Commit-Protokoll, und es wurden einige praktische Optimierungen vorgenommen. Das Modell basiert auf einem „Zeitstempelzuweiser“, der jeder Transaktion monoton ansteigende Zeitstempel zuweist, sodass Transaktionskonflikte erkannt werden. Im TiDB-Cluster spielt PD die Rolle des Zeitstempelverteilers. TiDB muss XA nicht unterstützen, um datenbankübergreifende Transaktionen wie MySQL zu erfüllen. Das verteilte Transaktionsmodell von TiDO ist in Bezug auf Leistung und Stabilität viel besser als XA, daher unterstützt es XA nicht und muss es auch nicht unterstützen. Im Vergleich zu herkömmlichen eigenständigen Datenbanken bietet TiDB die folgenden Vorteile:

Rein verteilte Architektur, gute Skalierbarkeit, Unterstützung der elastischen Erweiterung und Kontraktion. Unterstützt SQL und macht das MySQL-Netzwerkprotokoll nach außen zugänglich Weltweit und mit den meisten MySQL-Syntax kompatibel, kann es MySQL in den meisten Szenarien direkt ersetzenUnterstützt standardmäßig hohe Verfügbarkeit. Wenn einige Kopien fehlschlagen, kann die Datenbank selbst automatisch Datenreparatur und Failover durchführen, was für das Unternehmen transparent ist

:
- Die Datenmenge ist groß und kann nicht auf einem einzelnen Computer gespeichert werden.
- Ich möchte kein Sharding durchführen, oder ich bin zu faul, Sharding durchzuführen.
- Es gibt keine offensichtlichen Hotspots im Zugriffsmuster.
- Transaktionen sind erforderlich , starke Konsistenz und Notfallwiederherstellung
- Ich hoffe, dass Echtzeit-HTAP den Speicher reduzieren kann Link
Fünf Kernfunktionen
- Horizontale Erweiterung oder Reduzierung mit einem Klick
  
  Dank des Designs Aufgrund der Speicher- und Rechentrennungsarchitektur von TiDB können Rechenleistung und Speicherung bei Bedarf separat durchgeführt werden. Online-Erweiterung oder -Reduzierung, der Prozess der Erweiterung oder Reduzierung ist für das Betriebs- und Wartungspersonal der Anwendung transparent.
- Hochverfügbarkeit auf Finanzebene
  
  Die Datenkopien synchronisieren Transaktionsprotokolle über das Multi-Raft-Protokoll. Nur erfolgreiche, von der Mehrheit geschriebene Transaktionen können übermittelt werden, wodurch eine starke Datenkonsistenz gewährleistet wird und den Ausfall einiger Kopien verhindern, ohne die Datenverfügbarkeit zu beeinträchtigen. Strategien wie der geografische Standort des Replikats und die Anzahl der Replikate können nach Bedarf konfiguriert werden, um den Anforderungen verschiedener Katastrophentoleranzstufen gerecht zu werden.
- Echtzeit-HTAP
  
  Bietet zwei Speicher-Engines: die Zeilenspeicher-Engine TiKV und die Spaltenspeicher-Engine TiFlash, die Daten von TiKV in Echtzeit über das Multi-Raft-Learner-Protokoll kopieren, um die Zeilenspeicherung sicherzustellen Engine TiKV und Column Storage Engine TiFlash Die Daten sind stark konsistent. TiKV und TiFlash können bei Bedarf auf verschiedenen Maschinen bereitgestellt werden, um das Problem der HTAP-Ressourcenisolation zu lösen.
- Cloud-native verteilte Datenbank
  
  Eine verteilte Datenbank, die speziell für die Cloud entwickelt wurde, kann Bereitstellungstools und Automatisierung in öffentlichen Clouds, privaten Clouds und Hybrid-Clouds realisieren.
- Kompatibel mit dem MySQL 5.7-Protokoll und dem MySQL-Ökosystem
  
  Kompatibel mit dem MySQL 5.7-Protokoll, den allgemeinen MySQL-Funktionen und dem MySQL-Ökosystem. Anwendungen können von MySQL nach TiDB migriert werden, ohne dass eine kleine Menge Code geändert werden muss. Bietet eine Fülle von Datenmigrationstools, die Anwendungen dabei helfen, die Datenmigration einfach abzuschließen.
Vier Kernanwendungsszenarien
- Szenarien mit hohen Attributen der Finanzbranche, die eine hohe Datenkonsistenz und hohe Zuverlässigkeit, hohe Systemverfügbarkeit, Skalierbarkeit und Notfallwiederherstellung erfordern
  
  Wie wir alle wissen Die Finanzbranche stellt hohe Anforderungen an Datenkonsistenz und hohe Zuverlässigkeit, hohe Systemverfügbarkeit, Skalierbarkeit und Notfallwiederherstellung. Die herkömmliche Lösung besteht darin, Dienste in zwei Computerräumen in derselben Stadt bereitzustellen und Datenwiederherstellungsfunktionen in einem entfernten Computerraum bereitzustellen, jedoch keine Dienste bereitzustellen. Diese Lösung weist die folgenden Mängel auf: geringe Ressourcenauslastung, hohe Wartungskosten, RTO (Recovery Time Objective) und RPO (Recovery Point Objective) können den vom Unternehmen erwarteten Wert nicht wirklich erreichen. TiDB verwendet das Multi-Copy + Multi-Raft-Protokoll, um Daten auf verschiedene Computerräume, Racks und Maschinen zu verteilen. Wenn einige Maschinen ausfallen, kann das System automatisch umschalten, um sicherzustellen, dass der RTO des Systems
- Riesige Datenmengen und OLTP-Szenarien mit hoher Parallelität, die eine hohe Speicherkapazität, Skalierbarkeit und Parallelität erfordern.
  
  Mit der schnellen Geschäftsentwicklung ist bei den Daten ein explosionsartiges Wachstum zu verzeichnen, und herkömmliche eigenständige Datenbanken können diese Anforderungen nicht erfüllen Anforderungen Aufgrund des explosionsartigen Wachstums der Daten, die Datenbankkapazität erfordern, bestehen praktikable Lösungen darin, stattdessen Middleware-Produkte mit Unterdatenbanken und Untertabellen oder NewSQL-Datenbanken zu verwenden oder High-End-Speichergeräte zu verwenden NewSQL-Datenbanken wie TiDB. TiDB verwendet eine Rechen- und Speichertrennungsarchitektur, die Rechen- und Speicherkapazität erweitern bzw. verkleinern kann. Die Datenverarbeitung unterstützt maximal 512 Knoten, jeder Knoten unterstützt maximal 1000 Parallelität und die Clusterkapazität unterstützt maximal die PB-Ebene.
- Echtzeit-HTAP-Szenario
  
  Mit der rasanten Entwicklung von 5G, dem Internet der Dinge und künstlicher Intelligenz werden Unternehmen immer mehr Daten produzieren, und deren Umfang kann Hunderte von TB oder sogar PB erreichen Die traditionelle Lösung besteht darin, Online-Transaktionen über eine OLTP-Datenbank zu verarbeiten und Daten zur Datenanalyse über ETL-Tools zu synchronisieren. Diese Verarbeitungslösung weist viele Probleme auf, wie z. B. hohe Speicherkosten und schlechte Echtzeitleistung. TiDB führte in Version 4.0 die Spaltenspeicher-Engine TiFlash ein und kombinierte sie mit der Zeilenspeicher-Engine TiKV, um eine echte HTAP-Datenbank aufzubauen. Mit einem geringen Anstieg der Speicherkosten können Online-Transaktionsverarbeitung und Echtzeit-Datenanalyse im selben System durchgeführt werden , wodurch die Kosten für Unternehmen erheblich gespart werden.
- Datenaggregation und Sekundärverarbeitungsszenarien
  
  Derzeit sind die Geschäftsdaten der meisten Unternehmen in verschiedenen Systemen verstreut und verfügen nicht über eine einheitliche Zusammenfassung. Da sich das Unternehmen weiterentwickelt, muss die Entscheidungsebene des Unternehmens den Geschäftsstatus des gesamten Unternehmens verstehen, um zeitnahe Entscheidungen treffen zu können Es ist notwendig, die Daten zu verteilen. Die Daten in verschiedenen Systemen werden im selben System gesammelt und einer sekundären Verarbeitung unterzogen, um T+0- oder T+1-Berichte zu erstellen. Die traditionelle gängige Lösung ist die Verwendung von ETL + Hadoop, aber das Hadoop-System ist zu komplex und die Betriebs-, Wartungs- und Speicherkosten sind zu hoch, um den Anforderungen der Benutzer gerecht zu werden. Im Vergleich zu Hadoop ist TiDB viel einfacher. Unternehmen synchronisieren Daten mit TiDB über ETL-Tools, oder TiDB-Synchronisierungstools können direkt über SQL in TiDB generiert werden.
2. Schnell loslegen

TiDB ist ein verteiltes System. Der einfachste TiDB-Testcluster besteht normalerweise aus 2 TiDB-Instanzen, 3 TiKV-Instanzen, 3 PD-Instanzen und optionalen TiFlash-Instanzen. Über TiUP Playground können Sie schnell den oben genannten grundlegenden Testcluster erstellen. Die Schritte sind wie folgt: TiUP Playground，可以快速搭建出上述的一套基础测试集群，步骤如下：
- step1、下载并安装 TiUP。
```
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
===============================================
```
- step2、声明全局环境变量。 source ${your_shell_profile}
- ```
source /home/user/.bashrc
```
- ```
tiup playground
```
step3 Führen Sie den folgenden Befehl in der aktuellen Sitzung aus, um den Cluster zu starten.
```
#简单来说，没有 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
……
```
Schritt 4, Verifizierung. [Jetzt können Sie TiDB wie MySQL verwenden einander zu einem vollständigen TiDB-System zusammen. Das entsprechende Architekturdiagramm lautet wie folgt:
- Go-Video-Tutorial
  ]
- PD speichert die Metainformationen des Clusters, z. B. auf welchem TiKV-Knoten sich der Schlüssel befindet; PD ist auch für den Lastausgleich und das Daten-Sharding verantwortlich Cluster. PD unterstützt die Datenverteilung und Fehlertoleranz durch die Einbettung von etcd. PD ist in Go-Sprache geschrieben.
- TiKV ist eine verteilte Schlüsselwert-Speicher-Engine, die Transaktionen bereitstellt. Sie basiert auf Google Spanner und HBase, ist jedoch vom zugrunde liegenden komplexeren HDFS getrennt. Speichern Sie Schlüsselwertwerte lokal über RocksDB und verwenden Sie das Raft-Protokoll für die Replikation, um die Datenkonsistenz und Notfallwiederherstellung aufrechtzuerhalten. TiKV ist in der Rust-Sprache geschrieben. 1. Speicherung der TiDB-Datenbank – TiKV-Server. TiDB-Speichermodell, eine verteilte KV-Engine mit Transaktionen So erreichen Sie eine Fehlertoleranz bei mehreren Kopien.
  
  Speicherknoten
  TiKV-Server
TiFlash: TiFlash ist eine spezielle Art von Speicherknoten. Im Gegensatz zu gewöhnlichen TiKV-Knoten werden Daten in TiFlash in Spaltenform gespeichert und ihre Hauptfunktion besteht darin, Analyseszenarien zu beschleunigen.

TiKV
Beim Speichern von Daten muss sichergestellt werden, dass: Daten nicht verloren gehen und in gutem Zustand sind → Raft-Protokoll. Darüber hinaus müssen die folgenden Punkte berücksichtigt werden:
1. Kann es eine rechenzentrumsübergreifende Notfallwiederherstellung unterstützen? 2. Ist die Schreibgeschwindigkeit schnell genug? 3. Sind die Daten nach dem Speichern gut lesbar? 4. Wie kann ich die gespeicherten Daten ändern? Wie werden gleichzeitige Änderungen unterstützt?
5. Wie ändere ich mehrere Datensätze atomar?
Das TiKV-Projekt löst die oben genannten Probleme sehr gut. Also Wie implementiert man eine riesige (verteilte) Karte mit hoher Leistung und hoher Zuverlässigkeit wie TiKV?
- TiKV ist eine riesige Karte, die Schlüssel-Wert-Paare speichert.
- Die Schlüssel-Wert-Paare in dieser Karte sind entsprechend der binären Reihenfolge des Schlüssels geordnet, das heißt, wir können Suchen Sie nach der Position eines bestimmten Schlüssels und rufen Sie dann kontinuierlich die Next-Methode auf, um größere Schlüsselwerte zu erhalten als dieser Schlüssel in aufsteigender Reihenfolge.
Raft and RocksDB

TiKV verwendet Raft für die Datenreplikation. Durch die Protokollreplikationsfunktion von Raft können Daten sicher und zuverlässig mit den meisten Knoten der Gruppe synchronisiert werden. .

TiKV schreibt die Daten nicht direkt auf die Festplatte, sondern speichert die Daten in RocksDB. RocksDB ist für die spezifische Datenimplementierung verantwortlich. [RocksDB ist eine hervorragende Open-Source-Standalone-Speicher-Engine. 】

Durch die Verwendung des Raft-Konsensalgorithmus werden Daten zwischen jedem TiKV-Knoten in mehrere Kopien kopiert, um die Sicherheit der Daten zu gewährleisten, wenn ein Knoten ausfällt.

Tatsächlich verwendet
TiKV unter der Haube ein Replikationsprotokoll + ein Zustandsmaschinenmodell (State Machine)
, um Daten zu replizieren. Bei Schreibanfragen werden Daten an den Leader geschrieben, der den Befehl dann in Form eines Protokolls an seine Follower kopiert. Wenn die Mehrheit der Knoten im Cluster dieses Protokoll empfängt, wird das Protokoll festgeschrieben und die Zustandsmaschine ändert sich entsprechend.

RegionskonzeptFür ein KV-System gibt es zwei typische Lösungen zum Verteilen von Daten auf mehrere Maschinen: Die eine besteht darin, einen Hash gemäß dem Schlüssel durchzuführen und den entsprechenden Speicherknoten gemäß dem Hash-Wert auszuwählen Die erste besteht darin, den Bereich zu teilen und einen bestimmten Zeitraum aufeinanderfolgender Schlüssel auf einem Speicherknoten zu speichern.
Um die Bereichsabfrage zu unterstützen
hat TiKV die zweite Methode gewählt, den gesamten Schlüsselwertraum in viele Segmente unterteilt. Jedes Segment ist eine Reihe aufeinanderfolgender Schlüssel. Wir nennen jedes Segment eine Region Versuchen Sie unser Bestes, die in jeder Region gespeicherten Daten auf nicht mehr als eine bestimmte Größe zu beschränken (diese Größe kann konfiguriert werden, derzeit ist die Standardgröße 96 MB). Jede Region kann durch ein links geschlossenes und rechts offenes Intervall von StartKey bis EndKey beschrieben werden.

Nachdem wir die Daten in Regionen unterteilt haben, werden wir
Zwei wichtige Dinge tun
:
- Verteilen Sie die Daten auf allen Knoten im Cluster in Regionseinheiten und versuchen Sie sicherzustellen, dass jeder Knoten die Anzahl der Regionen hat serviert wird, ist ungefähr gleich.
  Daten werden nach Schlüssel in viele Regionen unterteilt, und die Daten jeder Region werden nur auf einem Knoten gespeichert. Unser System wird über eine Komponente [PD] verfügen, die dafür verantwortlich ist, Regionen möglichst gleichmäßig auf alle Knoten im Cluster zu verteilen. Auf diese Weise wird einerseits eine horizontale Erweiterung der Speicherkapazität (nach dem Hinzufügen neuer Knoten) erreicht wird automatisch hinzugefügt. Die Region auf dem Knoten wird geplant), und andererseits wird auch ein Lastausgleich erreicht (es wird nicht vorkommen, dass ein bestimmter Knoten viele Daten hat und andere Knoten nur wenige Daten haben). Um sicherzustellen, dass der Client der oberen Ebene auf die erforderlichen Daten zugreifen kann, zeichnet die Komponente [PD] im System gleichzeitig auch die Verteilung der Region auf dem Knoten auf Das heißt, Sie können dies über einen beliebigen Schlüssel tun Fragen Sie ab, in welcher Region sich der Schlüssel befindet und auf welchem Knoten sich die Region derzeit befindet.
  
  Führen Sie Raft-Replikation und Mitgliederverwaltung in Regionseinheiten durch.
- Nachdem Sie Region verstanden haben, sollten Sie in der Lage sein, das folgende Bild zu verstehen:
MVCC
Wenn zwei Clients gleichzeitig den Wert eines Schlüssels ohne MVCC ändern, müssen die Daten in einem verteilten Szenario gesperrt werden, was zu Leistungs- und Deadlock-Problemen führen kann. Die MVCC-Implementierung von TiKV wird durch Hinzufügen einer Version nach dem Schlüssel implementiert.
对于同一个 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
……
```
GC

TiDB 的事务的实现采用了 MVCC（多版本并发控制）机制，当新写入的数据覆盖旧的数据时，旧的数据不会被替换掉，而是与新写入的数据同时保留，并以时间戳来区分版本。Garbage Collection (GC) 的任务便是清理不再需要的旧数据。
- 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)。
2、TiDB数据库的计算——TiDB Server

从 SQL 的角度了解了数据是如何存储，以及如何用于计算。

TiDB 在 TiKV 提供的分布式存储能力基础上，构建了兼具优异的交易处理能力与良好的数据分析能力的计算引擎。

TiDB Server：SQL 解析层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。TiDB 层本身是无状态的，实践中可以启动多个 TiDB 实例，通过负载均衡组件（如 LVS、HAProxy 或 F5）对外提供统一的接入地址，客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。TiDB Server 本身并不存储数据，只是解析 SQL，将实际的数据读取请求转发给底层的存储节点 TiKV（或 TiFlash）。

SQL映射KV

可以将关系模型简单理解为 Table 和 SQL 语句，那么问题变为如何在 KV 结构上保存 Table 以及如何在 KV 结构上运行 SQL 语句。 SQL 和 KV 结构之间存在巨大的区别，那么如何能够方便高效地进行映射，就成为一个很重要的问题。一个好的映射方案必须有利于对数据操作的需求。

分布式SQL运算

首先我们需要将计算尽量靠近存储节点，以避免大量的 RPC 调用。其次，我们需要将 Filter 也下推到存储节点进行计算，这样只需要返回有效的行，避免无意义的网络传输。最后，我们可以将聚合函数、GroupBy 也下推【计算下推】到存储节点，进行预聚合，每个节点只需要返回一个 Count 值即可，再由 tidb-server 将 Count 值 Sum 起来【并行算子】。这里有一个数据逐层返回的示意图：

实际上 TiDB 的 SQL 层要复杂的多，模块以及层次非常多，下面这个图【SQL引擎架构】列出了重要的模块以及调用关系：

Kurzer Prozess der SQL-Abfragerückgabe: Die SQL-Anfrage des Benutzers wird direkt an den TIDB-Server gesendet, oder der TIDB-Server analysiert das MySQL-Protokollpaket, ruft den Anforderungsinhalt ab und führt dann eine Syntaxanalyse und einen Abfrageplan durch Formulierung und Optimierung, Ausführen von Abfrageplänen zum Abrufen und Verarbeiten von Daten. Alle Daten werden im TiKV-Cluster gespeichert, daher muss in diesem Prozess der TIDB-Server mit dem TIKV-Server interagieren, um Daten zu erhalten. Schließlich muss der TIDB-Server die Abfrageergebnisse an den Benutzer zurückgeben.

SQL-Ausführungsprozess

In TiDB ist der Prozess vom Eingabeabfragetext bis zum endgültigen Ausführungsplanausführungsergebnis in der folgenden Abbildung dargestellt:

Zuerst analysiert der Parser den ursprünglichen Abfragetext und einige einfach Nach der Legalitätsprüfung nimmt TiDB zunächst einige logisch äquivalente Änderungen an der Abfrage vor – Abfragelogikoptimierung.
Durch diese äquivalenten Änderungen kann diese Abfrage im logischen Ausführungsplan einfacher zu handhaben sein. Nachdem die entsprechende Änderung abgeschlossen ist, erhält TiDB eine Abfrageplanstruktur, die der ursprünglichen Abfrage entspricht, und erhält dann einen endgültigen Ausführungsplan basierend auf der Datenverteilung und den spezifischen Ausführungskosten eines Operators – Physische Abfrageoptimierung.
Gleichzeitig können Sie, wenn TiDB die PREPARE-Anweisung ausführt, das Caching aktivieren, um die Kosten für die Generierung von Ausführungsplänen durch TiDB zu senken – Ausführungsplan-Caching.

3. TiDB-Datenbankplanung – PD-Server

PD (Placement Driver) ist das Verwaltungsmodul des TiDB-Clusters und ist auch für die Echtzeitplanung von Clusterdaten verantwortlich.

Planungsszenarien

PD (Placement Driver) Server: Das Metainformationsverwaltungsmodul des gesamten TiDB-Clusters, verantwortlich für die Speicherung der Echtzeit-Datenverteilung jedes TiKV-Knotens und der Gesamttopologie des Cluster und Bereitstellung einer TiDB Dashboard-Verwaltungs- und Steuerungsschnittstelle sowie Zuweisung von Transaktions-IDs zu verteilten Transaktionen. PD speichert nicht nur Metainformationen, sondern gibt auch Datenplanungsbefehle an bestimmte TiKV-Knoten aus, basierend auf dem Datenverteilungsstatus, der in Echtzeit von TiKV-Knoten gemeldet wird. Man kann sagen, dass es sich um das „Gehirn“ des gesamten Clusters handelt. Darüber hinaus besteht der PD selbst aus mindestens 3 Knoten, um eine hohe Verfügbarkeit zu gewährleisten. Es wird empfohlen, eine ungerade Anzahl an PD-Knoten bereitzustellen.

Planungsanforderungen

Die erste Kategorie: Als verteiltes Hochverfügbarkeitsspeichersystem muss es mehrere Anforderungen erfüllen: [Notfallwiederherstellungsfunktion]
- Die Anzahl der Replikate darf nicht mehr oder weniger betragen.
- Replikate müssen je nach Topologie auf Maschinen mit unterschiedlichen Attributen verteilt werden.
- Die Notfallwiederherstellung kann im Falle eines Knotenausfalls oder einer Anomalie automatisch, angemessen und schnell durchgeführt werden.
Kategorie 2: Als gutes verteiltes System müssen folgende Dinge berücksichtigt werden: : [Höhere und angemessene Ressourcennutzung, gute Skalierbarkeit]
- Aufrechterhaltung einer gleichmäßigen Verteilung der Führungskräfte im Cluster.
- Behalten Sie die einheitliche Speicherkapazität jedes Knotens bei.
- Behalten Sie eine gleichmäßige Verteilung der Zugangs-Hotspots bei.
- Kontrollieren Sie die Geschwindigkeit des Lastausgleichs, um eine Beeinträchtigung von Onlinediensten zu vermeiden.
- Knotenstatus verwalten, einschließlich der manuellen Online-/Offline-Schaltung von Knoten.
Um diese Anforderungen zu erfüllen, müssen ausreichende Informationen gesammelt werden, z. B. der Status jedes Knotens, Informationen zu jeder Raft-Gruppe, Statistiken über Geschäftszugriffsvorgänge usw.; zweitens müssen einige Richtlinien festgelegt werden Entwickeln Sie auf der Grundlage dieser Informationen und Planungsrichtlinien einen Planungsplan, der den zuvor genannten Anforderungen so weit wie möglich entspricht.

Planungsoperationen

Die grundlegenden Operationen der Planung beziehen sich auf die Strategie zur Erfüllung der Planung. Die oben genannten Planungsanforderungen können in die folgenden drei Vorgänge unterteilt werden:
- Eine Kopie hinzufügen
- Eine Kopie löschen
- Die Führungsrolle zwischen verschiedenen Kopien einer Raft-Gruppe übertragen (migrieren)
Es kommt vor, dass das Raft-Protokoll erfolgreich ist AddReplica、RemoveReplica、TransferLeader Diese drei A-Befehle können die oben genannten drei Grundoperationen unterstützen.

Der Status des TiKV Store ist speziell in „Up“, „Disconnect“, „Offline“, „Down“ und „Tombstone“ unterteilt. Die Beziehung zwischen den einzelnen Status ist wie folgt:

Planungsstrategie
- Die Anzahl der Replikate in einer Region ist korrekt.
- Mehrere Kopien in einer Raft-Gruppe befinden sich nicht am selben Ort.
- Kopien werden gleichmäßig auf die Geschäfte verteilt.
- Die Anzahl der Leader ist gleichmäßig auf die Stores verteilt.
- Die Anzahl der Zugangs-Hotspots ist gleichmäßig auf die Filialen verteilt.
- Der von jedem Store belegte Speicherplatz ist ungefähr gleich.
- Kontrollieren Sie die Planungsgeschwindigkeit, um eine Beeinträchtigung der Online-Dienste zu vermeiden.
Planungsimplementierung

PD sammelt kontinuierlich Informationen über den Store [d. h. den TiKV-Knoten] oder das Heartbeat-Paket des Leaders, um detaillierte Daten des gesamten Clusters zu erhalten, und generiert eine Planungsoperationssequenz basierend auf diesen Informationen und der Planung Richtlinie: Jedes Mal, wenn der PD das Heartbeat-Paket vom Region Leader empfängt, prüft er, ob Vorgänge in der Region ausgeführt werden müssen, gibt die erforderlichen Vorgänge über die Antwortnachricht des Heartbeat-Pakets an den Region Leader zurück und überwacht die Ausführung in nachfolgenden Heartbeat-Paketen. Beachten Sie, dass es sich bei den hier aufgeführten Operationen nur um Vorschläge für den Regionsleiter handelt und es keine Garantie dafür gibt, dass sie ausgeführt werden. Ob und wann sie ausgeführt werden, wird vom Regionsleiter selbst anhand seines aktuellen Status festgelegt. 5. Best Practices von TiDB Zuordnungsschema, Sekundärindex-Implementierungsmethode, verteilte Ausführungs-Engine.

Raft

Raft ist ein Konsistenzprotokoll, das eine starke Garantie für die Konsistenz der Datenreplikation bieten kann. Die unterste Ebene von TiDB verwendet Raft, um Daten zu synchronisieren. Jeder Schreibvorgang muss auf die Mehrzahl der Kopien geschrieben werden, bevor der Erfolg an die Außenwelt zurückgegeben werden kann. Auf diese Weise kann sichergestellt werden, dass die Daten im System auf dem neuesten Stand sind, selbst wenn einige Kopien verloren gehen. Wenn beispielsweise maximal 3 Kopien vorhanden sind, wird jeder Schreibvorgang auf 2 Kopien als erfolgreich betrachtet. Wenn nur eine Kopie verloren geht, verfügt mindestens eine der beiden verbleibenden Kopien über die neuesten Daten.

Verglichen mit der Master-Slave-Synchronisationsmethode, die ebenfalls drei Kopien spart, ist die Raft-Methode effizienter, da die Schreibverzögerung von den beiden schnellsten Kopien und nicht von der langsamsten abhängt. Daher ist es bei Verwendung der Raft-Synchronisierung möglich, an mehreren Orten zu leben. In einem typischen Szenario mit drei Zentren an zwei Orten erfordert jeder Schreibvorgang nur erfolgreiche Schreibvorgänge im lokalen Rechenzentrum und einem nahegelegenen Rechenzentrum, um die Datenkonsistenz sicherzustellen, und erfordert keine erfolgreichen Schreibvorgänge in allen drei Rechenzentren.
Verteilte Transaktionen

TiDB bietet vollständige verteilte Transaktionen. Das Transaktionsmodell ist auf Basis von Google Percolator optimiert.

Optimistische SperreDas optimistische Transaktionsmodell von TiDB führt eine Konflikterkennung nur dann durch, wenn es tatsächlich übermittelt wird. Wenn ein Konflikt auftritt, müssen Sie es erneut versuchen. Dieses Modell ist in Szenarien mit schwerwiegenden Konflikten relativ ineffizient, da die Vorgänge vor dem erneuten Versuch ungültig sind und wiederholt werden müssen. Um ein extremeres Beispiel zu nennen: Verwenden Sie die Datenbank als Zähler. Wenn die Parallelität des Zugriffs relativ hoch ist, kommt es zu schwerwiegenden Konflikten, die zu einer großen Anzahl von Wiederholungsversuchen oder sogar zu Zeitüberschreitungen führen. Wenn der Zugriffskonflikt jedoch nicht sehr schwerwiegend ist, ist das optimistische Sperrmodell effizienter. In Szenarien mit schwerwiegenden Konflikten wird empfohlen, pessimistische Sperren zu verwenden oder das Problem auf Systemarchitekturebene zu lösen, z. B. durch das Platzieren von Zählern in Redis.
- Der pessimistische Transaktionsmodus von TiDB ist im Grunde das gleiche wie bei MySQL. Er wird während der Ausführungsphase nach dem Prinzip „Wer zuerst kommt, mahlt zuerst“ gesperrt, um Wiederholungsversuche in Konfliktsituationen zu vermeiden sorgen für eine höhere Erfolgsquote der Transaktion. Pessimistisches Sperren löst auch das Szenario, in dem Sie Daten im Voraus über zur Aktualisierung auswählen sperren möchten. Wenn das Geschäftsszenario selbst jedoch weniger Konflikte aufweist, ist die Leistung des optimistischen Sperrens vorteilhafter.
- Da verteilte Transaktionen eine zweistufige Übermittlung erfordern und die zugrunde liegende Schicht auch eine Raft-Replikation erfordert, ist der Übermittlungsprozess bei sehr großen Transaktionen sehr langsam und der zugrunde liegende Raft-Replikationsprozess bleibt hängen . Um zu verhindern, dass das System hängen bleibt, haben wir die Größe der Transaktionen begrenzt [eine einzelne Transaktion enthält nicht mehr als 5.000 SQL-Anweisungen (Standard)].
  
  select for update 对数据提前锁定的场景。但如果业务场景本身冲突较少，乐观锁的性能会更有优势。
- 事务大小限制
  
  由于分布式事务要做两阶段提交，并且底层还需要做 Raft 复制，如果一个事务非常大，会使得提交过程非常慢，并且会卡住下面的 Raft 复制流程。为了避免系统出现被卡住的情况，我们对事务的大小做了限制【单个事务包含的 SQL 语句不超过 5000 条（默认）】。
数据分片

TiKV 自动将底层数据按照 Key 的 Range 进行分片。每个 Region 是一个 Key 的范围，从 StartKey 到 EndKey
Daten-ShardingTiKV teilt die zugrunde liegenden Daten automatisch entsprechend dem Schlüsselbereich auf. Jede Region ist ein Bereich von Schlüsseln, ein links geschlossenes und rechts offenes Intervall von StartKey bis EndKey. Wenn die Gesamtzahl der Schlüsselwerte in einer Region einen bestimmten Wert überschreitet, wird sie automatisch aufgeteilt. Dieser Teil ist für den Benutzer transparent.

LastausgleichPD plant die Auslastung des Clusters basierend auf dem Status des gesamten TiKV-Clusters. Die Planung basiert auf der Region als Einheit, und die von PD konfigurierte Richtlinie wird als Planungslogik verwendet und automatisch abgeschlossen.

🎜🎜SQL auf KV🎜🎜🎜TiDB ordnet SQL-Strukturen automatisch KV-Strukturen zu. Einfach ausgedrückt führt TiDB die folgenden Vorgänge aus: 🎜
- Eine Datenzeile wird einem KV zugeordnet, dem Schlüssel wird TableID vorangestellt und die Zeilen-ID ist das Suffix TableID 构造前缀，以行 ID 为后缀
- 一条索引映射为一个 KV，Key 以 TableID+IndexID
mit dem Indexwert Sie können sehen, dass die Daten oder der Index in einer Tabelle das gleiche Präfix haben, sodass diese Schlüsselwerte im TiKV-Schlüsselraum vorhanden sind wird in benachbarten Positionen sein. Wenn die Schreibmenge dann groß ist und sich auf eine Tabelle konzentriert, kommt es zu Schreib-Hotspots, insbesondere wenn einige Indexwerte in den kontinuierlich geschriebenen Daten ebenfalls kontinuierlich sind (z. B. die Aktualisierungszeit, ein Feld, das mit der Zeit zunimmt). , wird in einigen Regionen Schreib-Hotspots bilden und zu einem Flaschenhals des gesamten Systems werden. Wenn sich alle Datenlesevorgänge auf einen kleinen Bereich konzentrieren (z. B. Zehntausende oder Hunderttausende aufeinanderfolgender Datenzeilen), kann es ebenfalls zu Datenzugriffs-Hotspots kommen.
Sekundärer Index

TiDB unterstützt einen vollständigen Sekundärindex und ist ein globaler Index. Viele Abfragen können durch den Index optimiert werden. Wenn Sie Sekundärindizes sinnvoll nutzen, sind viele Erfahrungen mit MySQL immer noch auf TiDB anwendbar. In diesem Abschnitt werden jedoch einige Besonderheiten besprochen Vorsichtsmaßnahmen bei der Verwendung von Sekundärindizes auf TiDB sind wichtig.
- Je mehr Sekundärindizes, desto besser.
- Es ist angemessener, Indizes für Spalten mit relativ großer Unterscheidung [Kardinalität] zu erstellen. Wenn mehrere Abfragebedingungen vorliegen, können Sie einen kombinierten Index auswählen und auf das Präfixprinzip ganz links achten.
- Der Unterschied zwischen der Abfrage über den Index und dem direkten Scannen der Tabelle.
- Parallelität abfragen.
  
  Daten sind über viele Regionen verteilt, daher führt TiDB Abfragen gleichzeitig aus. Die Standard-Parallelität ist relativ konservativ, da eine zu hohe Parallelität viele Systemressourcen verbraucht.
  
  Bei Abfragen vom Typ OLTP, die oft keine großen Datenmengen umfassen, kann eine geringe Parallelität bereits die Anforderungen erfüllen.
  Für OLAP-Abfragen ist häufig ein höherer Grad an Parallelität erforderlich.
  Daher unterstützt TiDB die Anpassung der Abfrage-Parallelität über Systemvariablen. [tidb_distsql_scan_concurrency, tidb_index_lookup_size, tidb_index_lookup_concurrency, tidb_index_serial_scan_concurrency usw.]
- Garantieren Sie die Reihenfolge der Ergebnisse durch den Index. [Indizes können nicht nur zum Filtern von Daten verwendet werden, sondern auch zum Sortieren von Daten. Zuerst werden die Zeilen-IDs in der Reihenfolge des Index abgerufen und dann werden die Zeileninhalte in der Reihenfolge der Rückgabe der Zeilen-IDs zurückgegeben. Dadurch wird sichergestellt, dass die zurückgegebenen Ergebnisse entsprechend der Indexspalten angeordnet werden. 】
- unterstützt auch die umgekehrte Indizierung. [Die aktuelle Geschwindigkeit ist langsamer als beim sequenziellen Scan, normalerweise 20 % langsamer. Wenn die Daten häufig geändert werden und es viele Versionen gibt, ist sie sogar noch langsamer. Wenn möglich, wird empfohlen, die umgekehrte Reihenfolge zu vermeiden. Durchsuchen des Indexes:
Weitere Programmierkenntnisse finden Sie unter: Programmiervideo
! ! 🎜

Das obige ist der detaillierte Inhalt vonIst TIDB die Go-Sprache?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme：

Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn

Vorheriger Artikel：Wie werden Funktionen in der Go-Sprache aufgerufen?Nächster Artikel：Wie werden Funktionen in der Go-Sprache aufgerufen?

In Verbindung stehende Artikel

Mehr sehen

Ist TIDB die Go-Sprache?

1. Einführung in TiDB

Fünf Kernfunktionen

Vier Kernanwendungsszenarien

2. Schnell loslegen

TiKV

Raft and RocksDB

GC

2、TiDB数据库的计算——TiDB Server

SQL映射KV

分布式SQL运算

SQL-Ausführungsprozess

3. TiDB-Datenbankplanung – PD-Server

Planungsszenarien

Planungsanforderungen

Planungsoperationen

Planungsstrategie

Planungsimplementierung

Raft

数据分片

LastausgleichPD plant die Auslastung des Clusters basierend auf dem Status des gesamten TiKV-Clusters. Die Planung basiert auf der Region als Einheit, und die von PD konfigurierte Richtlinie wird als Planungslogik verwendet und automatisch abgeschlossen.

Sekundärer Index

In Verbindung stehende Artikel