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.
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-Hohe Kompatibilität mit MySQL 5.7analytische Verarbeitung.
TiDB unterstützt derzeit keine Trigger, gespeicherten Prozeduren, benutzerdefinierten Funktionen und Fremdschlüssel.
Benutzerfreundlichkeit.
Unterstützt verteilte 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
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.
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.
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
Schritt 2. Deklarieren Sie globale Umgebungsvariablen. source ${your_shell_profile}
#新开启一个 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。
#简单来说,没有 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 ……
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-ServerTiFlash: 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.
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 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.
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:
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
对于同一个 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引擎架构】列出了重要的模块以及调用关系:
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.
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.
PD (Placement Driver) ist das Verwaltungsmodul des TiDB-Clusters und ist auch für die Echtzeitplanung von Clusterdaten verantwortlich.
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.
Die erste Kategorie: Als verteiltes Hochverfügbarkeitsspeichersystem muss es mehrere Anforderungen erfüllen: [Notfallwiederherstellungsfunktion]
Kategorie 2: Als gutes verteiltes System müssen folgende Dinge berücksichtigt werden: : [Höhere und angemessene Ressourcennutzung, gute Skalierbarkeit]
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.
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:
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:
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 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.
TiDB bietet vollständige verteilte Transaktionen. Das Transaktionsmodell ist auf Basis von Google Percolator optimiert.
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
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. TableID
vorangestellt und die Zeilen-ID ist das Suffix TableID
构造前缀,以行 ID 为后缀TableID+IndexID
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.
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!