TiDB : base SQL distribuée pour charges d'agents IA

Contexte

Un problème ancien se cache derrière TiDB : la croissance d'une activité est difficile à prévoir. Le trafic double, et une instance MySQL mono-nœud est la première à céder. Les équipes découpent alors leurs bases à la main ou écrivent une logique de routage dans l'application. Plus tard, les rapports exigent une base analytique et les recommandations une base vectorielle. Les données circulent entre plusieurs systèmes, et chacun devient un silo.

PingCAP développe TiDB en Go et le décrit comme une base SQL distribuée, cloud-native et open source. Ses objectifs affichés sont la haute disponibilité, la montée en charge horizontale et verticale, la cohérence forte et la performance. Le « Ti » du nom vient du titane, choisi pour sa solidité et sa légèreté. Le dépôt compte environ 40 000 étoiles, signe d'un intérêt réel dans la communauté des bases de données open source.

Le positionnement le plus récent met l'accent sur les charges de travail d'agents IA. Ces charges croissent de façon imprévisible, mais exigent tout de même des garanties ACID, ainsi que transactions, analytique et recherche vectorielle réunies. TiDB se présente donc comme un socle unique pour ces trois besoins. Il ne se veut ni un simple remplaçant de MySQL, ni un moteur analytique à usage unique.

Analyse approfondie

La conception repose sur quatre axes nets. Le premier est la transaction distribuée. TiDB s'appuie sur le commit en deux phases pour offrir des garanties ACID. Une transaction peut couvrir plusieurs nœuds, et les données doivent rester correctes malgré une partition réseau ou la panne d'un nœud. Le deuxième axe est la haute disponibilité. Le protocole de consensus Raft est intégré, et chaque donnée existe en plusieurs réplicas. Une transaction n'est validée qu'une fois l'écriture présente sur la majorité des réplicas. Si certains réplicas tombent, le système conserve une cohérence forte et reste disponible. L'emplacement géographique des réplicas se configure aussi, ce qui permet d'ajuster le niveau de reprise après sinistre.

Le troisième axe est l'élasticité. TiDB sépare le calcul du stockage, et chacun s'ajuste seul. Ajouter des nœuds ou augmenter les ressources d'un nœud ne demande aucun arrêt. Face à un intergiciel de sharding, la base prend elle-même en charge le découpage, l'ordonnancement et la cohérence. L'application n'a plus besoin de connaître les règles de partition. Le quatrième axe est le HTAP, c'est-à-dire le traitement transactionnel et analytique hybride. TiDB propose deux moteurs : TiKV pour le stockage en lignes et TiFlash pour le stockage en colonnes. TiFlash copie les données de TiKV en temps réel grâce au protocole Multi-Raft Learner, ce qui garde les deux côtés cohérents. Le serveur TiDB coordonne ensuite chaque requête et choisit le moteur le mieux adapté. Les requêtes analytiques n'ont plus besoin d'un pipeline de synchronisation hors ligne : une copie des données et un système à maintenir disparaissent.

Impact sur l'industrie

Côté adoption, TiDB garde une barrière d'entrée modeste. Il reste compatible avec MySQL 8.0, si bien que les équipes conservent protocoles, frameworks et outils familiers. Une migration peut se faire sans modifier le code, ou avec peu de retouches. Cela compte pour les équipes qui possèdent un grand parc MySQL, car le vrai coût de migration se loge souvent dans les pilotes, les ORM et les scripts d'exploitation plutôt que dans la base elle-même.

Les options de déploiement sont larges : cloud public, centres de données sur site, ou exécution native sur Kubernetes. TiDB Operator automatise l'exploitation des clusters sur Kubernetes. Les équipes qui veulent moins de travail peuvent choisir TiDB Cloud, service entièrement géré, et créer un cluster en quelques clics. Le README fournit un démarrage rapide, une présentation de l'architecture, un guide de contribution et des canaux d'assistance.

Pour les développeurs d'agents, la source suggère un schéma type : garder la mémoire de session, l'état métier et les données vectorielles dans la même base SQL. Les transactions assurent la cohérence, et un seul modèle de droits et une seule politique de sauvegarde gouvernent le tout. On évite ainsi un stockage distinct pour chaque type de donnée. Moins de systèmes signifie moins de transferts et moins de problèmes de cohérence. Les mots-clés du projet incluent agent-memory et agent-context, ce qui montre que PingCAP vise délibérément le rôle de couche de données pour agents.

Perspectives

Les risques sont clairs. Un système distribué est plus complexe qu'une base mono-nœud. Le commit en deux phases et la réplication multiple ajoutent de la latence. Le réglage des transactions entre nœuds, l'exploitation du cluster et la planification de capacité demandent un effort d'apprentissage à l'équipe.

La compatibilité MySQL ne signifie pas une identité totale. Avant de migrer, les équipes doivent vérifier point par point la documentation officielle de compatibilité. La profondeur réelle de la recherche vectorielle sous charge d'agents reste aussi une question ouverte. La documentation officielle et les propres tests de performance de l'équipe doivent trancher, plus que la description du projet.

Trois pistes méritent d'être suivies. La première est la profondeur de l'association entre recherche vectorielle, transactions et analytique. La deuxième est la maîtrise des coûts de la séparation calcul-stockage dans le cloud. La troisième est la capacité des outils autour de la mémoire d'agents à devenir des pratiques stables. Si c'est le cas, le pari de TiDB, un seul système pour les données métier, l'analytique et la mémoire d'agents, pourrait se révéler solide.