Le tidb est-il le langage de prédilection ?

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.

1. Introduction à TiDB

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,

traitement analytique en ligne.

Hautement compatible avec MySQL 5.7

• TiDB est hautement compatible avec le protocole MySQL 5.7, les fonctions et la syntaxe communes de MySQL 5.7. Bien que TiDB prenne en charge la syntaxe et le protocole MySQL, TiDB est un produit développé de manière totalement indépendante par l'équipe PingCAP et n'est pas développé sur la base de MySQL.
Les outils système (PHPMyAdmin, Navicat, MySQL Workbench, mysqldump, Mydumper, Myloader), les clients, etc. de l'écosystème MySQL 5.7 sont tous applicables à TiDB.

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

• TiDB est très simple à utiliser. Vous pouvez utiliser le cluster TiDB comme MySQL. Vous pouvez utiliser TiDB dans n'importe quelle application qui utilise MySQL comme service de stockage backend, et fondamentalement, aucune modification n'est requise. . Appliquez le code et vous pourrez utiliser les outils de gestion MySQL les plus populaires pour gérer TiDB.

Tant que le langage de programmation prend en charge le client/pilote MySQL, vous pouvez utiliser TiDB directement

.

Prend en charge les transactions distribuées

• Qu'il s'agisse de quelques nœuds au même endroit ou de plusieurs nœuds dans plusieurs centres de données, TiDB prend en charge les transactions distribuées ACID
.

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énarios

• Prend en charge la haute disponibilité par défaut Lorsque quelques copies échouent, la base de données elle-même peut effectuer automatiquement la réparation et le basculement des données, ce qui est transparent pour l'entreprise
• . Les transactions ACID de prise en charge sont adaptées à certains scénarios avec de fortes exigences de cohérence, tels que les virements bancaires.
• Il dispose d'un riche écosystème de chaîne d'outils, couvrant la migration des données, la synchronisation, la sauvegarde et d'autres scénarios
• Pour faire simple, TiDB convient au Scènes suivantes avec ces caractéristiques

 :

• La quantité de données est trop importante pour être enregistrée sur une seule machine
• Je ne veux pas faire du Sharding ou je suis trop paresseux pour faire du Sharding
• Il n'y a pas de points chauds évidents dans le modèle d'accès
• Des transactions nécessaires , une forte cohérence et une reprise après sinistre
• J'espère que le HTAP en temps réel pourra réduire le lien de stockage

Cinq fonctionnalités principales

• Extension 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.

Quatre scénarios d'application principaux

• 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.

2. Commencez rapidement

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 à TiUP Playground, vous pouvez rapidement créer le cluster de test de base ci-dessus. Les étapes sont les suivantes : 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}

étape 1.

source /home/user/.bashrc

Une fois l'installation terminée, il s'affichera :

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。

step3 Exécutez la commande suivante dans la session en cours pour démarrer le cluster.

#简单来说，没有 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
……

étape 4, vérification. [Vous pouvez désormais utiliser TiDB comme MySQL

]

rrreee

• 3. Principe de l'architecture TiDB

  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 :

• Le serveur TiDB est responsable du traitement de la logique liée à SQL, de la conversion des instructions SQL en clés et de l'utilisation de PD pour trouver dans quel TiKV se trouvent les données. TiDB lui-même est apatride, ne stocke pas de données et n'est responsable que des calculs. TiDB est écrit en langage Go. [Recommandations associées :
Tutoriel vidéo Go
• ]
  PD

PD stocke les méta-informations du cluster, telles que le nœud TiKV sur lequel se trouve la clé ; PD est également responsable de l'équilibrage de charge et du partage des données du cluster ; grappe. 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.

TiKV ServerTiKV est un moteur de stockage de valeurs-clés distribué qui fournit des transactions. Il est conçu sur la base de Google Spanner et HBase, mais est séparé du HDFS sous-jacent plus complexe. Stockez les valeurs clé-valeur localement via RocksDB et utilisez le protocole Raft pour la réplication afin de maintenir la cohérence des données et la reprise après sinistre. TiKV est écrit en langage Rust.

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é

】La structure hiérarchique et comment atteindre la tolérance aux pannes multi-copies. Storage NodeTiKV Server

 : Responsable du stockage des données de l'extérieur, TiKV est un moteur de stockage de valeurs-clés distribué qui fournit des transactions. L'unité de base pour le stockage des données est la région. Chaque région est responsable du stockage des données d'une plage de clés (la plage fermée à gauche et ouverte à droite de StartKey à EndKey). Chaque nœud TiKV est responsable de plusieurs régions. L'API de TiKV fournit une prise en charge native des transactions distribuées au niveau de la paire clé-valeur KV et fournit par défaut le niveau d'isolation SI (Snapshot Isolation), qui est également au cœur de la prise en charge par TiDB des transactions distribuées au niveau SQL. Une fois que la couche SQL de TiDB a terminé l'analyse SQL, elle convertira le plan d'exécution SQL en un appel réel à l'API TiKV. Par conséquent, les données sont stockées dans TiKV. De plus, les données de TiKV conservent automatiquement plusieurs copies (trois copies par défaut), prenant naturellement en charge la haute disponibilité et le basculement automatique.

TiFlash : TiFlash est un type spécial de nœud de stockage. Contrairement aux nœuds TiKV ordinaires, dans TiFlash, les données sont stockées sous forme de colonnes et leur fonction principale est d'accélérer les scénarios analytiques.

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 est une énorme carte qui stocke les paires clé-valeur.
• Les paires clé-valeur dans cette carte sont classées selon l'ordre binaire de la clé, c'est-à-dire que nous pouvons rechercher l'emplacement d'une certaine clé, puis appeler en continu la méthode Next pour obtenir des valeurs-clés plus grandes. que cette clé par ordre croissant.

Raft et RocksDB

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.

Concept de région

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

Si deux clients modifient la valeur d'une clé en même temps, sans MVCC, les données doivent être verrouillées dans un scénario distribué, cela peut entraîner des problèmes de performances et de blocage. L'implémentation MVCC de TiKV est implémentée en ajoutant la version après la clé.

对于同一个 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引擎架构】列出了重要的模块以及调用关系：

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.

Processus d'exécution SQL

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.

3. Planification de la base de données TiDB - PD Server

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.

Scénarios de planification

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.

Exigences de planification

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]

• Le nombre de répliques ne peut pas être supérieur ou moins.
• Les répliques doivent être distribuées sur des machines avec des attributs différents selon la topologie.
• La reprise après sinistre peut être effectuée automatiquement, raisonnablement et rapidement en cas d'indisponibilité ou d'anomalie du nœud.

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é]

• Maintenir une répartition uniforme des leaders dans tout le cluster.
• Maintenir une capacité de stockage uniforme de chaque nœud.
• Maintenez une répartition uniforme des points d'accès.
• Contrôlez la vitesse d'équilibrage de charge pour éviter d'affecter les services en ligne.
• Gérez l'état des nœuds, notamment en mettant manuellement les nœuds en ligne/hors ligne.

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.

Opérations de planification

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 :

• Ajouter une copie
• Supprimer une copie
• Transférer (migrer) le rôle Leader entre différentes copies d'un groupe Raft

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 :

Stratégie de planification

• Le nombre de répliques dans une région est correct.
• Plusieurs exemplaires d'un groupe Raft ne se trouvent pas au même endroit.
• Les copies sont réparties uniformément entre les magasins.
• Le nombre de Leaders est réparti équitablement entre les magasins.
• Le nombre de hotspots d'accès est réparti uniformément entre les magasins.
• L'espace de stockage occupé par chaque Store est à peu près égal.
• Contrôlez la vitesse de planification pour éviter d'affecter les services en ligne.

Mise en œuvre de la planification

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.

5. Meilleures pratiques de TiDB

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

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.

Transactions distribué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

Taille limite des transactionsÉtant donné que les transactions distribuées nécessitent une soumission en deux phases et que la couche sous-jacente nécessite également une réplication Raft, si une transaction est très volumineuse, le processus de soumission sera très lent et le processus de réplication Raft sous-jacent sera bloqué . Afin d'éviter que le système ne reste bloqué, nous avons limité la taille des transactions [une seule transaction ne contient pas plus de 5 000 instructions SQL (par défaut)].

Partage de donnéesTiKV fragmente automatiquement les données sous-jacentes en fonction de la plage de la clé. Chaque région est une plage de clés, un intervalle fermé à gauche et ouvert à droite de 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.

🎜🎜Équilibrage de charge🎜🎜🎜PD planifiera la charge du cluster en fonction de l'état de l'ensemble du cluster TiKV. La planification est basée sur la région comme unité, et la politique configurée par PD est utilisée comme logique de planification et est complétée automatiquement. 🎜🎜🎜🎜🎜SQL sur KV🎜🎜🎜TiDB mappe automatiquement les structures SQL aux structures KV. En termes simples, TiDB effectue les opérations suivantes : 🎜

• Une ligne de données est mappée à un KV, la clé est construite avec le préfixe TableID et l'ID de ligne est le suffixe TableID 构造前缀，以行 ID 为后缀
• 一条索引映射为一个 KV，Key 以 TableID+IndexID
Un index est mappé à un KV, la clé est construite avec le préfixe de TableID+IndexID , en construisant le suffixe

avec la valeur de l'index. Vous pouvez voir que les données ou l'index d'une table auront le même préfixe, de sorte que dans l'espace clé TiKV, ces valeurs-clés seront dans des positions adjacentes. Ensuite, lorsque la quantité d'écriture est importante et concentrée sur une table, cela provoquera des points chauds d'écriture, en particulier lorsque certaines valeurs d'index dans les données écrites en continu sont également continues (comme le temps de mise à jour, un champ qui augmente avec le temps). formera des points chauds d'écriture sur quelques régions et deviendra un goulot d'étranglement pour l'ensemble du système. De même, si toutes les opérations de lecture de données sont concentrées sur une petite plage (telle que des dizaines de milliers ou des centaines de milliers de lignes consécutives de données), cela peut provoquer des points chauds d'accès aux données.

Index secondaire

TiDB prend en charge un index secondaire complet et est un index global de nombreuses requêtes peuvent être optimisées via l'index. Si vous faites bon usage des index secondaires, cela est très important pour votre entreprise. De nombreuses expériences sur MySQL sont toujours applicables à TiDB. Cependant, TiDB possède également certaines caractéristiques propres auxquelles vous devez prêter attention. précautions lors de l’utilisation d’index secondaires sur TiDB.

• Plus il y a d'index secondaires, mieux c'est.

• Il est plus approprié de créer des index sur des colonnes avec une discrimination [cardinalité] relativement importante. Lorsqu'il existe plusieurs conditions de requête, vous pouvez choisir un index combiné et faire attention au principe du préfixe le plus à gauche.

• La différence entre l'interrogation via l'index et l'analyse directe de la table.

• 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 les requêtes de type OLAP, un degré de concurrence plus élevé est souvent requis.
  Donc, TiDB prend en charge l'ajustement de la concurrence des requêtes via la variable système. [tidb_distsql_scan_concurrency, tidb_index_lookup_size, tidb_index_lookup_concurrency, tidb_index_serial_scan_concurrency, etc.]

• Garantissez l'ordre des résultats via l'index. [En plus d'être utilisés pour filtrer les données, les index peuvent également être utilisés pour trier les données. Tout d'abord, les ID de ligne sont obtenus dans l'ordre de l'index, puis le contenu des lignes est renvoyé dans l'ordre de retour des ID de ligne. Cela garantit que les résultats renvoyés sont organisés selon la séquence des colonnes d'index. 】

• prend également en charge l'indexation inversée. [La vitesse actuelle est plus lente que l'analyse séquentielle, généralement 20 % plus lente. Lorsque les données sont fréquemment modifiées et qu'il existe de nombreuses versions, elle sera encore plus lente. Si possible, il est recommandé d'éviter l'ordre inverse. Scan de l'index】

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!