Oui, TiDB est écrit en langage go. TiDB est une base de données NewSQL distribuée ; elle prend en charge l'expansion élastique horizontale, les transactions ACID, le SQL standard, la syntaxe MySQL et le protocole MySQL, et possède une forte cohérence des données et des fonctionnalités de haute disponibilité. Le PD dans l'architecture TiDB stocke les méta-informations du cluster, telles que le nœud TiKV sur lequel se trouve la clé ; le PD est également responsable de l'équilibrage de charge et du partage des données du cluster ; PD prend en charge la distribution des données et la tolérance aux pannes en intégrant etcd. PD est écrit en langage Go.
L'environnement d'exploitation de ce tutoriel : système Windows 7, GO version 1.18, ordinateur Dell G3.
Il existe de nombreux projets lourds dans le langage Go, et le projet open source Go le plus puissant en Chine est probablement TiDB. TiDB est une base de données distribuée dont beaucoup de gens ne connaissent peut-être rien. Laissez-moi vous parler de ce sujet aujourd'hui.
TiDB a un design simple, et son site officiel et son code sont très faciles à lire. C'est le projet open source de premier choix pour l'apprentissage des bases de données distribuées.
La base de données, le système d'exploitation et le compilateur sont collectivement appelés les trois principaux systèmes, qui peuvent être considérés comme la pierre angulaire de l'ensemble du logiciel informatique.
De nombreuses personnes ont utilisé des bases de données, mais peu ont implémenté une base de données, notamment une base de données distribuée. Comprendre les principes de mise en œuvre et les détails de la base de données peut, d'une part, améliorer les compétences personnelles et aider à construire d'autres systèmes, et d'autre part, cela peut également aider à faire bon usage de la base de données.
TiDB est une base de données NewSQL distribuée. Il prend en charge l'expansion élastique horizontale, les transactions ACID, le SQL standard, la syntaxe MySQL et le protocole MySQL, et possède la fonctionnalité de haute disponibilité d'une forte cohérence des données. Il s'agit d'une base de données hybride qui convient non seulement aux scénarios OLTP mais également à OLAP. scénarios. OLTP : traitement des transactions en ligne, traitement des transactions
en ligne.OLAP : Traitement analytique en ligne,Hautement compatible avec MySQL 5.7traitement analytique en ligne.
TiDB ne prend actuellement pas en charge les déclencheurs, les procédures stockées, les fonctions personnalisées et les clés étrangères.
Facilité d'utilisation.
Prend en charge les transactions distribuées
Le modèle de transaction TiDB est inspiré du Modèle Percolator de Google. Le corps principal est un
protocole de validation en deux phases, et quelques optimisations pratiques ont été apportées. Le modèle repose sur un timestamp assigner qui attribue des horodatages croissants de manière monotone à chaque transaction afin que les conflits de transaction soient détectés. Dans le cluster TiDB, PD joue le rôle de distributeur d'horodatage. TiDB n'a pas besoin de prendre en charge XA pour répondre aux transactions entre bases de données comme MySQL. Le modèle de transaction distribué de TiDO est beaucoup plus élevé que XA en termes de performances et de stabilité, il n'a donc pas besoin de prendre en charge XA.
Par rapport aux bases de données autonomes traditionnelles, TiDB présente les avantages suivants
:Architecture purement distribuée, a une bonne évolutivité, prend en charge l'expansion et la contraction élastiques
Prend en charge SQL et expose le protocole réseau MySQL à l'extérieur monde et compatible avec la plupart des syntaxes MySQL, il peut remplacer directement MySQL dans la plupart des scénariosExtension ou réduction horizontale en un clic Grâce à la conception De l'architecture de séparation du stockage et du calcul de TiDB, le calcul et le stockage peuvent être effectués séparément sur demande Expansion ou réduction en ligne, le processus d'expansion ou de réduction est transparent pour le personnel d'exploitation et de maintenance des applications. Haute disponibilité au niveau financier Les données sont stockées en plusieurs copies. Les copies de données synchronisent les journaux de transactions via le protocole Multi-Raft. Seules les transactions réussies écrites par la majorité peuvent être soumises, garantissant une forte cohérence des données. et empêcher la panne de quelques copies sans affecter la disponibilité des données. Des stratégies telles que l'emplacement géographique et le nombre de répliques peuvent être configurées selon les besoins pour répondre aux exigences des différents niveaux de tolérance aux catastrophes. HTAP en temps réel Fournit deux moteurs de stockage : le moteur de stockage de lignes TiKV et le moteur de stockage de colonnes TiFlash copie les données de TiKV en temps réel via le protocole Multi-Raft Learner pour garantir que le stockage de lignes. moteur TiKV et moteur de stockage en colonnes TiFlash Les données sont fortement cohérentes. TiKV et TiFlash peuvent être déployés sur différentes machines à la demande pour résoudre le problème de l'isolation des ressources HTAP. Base de données distribuée native du cloud Une base de données distribuée spécialement conçue pour le cloud Grâce à TiDB Operator, les outils de déploiement et l'automatisation peuvent être réalisés dans les cloud publics, les cloud privés et les cloud hybrides. Compatible avec le protocole MySQL 5.7 et l'écosystème MySQL Compatible avec le protocole MySQL 5.7, les fonctions communes MySQL et l'écosystème MySQL Les applications peuvent être migrées de MySQL vers TiDB sans ou modifier une petite quantité de code. Fournit une multitude d’outils de migration de données pour aider les applications à effectuer facilement la migration des données. Scénarios avec des attributs du secteur financier qui nécessitent une cohérence et une fiabilité élevées des données, une disponibilité élevée du système, une évolutivité et une reprise après sinistre Comme nous le savons tous, le secteur financier a des exigences élevées en matière de cohérence et de fiabilité des données, de disponibilité élevée du système, d'évolutivité et de reprise après sinistre. La solution traditionnelle consiste à fournir des services dans deux salles informatiques dans la même ville et à fournir des capacités de récupération des données après sinistre mais aucun service dans une salle informatique dans un autre endroit. Cette solution présente les inconvénients suivants : une faible utilisation des ressources, des coûts de maintenance élevés, . Le RTO (Recovery Time Objective) et le RPO (Recovery Point Objective) ne peuvent pas véritablement atteindre la valeur attendue par l'entreprise. TiDB utilise le protocole multi-copie + Multi-Raft pour planifier les données vers différentes salles informatiques, racks et machines. Lorsque certaines machines tombent en panne, le système peut automatiquement basculer pour garantir que le RTO du système Scénarios OLTP de données massives et à haute concurrence qui nécessitent une capacité de stockage, une évolutivité et une concurrence élevées Avec le développement rapide des entreprises, les données ont connu une croissance explosive et les bases de données autonomes traditionnelles ne peuvent pas répondre aux exigences exigences En raison de la croissance explosive des données qui nécessitent une capacité de base de données, les solutions réalisables consistent à utiliser des produits middleware avec des sous-bases de données et des sous-tables, ou à utiliser la base de données NewSQL à la place, ou à utiliser des périphériques de stockage haut de gamme. Parmi eux, la plupart. la base de données NewSQL, telle que TiDB, est la plus rentable. TiDB adopte une architecture de séparation de calcul et de stockage, qui peut respectivement étendre et réduire le calcul et le stockage. L'informatique prend en charge un maximum de 512 nœuds, chaque nœud prend en charge un maximum de 1 000 simultanéités et la capacité du cluster prend en charge un maximum de niveau PB. Scénario HTAP en temps réel Avec le développement rapide de la 5G, de l'Internet des objets et de l'intelligence artificielle, les entreprises produiront de plus en plus de données, et leur échelle pourrait atteindre des centaines de To, voire des PB. La solution traditionnelle consiste à traiter les transactions en ligne via une base de données OLTP et à synchroniser les données avec une base de données OLAP pour l'analyse des données via des outils ETL. Cette solution de traitement présente de nombreux problèmes tels que des coûts de stockage élevés et de mauvaises performances en temps réel. TiDB a introduit le moteur de stockage en colonnes TiFlash dans la version 4.0 et l'a combiné avec le moteur de stockage en lignes TiKV pour créer une véritable base de données HTAP. Avec une légère augmentation des coûts de stockage, le traitement des transactions en ligne et l'analyse des données en temps réel peuvent être effectués dans le même système. , ce qui permet d'économiser considérablement les coûts des entreprises. Scénarios d'agrégation de données et de traitement secondaire Actuellement, les données commerciales de la plupart des entreprises sont dispersées dans différents systèmes sans résumé unifié. À mesure que l'activité se développe, le niveau décisionnel de l'entreprise doit comprendre la situation commerciale de l'ensemble de l'entreprise afin de prendre des décisions en temps opportun. il est nécessaire de disperser les données. Les données des différents systèmes sont rassemblées dans le même système et traitées deux fois pour générer des rapports T+0 ou T+1. La solution courante traditionnelle consiste à utiliser ETL + Hadoop, mais le système Hadoop est trop complexe et les coûts d'exploitation, de maintenance et de stockage sont trop élevés pour répondre aux besoins des utilisateurs. Par rapport à Hadoop, TiDB est beaucoup plus simple. L'entreprise synchronise les données avec TiDB via des outils ETL ou des outils de synchronisation TiDB peuvent être directement générés dans TiDB via SQL. TiDB est un système distribué. Le cluster de test TiDB le plus basique se compose généralement de 2 instances TiDB, 3 instances TiKV, 3 instances PD et des instances TiFlash facultatives. Grâce à step1、下载并安装 TiUP。 安装完成后显示： step2、声明全局环境变量。
Cinq fonctionnalités principales
Quatre scénarios d'application principaux
2. Commencez rapidement
TiUP Playground, vous pouvez rapidement créer le cluster de test de base ci-dessus. Les étapes sont les suivantes : 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
étape 2. Déclarez les variables d'environnement globales. 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 ……
rrreee
En termes de conception de base, la base de données distribuée TiDB divise l'architecture globale en plusieurs modules, avec lesquels les modules communiquent. les uns les autres pour former un système TiDB complet. Le diagramme d'architecture correspondant est le suivant :
1. Stockage de la base de données TiDB - Serveur TiKV
Modèle de stockage TiDB, un moteur KV distribué avec transactions【
Un moteur clé-valeur distribué globalement ordonné
TiKV
La sauvegarde des données nécessite de s'assurer que : les données ne sont pas perdues et les données sont bonnes → Protocole Raft. De plus, les problèmes suivants doivent être pris en compte :
1. Peut-il prendre en charge la reprise après sinistre entre centres de données ? 🎜 2. La vitesse d'écriture est-elle suffisamment rapide ? 🎜 3. Une fois les données enregistrées, sont-elles faciles à lire ? 🎜 4. Comment modifier les données enregistrées ? Comment prendre en charge les modifications simultanées ? 🎜 5. Comment modifier plusieurs enregistrements de manière atomique ? 🎜🎜Le projet TiKV résout très bien les problèmes ci-dessus. Alors 🎜Comment implémenter une énorme carte (distribuée) avec de hautes performances et une haute fiabilité comme TiKV ? 🎜🎜TiKV utilise Raft pour la réplication des données. Chaque modification de données sera enregistrée sous forme de journal Raft. Grâce à la fonction de réplication des journaux de Raft, les données peuvent être synchronisées avec la plupart des nœuds du groupe de manière sûre et fiable. .
TiKV ne choisit pas d'écrire les données directement sur le disque, mais enregistre les données dans RocksDB. RocksDB est responsable de l'implémentation spécifique des données. [RocksDB est un très excellent moteur de stockage autonome open source. 】
En utilisant l'algorithme de consensus Raft, les données sont copiées en plusieurs copies entre chaque nœud TiKV pour garantir la sécurité des données en cas de panne d'un nœud.
En fait, sous le capot, TiKV utilise un modèle de journal de réplication + machine à états (State Machine) pour répliquer les données. Pour les demandes d'écriture, les données sont écrites sur le Leader, qui copie ensuite la commande vers ses Followers sous la forme d'un journal. Lorsqu'une majorité des nœuds du cluster reçoivent ce journal, le journal est validé et la machine à états change en conséquence.
Pour un système KV, il existe deux solutions typiques pour distribuer des données sur plusieurs machines : l'une consiste à hacher en fonction de la clé et à sélectionner le nœud de stockage correspondant en fonction de la valeur de hachage ; La première consiste à diviser la plage, et une certaine période de clés consécutives est stockée sur un nœud de stockage. Afin de prendre en charge les requêtes de plage, TiKV a choisi la deuxième méthode, divise l'ensemble de l'espace clé-valeur en plusieurs segments. Chaque segment est une série de clés consécutives. Nous appelons chaque segment une Région, et nous le ferons. faisons de notre mieux pour conserver les données enregistrées dans chaque région à une certaine taille ne dépassant pas une certaine taille (cette taille peut être configurée, actuellement la valeur par défaut est de 96 Mo). Chaque région peut être décrite par un intervalle fermé à gauche et ouvert à droite de StartKey à EndKey.
Après avoir divisé les données en régions, nous ferons Deux choses importantes :
Distribuer les données sur tous les nœuds du cluster en unités de région et essayer de nous assurer que chaque nœud Le nombre de régions servi est à peu près le même.
Les données sont divisées en plusieurs régions selon la clé, et les données de chaque région ne seront enregistrées que sur un seul nœud. Notre système aura un composant [PD] chargé de répartir les régions aussi uniformément que possible sur tous les nœuds du cluster, de cette manière, d'une part, il réalise une expansion horizontale de la capacité de stockage (après avoir ajouté de nouveaux nœuds, d'autres nœuds). sera automatiquement ajouté). La région sur le nœud est planifiée), et d'un autre côté, l'équilibrage de charge est également réalisé (il n'y aura pas de situation où un certain nœud a beaucoup de données et d'autres nœuds ont peu de données). Dans le même temps, afin de garantir que le client de couche supérieure puisse accéder aux données requises, le composant [PD] du système enregistrera également la répartition de la région sur le nœud, c'est-à-dire que vous pouvez utiliser n'importe quelle clé. requêtez dans quelle région se trouve la clé et sur quel nœud se trouve actuellement la région.
Faites la réplication Raft et la gestion des membres dans les unités régionales.TiKV réplique les données en unités de région, c'est-à-dire que les données d'une région enregistreront plusieurs copies, et chaque copie est appelée une réplique. Replica utilise Raft pour maintenir la cohérence des données (enfin mentionné Raft). Plusieurs répliques dans une région seront stockées sur différents nœuds pour former un groupe Raft. Une réplique servira de leader de ce groupe et l'autre réplique servira de suiveurs. Toutes les lectures et écritures sont effectuées via le leader, qui sont ensuite copiées sur le suiveur. Après avoir compris la région, vous devriez être capable de comprendre l'image suivante :
En utilisant la région comme une unité pour disperser et répliquer les données, vous disposerez d'un système KeyValue distribué avec certaines capacités de tolérance aux catastrophes. Vous n'aurez plus à vous soucier de la perte de données ou d'une panne de disque entraînant une perte de données.
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引擎架构】列出了重要的模块以及调用关系：
Bref processus de retour de requête SQL : la requête SQL de l'utilisateur sera envoyée au serveur tidb directement ou via Load Balancer. Le serveur tidb analysera le paquet de protocole MySQL, obtiendra le contenu de la requête, puis effectuera une analyse syntaxique et un plan de requête. formulation et optimisation, Exécuter des plans de requêtes pour obtenir et traiter les données. Toutes les données sont stockées dans le cluster TiKV, donc dans ce processus, le serveur tidb doit interagir avec le serveur tikv pour obtenir des données. Enfin, tidb-server doit renvoyer les résultats de la requête à l'utilisateur.
Dans TiDB, le processus depuis le texte de requête d'entrée jusqu'au résultat final de l'exécution du plan d'exécution peut être vu dans la figure ci-dessous :
Tout d'abord, l'analyseur analyse le texte de requête d'origine et certains simple Après vérification de la légalité, TiDB apportera d'abord des modifications logiquement équivalentes à la requête - Optimisation de la logique de requête.
Grâce à ces changements équivalents, cette requête peut devenir plus facile à gérer dans le plan d'exécution logique. Une fois le changement équivalent terminé, TiDB obtiendra une structure de plan de requête équivalente à la requête d'origine, puis obtiendra un plan d'exécution final basé sur la distribution des données et le coût d'exécution spécifique d'un opérateur - Optimisation physique de la requête.
Dans le même temps, lorsque TiDB exécute l'instruction PREPARE, vous pouvez choisir d'activer la mise en cache pour réduire la surcharge de TiDB générant des plans d'exécution - Mise en cache du plan d'exécution.
PD (Placement Driver) est le module de gestion du cluster TiDB et est également responsable de la planification en temps réel des données du cluster.
Serveur PD (Placement Driver) : Le module de gestion des méta-informations de l'ensemble du cluster TiDB, responsable du stockage de la distribution des données en temps réel de chaque nœud TiKV et de la topologie globale du cluster, et fournir une interface de gestion et de contrôle du tableau de bord TiDB et attribuer des ID de transaction aux transactions distribuées. PD stocke non seulement des méta-informations, mais émet également des commandes de planification de données à des nœuds TiKV spécifiques en fonction de l'état de distribution des données signalé en temps réel par les nœuds TiKV. On peut dire qu'il s'agit du « cerveau » de l'ensemble du cluster. De plus, le PD lui-même est composé d'au moins 3 nœuds pour assurer une haute disponibilité. Il est recommandé de déployer un nombre impair de nœuds PD.
Catégorie 1 : En tant que système de stockage distribué à haute disponibilité, les exigences à respecter incluent plusieurs types : [Fonction de récupération après sinistre]
Catégorie 2 : En tant que bon système distribué, les éléments à prendre en compte incluent : [Utilisation des ressources plus élevée et raisonnable, bonne évolutivité]
Afin de répondre à ces besoins, des informations suffisantes doivent être collectées, telles que le statut de chaque nœud, les informations de chaque groupe Raft, les statistiques des opérations d'accès aux entreprises, etc. Deuxièmement, certaines politiques doivent être définies. utilise ces informations et ces stratégies de planification pour élaborer un plan de planification qui répond autant que possible aux besoins énoncés précédemment.
Les opérations de base de planification font référence à la stratégie pour satisfaire la planification. Les exigences de planification ci-dessus peuvent être organisées selon les trois opérations suivantes :
Il arrive que le protocole Raft passe AddReplica、RemoveReplica、TransferLeader Ces trois commandes A peuvent prendre en charge les trois opérations de base ci-dessus.
Le statut de TiKV Store est spécifiquement divisé en Up, Disconnect, Offline, Down et Tombstone. La relation entre chaque statut est la suivante :
PD collecte en permanence des informations via le magasin [c'est-à-dire le nœud TiKV] ou le paquet de battements de cœur du leader pour obtenir des données détaillées sur l'ensemble du cluster et génère une séquence d'opérations de planification basée sur ces informations et la planification. politique, à chaque fois qu'il reçoit le paquet de battements de cœur du chef de région, le PD vérifiera s'il y a des opérations à effectuer sur la région, renverra les opérations requises au chef de région via le message de réponse du paquet de battements de cœur et surveillera le exécution dans le résultat des paquets de battements de cœur suivants. Notez que les opérations ici ne sont que des suggestions pour le chef de région, et il n'y a aucune garantie qu'elles seront exécutées. Le fait et le moment où elles seront exécutées sont déterminés par le chef de région lui-même en fonction de son statut actuel.
Les meilleures pratiques de TiDB sont étroitement liées à ses principes de mise en œuvre. Il est recommandé de comprendre d'abord certains mécanismes de mise en œuvre de base, notamment Raft, les transactions distribuées, le partage de données, l'équilibrage de charge, SQL vers KV. schéma de mappage, méthode de mise en œuvre d'index secondaire, moteur d'exécution distribué.
Raft est un protocole de cohérence qui peut fournir une forte garantie de réplication des données de cohérence. La couche inférieure de TiDB utilise Raft pour synchroniser les données. Chaque écriture doit être écrite sur une majorité de copies avant que le succès puisse être renvoyé au monde extérieur. De cette façon, même si quelques copies sont perdues, les données les plus récentes peuvent être garanties dans le système. Par exemple, s'il y a un maximum de 3 copies, chaque écriture sur 2 copies sera considérée comme réussie. À tout moment, si une seule copie est perdue, au moins une des deux copies survivantes disposera des données les plus récentes.
Par rapport à la méthode de synchronisation Maître-Esclave, qui enregistre également trois copies, la méthode Raft est plus efficace car le délai d'écriture dépend des deux copies les plus rapides et non de la plus lente. Par conséquent, lors de l’utilisation de la synchronisation Raft, il est possible de vivre à plusieurs endroits. Dans un scénario typique de trois centres à deux endroits, chaque écriture nécessite uniquement des écritures réussies dans le centre de données local et dans un centre de données à proximité pour garantir la cohérence des données, et ne nécessite pas d'écritures réussies dans les trois centres de données.
TiDB fournit des transactions distribuées complètes. Le modèle de transaction est optimisé sur la base de Google Percolator.
Optimistic Lock
Le modèle de transaction optimiste de TiDB n'effectuera la détection des conflits que lorsqu'il est réellement soumis. S'il y a un conflit, vous devez réessayer. Ce modèle sera relativement inefficace dans les scénarios comportant des conflits graves, car les opérations avant nouvelle tentative ne sont pas valides et doivent être répétées. Pour donner un exemple plus extrême, utilisez la base de données comme compteur Si la concurrence d'accès est relativement élevée, de graves conflits se produiront, entraînant un grand nombre de tentatives, voire des délais d'attente. Mais si le conflit d’accès n’est pas très grave, alors le modèle de verrouillage optimiste est plus efficace. Dans les scénarios comportant des conflits graves, il est recommandé d'utiliser des verrous pessimistes ou de résoudre le problème au niveau de l'architecture du système, par exemple en plaçant des compteurs dans Redis.
Verrouillage pessimiste
Mode de transaction pessimiste de TiDB Le comportement des transactions pessimistes est fondamentalement le même que celui de MySQL. Il sera verrouillé pendant la phase d'exécution selon le principe du premier arrivé, premier servi pour éviter les tentatives en cas de conflit. assurer plus de conflits taux de réussite de la transaction. Le verrouillage pessimiste résout également le scénario dans lequel vous souhaitez verrouiller les données à l'avance via sélectionner pour mise à jour. Mais si le scénario commercial lui-même comporte moins de conflits, les performances du verrouillage optimiste seront plus avantageuses. select for update 对数据提前锁定的场景。但如果业务场景本身冲突较少，乐观锁的性能会更有优势。
事务大小限制
由于分布式事务要做两阶段提交，并且底层还需要做 Raft 复制，如果一个事务非常大，会使得提交过程非常慢，并且会卡住下面的 Raft 复制流程。为了避免系统出现被卡住的情况，我们对事务的大小做了限制【单个事务包含的 SQL 语句不超过 5000 条（默认）】。
TiKV 自动将底层数据按照 Key 的 Range 进行分片。每个 Region 是一个 Key 的范围，从 StartKey 到 EndKey
StartKey à EndKey. Si le nombre total de valeurs-clés dans une région dépasse une certaine valeur, elle sera automatiquement divisée. Cette partie est transparente pour l'utilisateur. TableID et l'ID de ligne est le suffixe TableID 构造前缀，以行 ID 为后缀TableID+IndexID
TableID+IndexID , en construisant le suffixe Concurrence de requête.
Les données sont dispersées dans de nombreuses régions, donc TiDB effectuera des requêtes simultanément. La concurrence par défaut est relativement conservatrice, car une concurrence trop élevée consommera beaucoup de ressources système.
Pour les requêtes de type OLTP, qui n'impliquent souvent pas une grande quantité de données, une faible concurrence peut déjà répondre aux besoins.
Pour plus de connaissances sur la programmation, veuillez visiter : Vidéo de programmation
! ! 🎜Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
Utilisation du mot-clé Type dans Go
Comment implémenter une liste chaînée en go
Que sont les logiciels de programmation en langage Go ?
Comment apprendre le langage go à partir de 0 bases
Comment définir des variables dans Golang
Quelles sont les méthodes pour implémenter la surcharge d'opérateurs en langage Go ?
Quels sont les opérateurs en langage Go ?
Quelles sont les méthodes de conversion de données dans Golang ?
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
