SQL distribué : quand utiliser Spanner, CockroachDB et YugabyteDB

Ce que signifie le SQL distribué

Le SQL distribué est une architecture de base de données relationnelle qui répartit les données et le traitement des transactions sur plusieurs machines tout en présentant aux applications une seule base SQL logique. Elle conserve les tables, jointures, index, contraintes et transactions ACID, puis ajoute le partitionnement automatique, la réplication et la reprise après panne.

Un système entre généralement dans cette catégorie lorsqu’il combine les propriétés suivantes :

• Un schéma relationnel et une interface de requêtes SQL
• Une montée en charge horizontale sur les nœuds de base de données
• Une cohérence transactionnelle entre les partitions
• Une réplication et un basculement automatiques
• Un fonctionnement coordonné comme une seule base logique

Cette définition compte, car une base ne devient pas SQL distribué simplement en ajoutant des réplicas de lecture à PostgreSQL ou MySQL. Un primaire avec des réplicas envoie toujours les écritures vers un serveur principal. Le sharding géré par l’application répartit les écritures, mais oblige l’application à décider où vivent les enregistrements et comment se comportent les opérations entre shards. Le SQL distribué transfère une grande partie de cette responsabilité vers la base de données.

Entre un SGBDR classique et NoSQL

Le SQL distribué associe le modèle de programmation relationnel d’un SGBDR classique à la conception extensible des magasins de données distribués. Les déploiements PostgreSQL et MySQL traditionnels fonctionnent bien lorsqu’une instance primaire peut absorber la charge d’écriture et qu’une panne régionale ne demande pas de continuer à écrire ailleurs. Les réplicas de lecture, le cache, le pool de connexions et de meilleurs index peuvent prolonger ce modèle pendant des années.

De nombreuses bases NoSQL ont facilité la distribution en limitant les jointures, les transactions ou les garanties de cohérence. Ces choix restent judicieux pour des charges comme les grands flux d’événements, les caches jetables et les enregistrements qui participent rarement à des transactions sur plusieurs lignes. Un cluster relationnel assume davantage de coordination, car les applications s’attendent à ce que les contraintes et transactions restent valides après la répartition des données entre les nœuds.

La différence concrète tient à la responsabilité de la complexité. Avec le sharding manuel, les équipes applicatives implémentent le routage, rééquilibrent les données, coordonnent les changements de schéma et gèrent les opérations qui touchent plusieurs shards. Avec le SQL distribué, la base fournit ces mécanismes, même si les ingénieurs doivent toujours concevoir les schémas et requêtes pour un système en réseau.

Les problèmes qu’il est conçu pour résoudre

Le SQL distribué vise les applications dont la disponibilité, l’implantation géographique ou la croissance des écritures dépassent une architecture à primaire unique. Parmi les exemples courants : un service SaaS mondial, un système de réservation qui ne peut pas surallouer, ou un grand livre financier dont les invariants doivent résister aux pannes de nœuds.

Il peut supprimer le besoin de sharding au niveau applicatif et réduire la dépendance à un seul emplacement d’écriture. Il peut aussi placer les données près des utilisateurs ou dans des juridictions autorisées. Ces avantages ont un prix : davantage de réplicas, de trafic réseau, de coordination et de modes de panne inexistants sur un serveur unique.

Une base relationnelle gérée classique reste le meilleur choix par défaut lorsque la charge tient confortablement dans une région. Le SQL distribué justifie son coût lorsque le sharding personnalisé, le basculement régional ou les contrôles géographiques des données deviendraient autrement un grand système d’ingénierie à part entière.

Comment fonctionne le SQL distribué en interne

Le SQL distribué divise les données en partitions répliquées et coordonne les changements au moyen de protocoles de consensus et de transactions distribuées. La base masque une grande partie de cette mécanique derrière SQL, mais son fonctionnement façonne toujours la latence, le débit, la conception du schéma et la réponse aux incidents.

Les partitions déterminent où vivent les enregistrements

Un cluster divise ses tables logiques en unités plus petites qui peuvent se déplacer indépendamment entre les nœuds. Spanner appelle couramment ces unités des splits, CockroachDB utilise des ranges et YugabyteDB des tablets. Chaque unité couvre une partie de l’espace de clés d’une table ou d’un index.

Les frontières de partition peuvent suivre des plages, des hachages ou des règles géographiques explicites. Une plage ordonnée par identifiant client facilite l’analyse d’enregistrements liés, mais un identifiant monotone peut concentrer les nouvelles écritures vers une partition. La distribution par hachage répartit mieux les écritures, mais peut compliquer les analyses ordonnées ou le placement par locataire. Beaucoup de schémas de production combinent un identifiant de locataire avec une autre valeur afin de garder les données liées accessibles sans concentrer toutes les écritures au même endroit.

Les index secondaires ont besoin de leur propre stockage distribué. L’écriture d’une ligne peut donc mettre à jour la table de base et plusieurs entrées d’index sur différentes partitions. Un index peu coûteux sur un serveur unique peut créer du travail de consensus et du trafic réseau supplémentaires dans un cluster.

La réplication et le consensus protègent chaque partition

Chaque partition possède normalement plusieurs réplicas, et un groupe de consensus décide de la séquence acceptée des changements. CockroachDB et YugabyteDB s’appuient sur une réplication basée sur Raft. Spanner utilise une réplication basée sur Paxos avec son infrastructure de temps.

Un leader ou détenteur de bail coordonne les écritures d’un groupe de réplicas. Le système enregistre un changement sur suffisamment de réplicas pour former un quorum avant de le considérer comme validé. Si un nœud disparaît, les membres restants peuvent élire ou désigner un autre coordinateur tant qu’un quorum reste disponible.

Le quorum est une exigence mathématique, pas la promesse que toute panne est sans conséquence. Un groupe de trois réplicas peut en général tolérer l’indisponibilité d’un réplica. La perte de deux membres signifie que la copie restante ne peut pas accepter les écritures de façon sûre, car elle ne peut pas prouver qu’une autre majorité n’a pas progressé ailleurs. Le placement entre domaines de panne importe autant que le nombre de réplicas.

Les transactions distribuées coordonnent plusieurs partitions

Une transaction qui ne touche qu’une partition peut souvent se terminer avec peu de coordination. Une transaction impliquant plusieurs partitions nécessite une décision de commit commune afin que tous les participants appliquent leurs écritures ou les abandonnent.

Le protocole exact diffère selon le produit, mais le travail comprend généralement la lecture ou le verrouillage des versions utiles, la validation des changements concurrents, la réplication des intentions ou enregistrements provisoires et la finalisation du commit. Les transactions longues élargissent la fenêtre de conflit. Les grands lots peuvent mobiliser de nombreux groupes de consensus et provoquer des pics de latence, même lorsque chaque instruction paraît simple.

C’est pourquoi la conception de transactions consciente du réseau est importante. Regroupez les lignes liées sous des préfixes de partition compatibles lorsque la base le permet. Gardez les transactions courtes, évitez d’attendre des services externes pendant qu’une transaction est ouverte et ne chargez pas des milliers d’enregistrements sans lien dans une même unité atomique sans mesurer l’effet.

Le temps et l’ordre demandent des mécanismes explicites

Les nœuds distribués ne partagent pas une horloge parfaitement synchronisée. Chaque produit a donc besoin d’un moyen d’ordonner les transactions. Spanner utilise les bornes d’incertitude TrueTime et l’attente de commit pour fournir une cohérence externe. D’autres systèmes peuvent combiner horloges physiques, composants logiques, suivi des dépendances et protocoles transactionnels.

La coordination des horloges affecte l’exécution sérialisable, les lectures sur suiveur et les instantanés. Les applications doivent utiliser les horodatages des transactions de la base au lieu de supposer que des horodatages générés par des serveurs applicatifs distincts établissent un ordre global fiable.

La localité contrôle le chemin réseau

La configuration de localité décide où se trouvent les réplicas et quelle région coordonne les écritures d’un enregistrement. Les lectures peuvent être rapides lorsqu’un réplica adapté se trouve près de l’appelant. Une écriture fortement ordonnée doit toujours atteindre les réplicas nécessaires au quorum, donc sa latence reflète la topologie choisie.

Un bon placement suit la charge plutôt qu’un schéma de l’entreprise. Si la plupart des écritures d’un locataire européen proviennent d’Europe, y placer son coordinateur d’écriture évite un trajet intercontinental au début de chaque transaction. Un enregistrement partagé mondialement, tel qu’un compteur mis à jour par toutes les régions, ne peut pas être local à chaque rédacteur et peut devenir un point de contention.

Quand le SQL distribué est le bon choix

Le SQL distribué est le bon choix lorsque la résilience géographique, la capacité d’écriture horizontale ou la correction entre partitions comptent assez pour justifier les coûts permanents de coordination. Une grande entreprise n’en a pas automatiquement besoin, et un petit produit peut en avoir besoin si sa promesse commerciale inclut une disponibilité régionale stricte.

Les conditions qui justifient une évaluation

Une évaluation sérieuse convient lorsque plusieurs de ces conditions s’appliquent :

• Le service doit continuer à fonctionner malgré la panne d’une zone ou d’une région
• La demande d’écriture approche la limite pratique d’une base primaire unique
• Le sharding manuel absorberait beaucoup de temps d’ingénierie applicative
• Les transactions doivent rester correctes entre nœuds ou emplacements
• Les enregistrements exigent un placement géographique applicable

Ces conditions doivent s’appuyer sur des chiffres. Définissez l’objectif de temps de reprise, l’objectif de point de reprise, la latence des transactions, le débit d’écriture de pointe et les domaines de panne. Une demande vague de montée en charge mondiale ne suffit pas pour choisir une architecture.

Des utilisateurs régionaux ne constituent pas à eux seuls une raison décisive. Une application riche en contenu peut placer ses serveurs web et caches près des utilisateurs tout en gardant une seule région de base de données. Les réplicas de lecture peuvent prendre en charge la consultation régionale si des résultats légèrement anciens sont acceptables. Le cas devient plus solide lorsque des utilisateurs de plusieurs endroits doivent effectuer des écritures à faible latence sur des données liées.

Les conditions qui favorisent une base plus simple

Un service relationnel classique est généralement préférable lorsque le trafic est modéré, que les écritures viennent d’une région et qu’une reprise peut inclure une promotion planifiée de base. Il offre des outils matures, une large compatibilité avec les extensions, un débogage familier et une facture d’infrastructure plus basse.

Des exigences de latence très serrées peuvent aussi favoriser un primaire régional unique. Une écriture durable locale peut se terminer bien plus vite qu’une écriture de quorum traversant des régions éloignées. Les systèmes dominés par l’analytique devraient généralement séparer les transactions opérationnelles des longues analyses au lieu d’attendre d’un même cluster qu’il excelle dans les deux.

La capacité de l’équipe compte. Les services gérés réduisent le travail lié au matériel, aux correctifs et au plan de contrôle, mais ils ne suppriment pas la contention du schéma, les nouvelles tentatives de transaction, la planification des requêtes, la gestion de capacité ni la gestion des incidents côté application. Si l’équipe n’a pas le temps de tester le comportement en cas de panne, adopter une base distribuée peut accroître le risque.

Un seuil de décision fondé sur les alternatives

La justification la plus forte apparaît lorsque l’alternative est déjà complexe. Si les ingénieurs s’apprêtent à créer le routage des locataires, des cartes de shards, des règles de transaction entre shards, des procédures de promotion régionale et des outils de migration séparés, une base qui fournit ces fonctions mérite une évaluation attentive.

Si l’alternative est une instance PostgreSQL gérée avec un réplica de lecture et des sauvegardes testées, la migration exige des preuves claires. Évaluez d’abord le système existant. La saturation CPU peut venir d’une requête inefficace, d’une mauvaise gestion des connexions, d’un excès d’index ou d’un cache manquant, plutôt que d’un besoin d’écritures horizontales.

Cohérence, disponibilité et latence

Le SQL distribué préserve généralement la cohérence transactionnelle pendant les pannes en refusant les opérations qui ne peuvent pas joindre le quorum requis. Ce comportement protège l’état validé, mais certaines requêtes peuvent échouer ou attendre pendant une partition réseau.

CAP décrit le comportement en cas de panne

Le théorème CAP s’applique lorsque la communication entre les parties du cluster est interrompue. Pour les données concernées, un système ne peut pas garantir à la fois une cohérence linéarisable et des réponses réussies de chaque côté isolé. Une base orientée cohérence permet au côté disposant du quorum de continuer et refuse les écritures dangereuses ailleurs.

CAP n’explique pas la latence en fonctionnement normal. Même lorsque chaque liaison fonctionne, les réplicas doivent communiquer. La décision d’ingénierie comprend ce qui se produit pendant une partition et le degré de coordination que l’application accepte en situation saine.

Une application doit traiter explicitement les résultats indisponibles. Les délais d’attente, erreurs de transaction réessayables et pertes temporaires d’une région d’écriture sont des possibilités normales. Renvoyer un succès depuis les deux régions isolées serait pire pour un solde ou une réservation, car la réconciliation risquerait de ne pas avoir de réponse automatique valide.

Les lectures fortes et les lectures volontairement anciennes diffèrent

Une lecture forte observe un état de base cohérent avec la garantie d’ordre demandée. Certains produits proposent aussi des lectures sur suiveur ou à ancienneté bornée qui échangent de la fraîcheur contre une latence plus basse et moins de travail sur le coordinateur d’écriture.

Ce choix doit suivre le champ lu. Une description de produit peut souvent tolérer un réplica légèrement ancien. Un mot de passe récemment modifié, un solde courant ou le stock restant doivent emprunter un chemin fort ou cohérent avec la session. Les applications ne devraient pas marquer toutes les lectures comme anciennes pour gagner en vitesse, puis reconstruire la correction dans le code de service.

Le comportement lecture après écriture doit être testé avec le pilote et la couche de routage réels. Après une mise à jour, la requête suivante peut atteindre un autre serveur applicatif ou point de terminaison de base. Des jetons de session, des frontières de transaction ou un réglage de lecture forte peuvent être nécessaires pour garantir que l’utilisateur voit le changement accepté.

L’isolation contrôle les résultats concurrents

L’isolation des transactions détermine quelles anomalies peuvent produire des transactions concurrentes. L’isolation sérialisable vise à faire paraître les transactions terminées comme si elles s’étaient exécutées une à une, même lorsque la base les exécute simultanément.

L’exécution sérialisable peut annuler un participant lorsque des opérations concurrentes ne peuvent pas être ordonnées sans risque. Cette annulation protège contre un mauvais résultat, elle ne signale pas une corruption de la base. Les applications ont besoin de nouvelles tentatives bornées autour de toute la transaction, y compris de chaque lecture qui a influencé ses écritures.

Les nouvelles tentatives doivent être idempotentes hors de la base. Si le code envoie un e-mail ou appelle un prestataire de paiement avant que la transaction soit certainement validée, une nouvelle tentative peut répéter l’effet de bord. Enregistrez un événement de boîte d’envoi dans la transaction, validez-la, puis laissez un worker distinct exécuter l’action externe.

La distance fixe un plancher de latence d’écriture

Une transaction multirégion ne peut pas se terminer plus vite que les messages exigés par son protocole. Un aller-retour de 80 millisecondes entre membres du quorum ajoute un délai réel avant même de compter l’exécution des requêtes, la maintenance des index, le travail applicatif et l’attente en file.

Le modèle coûteux est souvent une succession de transactions dans une action utilisateur. Si le paiement effectue une insertion de commande, une réservation de stock, une mise à jour de l’état du paiement et une écriture d’audit dans quatre commits bloquants, le coût réseau s’accumule. Regrouper les changements de base qui partagent un résultat atomique peut supprimer des allers-retours inutiles, tandis que les appels de paiement externes doivent rester hors d’une transaction ouverte.

Mesurez la latence par percentile plutôt qu’en moyenne. Les changements de leadership, la contention, les blocages de stockage et les nouvelles tentatives apparaissent dans la queue de distribution. Une conception qui atteint son objectif médian mais manque le 99e percentile lors d’un rééquilibrage ordinaire peut toujours provoquer des échecs visibles par les utilisateurs.

Comparaison entre Spanner, CockroachDB et YugabyteDB

Spanner, CockroachDB et YugabyteDB résolvent des problèmes de distribution semblables, mais diffèrent par leur modèle de déploiement, leur compatibilité, leur implémentation transactionnelle et leurs hypothèses d’exploitation. Le choix exige de tester le comportement de l’application plutôt que de se baser sur l’étiquette SQL commune.

Spanner s’inscrit dans une stratégie Google Cloud gérée

Spanner convient aux organisations prêtes à utiliser une base Google Cloud gérée et à concevoir autour de son dialecte, de sa topologie et de son modèle d’exploitation. TrueTime prend en charge les transactions à cohérence externe, ce qui signifie que les transactions validées respectent l’ordre réel dans les limites de la sémantique documentée.

Son dialecte PostgreSQL peut réduire les différences de syntaxe SQL, mais un dialecte n’équivaut pas complètement à PostgreSQL. Les extensions, fonctions administratives, catalogues système, types de données, pilotes et hypothèses d’ORM exigent toujours une vérification. Les équipes doivent inventorier chaque dépendance de base avant de considérer une application existante comme portable.

Spanner mérite une attention particulière lorsque le système voulu dépend déjà de l’identité, du réseau, de l’observabilité et des contrôles régionaux de Google Cloud. Le modèle géré élimine l’administration des nœuds de base, mais la conception du schéma, l’optimisation des requêtes, les quotas, la gestion des coûts et la reprise applicative restent à la charge du client.

CockroachDB convient aux applications distribuées orientées PostgreSQL

CockroachDB convient aux équipes qui veulent un accès applicatif de style PostgreSQL tout en répartissant les données transactionnelles sur des ranges. Il utilise par défaut l’isolation sérialisable. Les applications doivent donc réessayer correctement les transactions rejetées à cause de la contention ou de conflits d’ordonnancement.

La compatibilité doit être testée aux niveaux de la migration, du pilote et de l’ORM. Des extensions PostgreSQL et comportements spécialisés peuvent être absents ou différents. Les requêtes qui reposent sur des plans d’exécution à un nœud peuvent aussi se comporter différemment lorsque tables et index sont divisés entre plusieurs ranges.

Le déplacement des ranges et le rééquilibrage automatique simplifient les changements de capacité, mais un mauvais choix de clé primaire peut toujours créer des ranges très sollicités. Les abstractions multirégion aident à exprimer la localité des tables, mais les développeurs doivent décider quels enregistrements sont régionaux, lesquels sont mondiaux et où les écritures doivent être coordonnées.

YugabyteDB convient aux besoins YSQL et API mixtes

YugabyteDB convient aux applications qui apprécient une interface relationnelle compatible PostgreSQL et peuvent tirer parti de son API séparée compatible Cassandra. YSQL fournit les tables relationnelles et transactions distribuées, tandis que YCQL suit un modèle de données différent. Il ne faut pas le considérer comme une autre voie vers chaque opération YSQL.

Sa couche de stockage répartit les données via des tablets. La conception des tables, le découpage des tablets, le placement des index et la portée des transactions influencent la distribution du travail dans le cluster. Les applications PostgreSQL doivent toujours tester la compatibilité des extensions, fonctions, outils et comportements du planificateur.

La disponibilité de plusieurs approches de déploiement peut convenir aux politiques d’infrastructure qui exigent de contrôler le placement. En auto-gestion, ce contrôle transfère la responsabilité opérationnelle au client : mises à niveau, procédures de réparation, capacité, observabilité, certificats, sauvegardes et tests de panne ont tous besoin d’un responsable.

Un test produit utile s’appuie sur l’application

Une comparaison utile exécute la même charge représentative sur chaque produit viable. Testez la création du schéma, les migrations, le SQL généré par l’ORM, les nouvelles tentatives de transaction, la restauration de sauvegardes, le basculement, les événements de montée en charge et les requêtes à plus fort volume.

Ne comparez pas seulement le maximum de transactions par seconde. Relevez la latence p50, p95 et p99, les taux de conflit et de nouvelle tentative, les octets transférés entre régions, l’amplification du stockage, le temps de restauration et l’effort de l’opérateur lors d’un incident simulé. Le meilleur choix est celui qui atteint les objectifs de correction et de reprise avec un coût et une charge opérationnelle acceptables.

SaaS mondial avec des utilisateurs régionaux

Une application SaaS mondiale tire parti du SQL distribué lorsque les locataires ont besoin d’un placement régional des données et d’un accès transactionnel sans piles de bases distinctes pour chaque zone géographique. La conception fonctionne au mieux lorsque la mutualisation est explicite dans le schéma et que la plupart des transactions restent au sein d’un locataire.

La localité des locataires doit suivre les contrats et le trafic

Un identifiant de locataire peut piloter le placement afin que les enregistrements européens restent dans des emplacements européens approuvés tandis que les données d’un autre client restent dans le pays ou la région prévue par son contrat. Cela conserve un schéma logique unique tout en autorisant différentes politiques physiques.

Les règles de placement doivent couvrir davantage que la table de base. Les entrées d’index, flux de changements, données temporaires, sauvegardes et enregistrements exportés peuvent contenir des informations réglementées. Une politique qui épingle les lignes mais envoie un index secondaire mondial ailleurs peut violer la limite prévue.

L’isolation des locataires affecte aussi les performances. Un grand locataire peut saturer une partition partagée ou dominer un nœud. Il peut être nécessaire de hacher ou sous-partitionner ce locataire, tout en préservant un accès efficace aux transactions limitées au locataire.

Les lectures régionales ont besoin d’une politique de fraîcheur explicite

Les tableaux de bord dominés par la lecture peuvent utiliser des réplicas proches lorsque des données légèrement retardées sont acceptables. Les changements de compte, décisions d’autorisation et écrans de confirmation après transaction demandent un comportement plus fort. Classez les chemins de requête selon l’exigence de fraîcheur au lieu d’adopter un réglage global unique.

Le placement des écritures doit suivre le rédacteur habituel de chaque locataire. Si le personnel d’un client travaille principalement à Singapour, coordonner ses écritures sur un autre continent crée une latence évitable. Une procédure de migration de locataire doit mettre à jour le placement sans perdre d’écritures, enfreindre les règles de résidence ni laisser les caches applicatifs pointer vers d’anciens emplacements.

Le code applicatif mondial doit tolérer les déplacements

Les leaders se déplacent, les nœuds redémarrent et le routage change pendant la maintenance. Les pilotes doivent avoir des délais d’attente raisonnables, des politiques de nouvelle tentative, un renouvellement des connexions et une logique de redémarrage des transactions. Les nouvelles tentatives doivent utiliser un délai aléatoire et une limite afin qu’un cluster surchargé ne reçoive pas immédiatement une vague synchronisée de requêtes répétées.

La surveillance doit distinguer la latence utilisateur par région et par classe de locataire. Une moyenne mondiale peut cacher un groupe de clients lointains qui paie plusieurs trajets réseau supplémentaires. Des identifiants de trace reliant les segments API aux instructions de base facilitent la découverte des erreurs de localité.

Flux financiers et grands livres

Les flux financiers tirent profit d’une base lorsque les contraintes et transactions imposent les invariants du grand livre malgré les pannes et requêtes concurrentes. La distribution ne crée pas à elle seule une comptabilité correcte. Le schéma doit encoder les règles qui ne peuvent pas être enfreintes.

Un grand livre doit conserver une suite d’écritures vérifiable

Un grand livre orienté ajout enregistre chaque mouvement sous forme d’écritures au lieu de remplacer sans cesse une valeur de solde sans historique. Chaque comptabilisation doit avoir un identifiant de transaction stable, des comptes, des montants, une devise, un horodatage métier et des métadonnées de création. Les règles de partie double doivent être vérifiées avant le commit afin que les débits et crédits s’équilibrent pour l’unité de comptabilisation.

Un solde mis en cache peut accélérer les lectures, mais il doit changer dans la même transaction que les écritures ou être clairement traité comme une donnée dérivée. Les tâches de rapprochement doivent comparer les totaux dérivés aux écritures sources et signaler les écarts sans réécrire silencieusement l’historique.

Un ordre mondial est rarement nécessaire pour chaque compte. Les transactions qui touchent un compte ou une paire de transfert ont besoin d’un ordre cohérent, tandis que les comptes sans lien peuvent progresser en parallèle. Concevoir autour de cette frontière réduit la contention par rapport à une séquence mondiale ou une ligne de règlement unique.

L’idempotence rend les nouvelles tentatives sûres

Les API de paiement, files d’attente et webhooks réessaient après des délais d’attente. Chaque opération métier a donc besoin d’une clé d’idempotence stable. Imposer l’unicité dans le bon périmètre, tel qu’un commerçant ou compte, puis créer l’enregistrement de paiement et les écritures de grand livre dans une transaction de base.

CREATE TABLE payment_attempts (
    account_id UUID NOT NULL,
    idempotency_key TEXT NOT NULL,
    provider_reference TEXT,
    status TEXT NOT NULL,
    created_at TIMESTAMPTZ NOT NULL,
    PRIMARY KEY (account_id, idempotency_key)
);

Si deux workers soumettent la même opération, la contrainte unique décide quelle insertion réussit. Le worker perdant doit lire l’enregistrement existant et renvoyer son résultat établi. Il ne doit pas créer une seconde facturation chez le prestataire parce qu’une transaction de base a été réessayée.

Les appels externes exigent une frontière transactionnelle

Une base de données ne peut pas valider de façon atomique avec un prestataire de paiement indépendant, à moins que les deux participent à un protocole de coordination spécialisé, ce qui est rarement le cas pour les API publiques. Gardez l’appel réseau hors de la transaction de base et modélisez le flux avec des états explicites comme en attente, autorisé, capturé, échoué et annulé.

Une boîte d’envoi transactionnelle peut publier les changements validés vers des workers en aval. Les consommateurs doivent dédupliquer par identifiant d’événement, car un message peut être livré plusieurs fois. Cela fournit un traitement récupérable sans prétendre à une transaction unique impossible entre tous les services.

Les comptes très actifs exigent une conception adaptée

Les paies, règlements de places de marché et grands commerçants peuvent concentrer les écritures sur un compte. Ajouter des nœuds de base ne répartit pas une seule ligne en conflit. Les options comprennent des partitions d’écritures immuables, des accumulateurs par période, une comptabilisation mise en file pour un compte, ou une hiérarchie de sous-comptes soigneusement définie.

Testez la vraie distribution de l’asymétrie. Un trafic synthétique uniforme peut faire croire qu’un cluster est prêt alors qu’un seul commerçant de production produit des conflits sérialisables répétés. La correction passe avant tout, mais le modèle de données doit révéler la concurrence sûre lorsque les règles comptables le permettent.

Inventaire, réservations et billetterie

Les systèmes d’inventaire et de réservation ont besoin d’une transaction d’allocation faisant autorité lorsque plusieurs utilisateurs peuvent réclamer le même article rare. Des lectures rapides de disponibilité améliorent la navigation, mais seul le chemin de commit peut décider qui reçoit l’unité finale.

Les écritures conditionnelles empêchent la survente

Une mise à jour conditionnelle peut réserver un stock seulement s’il en reste assez. Le nombre de lignes affectées indique à l’application si l’allocation a réussi.

UPDATE inventory
SET available = available - 1
WHERE sku = $1
  AND available > 0;

Cette instruction doit partager une transaction avec l’enregistrement de réservation. Lire la disponibilité puis décrémenter plus tard crée une condition de concurrence, sauf si le niveau d’isolation et le traitement du prédicat protègent la décision. Les contraintes de base doivent également refuser les quantités négatives.

Pour des sièges attribués, une contrainte unique sur la représentation et l’identifiant de siège donne une seule réservation gagnante. L’inventaire hôtelier est souvent modélisé par chambre-nuit ou date de pool d’inventaire afin que des séjours qui se chevauchent ne puissent pas réclamer la même capacité. L’unité correcte de contention découle de la règle métier.

Les blocages temporaires séparent l’allocation du paiement

Un blocage temporaire réserve l’inventaire pendant le paiement ou la confirmation de l’utilisateur. Stockez son heure d’expiration et son état, puis convertissez-le en réservation confirmée par une transaction conditionnelle. Un worker d’expiration ne doit libérer que les blocages encore actifs, car la confirmation et l’expiration peuvent entrer en concurrence.

Un délai d’horloge ne suffit pas à garantir la libération. Les workers peuvent s’arrêter, les files prendre du retard et les régions tomber en panne. Les requêtes qui calculent l’inventaire vendable doivent prendre en compte de façon cohérente le statut expiré, tandis que les tâches de réparation récupèrent les blocages manqués.

La durée du blocage est une décision de produit et de capacité. Un blocage de dix minutes peut être raisonnable pour un paiement, mais il peut immobiliser une part importante d’un stock rare lors d’un pic. Mesurez les abandons et le temps de finalisation du paiement avant de la fixer.

Une contention extrême ne monte pas linéairement en charge

Des milliers d’acheteurs en concurrence pour une ligne ne peuvent pas être parallélisés en ajoutant des réplicas. Chaque décrément réussi doit être ordonné par rapport aux autres. Des contrôles d’admission, une file, des compartiments de stock ou des quotas régionaux préalloués peuvent protéger la base lors d’une mise en vente.

Les quotas régionaux réduisent la coordination mais modifient la sémantique. Si l’Europe possède des unités inutilisées pendant qu’une autre région est épuisée, le système doit disposer d’un moyen sûr de transférer le quota ou accepter un déséquilibre temporaire. Utilisez ce modèle seulement si l’entreprise peut définir comment rapprocher la capacité régionale.

Haute disponibilité et reprise après sinistre

Le SQL distribué peut maintenir le service lors de certaines pannes d’infrastructure lorsque le placement des réplicas, la capacité de réserve et le comportement de l’application correspondent à un objectif de service défini. La réplication seule ne garantit pas ce résultat.

Les SLO doivent préciser les domaines de panne

Un objectif de disponibilité a besoin d’une charge et d’un scénario de panne. Définissez si le service doit survivre à la perte d’un nœud, d’une zone de disponibilité ou d’une région entière. Indiquez le taux d’erreur et la latence acceptables pendant l’événement, pas seulement après la reprise.

Un cluster à trois réplicas placé dans un même bâtiment présente un profil de risque différent de trois réplicas répartis entre zones indépendantes. Une topologie multirégion protège contre un événement plus vaste, mais introduit des chemins de quorum plus longs et nécessite suffisamment de capacité restante pour absorber le trafic après la disparition d’un emplacement.

L’objectif de temps de reprise définit la rapidité avec laquelle le service doit revenir. L’objectif de point de reprise définit la quantité de données validées qui peut être perdue. La réplication synchrone par quorum peut prendre en charge un objectif de zéro perte de données validées pour les pannes couvertes, mais seulement tant que les réplicas requis et le chemin applicatif se comportent comme prévu.

Le basculement crée des événements applicatifs visibles

Les changements de leadership peuvent interrompre des transactions en cours, fermer des connexions et augmenter la latence. Les applications doivent distinguer les résultats de base réessayables des erreurs métier permanentes. Une transaction échouée doit redémarrer dans son ensemble au lieu de rejouer uniquement sa dernière instruction.

Les pools de connexions peuvent conserver des points de terminaison morts après une panne. Les vérifications de santé, le comportement DNS, les équilibreurs de charge, la validation des certificats et la découverte de topologie par le pilote font partie du plan de test. La base peut être saine alors que l’application ne peut toujours pas la trouver.

La capacité après panne mérite un calcul explicite. Si trois régions fonctionnent normalement près de 70 % d’utilisation, en perdre une ne laisse pas assez de place pour sa part de charge. Réserver de la marge coûte de l’argent, mais une topologie sans capacité de basculement ne respecte pas son objectif annoncé.

Les exercices de panne valident la conception

Les exercices de panne doivent désactiver un nœud, isoler une zone, interrompre la connectivité régionale et supprimer un point de terminaison applicatif. Mesurez la durée des erreurs, le taux de nouvelles tentatives de transaction, les percentiles de latence, la croissance des files et la réponse des opérateurs.

Exécutez ces exercices après des changements significatifs de topologie, de pilote ou de schéma. Une procédure validée sur le trafic de l’année dernière peut échouer après un doublement des données ou lorsqu’un locataire devient dominant. Automatisez les parties sûres de l’exercice afin que les preuves ne reposent pas sur un événement manuel annuel.

La réplication n’est pas une sauvegarde

Les réplicas copient fidèlement les suppressions accidentelles, migrations défectueuses et écritures applicatives nuisibles. Les sauvegardes et la récupération à un instant donné protègent contre les dommages logiques que la réplication ne peut pas détecter.

Les exercices de restauration doivent créer un environnement propre séparé, vérifier les sommes de contrôle ou invariants applicatifs et mesurer le temps total de reprise. Incluez les clés de chiffrement, les politiques d’accès, les versions de schéma et la configuration dépendante. Une sauvegarde qui existe mais ne peut pas être restaurée dans l’objectif n’est pas un système de reprise adéquat.

Résidence des données et architecture guidée par la conformité

Le SQL distribué peut placer des groupes de locataires ou d’enregistrements dans des régions approuvées, mais la conformité dépend de chaque copie, chemin d’accès et processus opérationnel. La localité de la base est un contrôle au sein d’un programme plus large.

Les règles de résidence ont besoin de définitions précises

Une exigence selon laquelle les données doivent rester dans un pays peut viser le stockage, le traitement, l’accès du support, les sauvegardes, les clés de chiffrement ou tous ces éléments. Ces interprétations conduisent à des topologies différentes. Les juristes et auditeurs doivent traduire la réglementation et les contrats en contrôles techniques vérifiables.

Les équipes ont besoin d’un inventaire des champs réglementés et des données dérivées. Les journaux, traces, index de recherche, exportations analytiques, pièces jointes de support et files de messages peuvent contenir les mêmes informations personnelles que la table principale. Restreindre la base tout en exportant des charges brutes dans le monde entier ne respecte pas la politique visée.

La minimisation des données peut simplifier la conception. Si un service mondial a seulement besoin d’un identifiant de compte et d’un statut agrégé, gardez les détails sensibles dans la région approuvée et exposez ailleurs la plus petite représentation autorisée.

Les politiques de placement doivent couvrir le cycle de vie

Les politiques doivent indiquer où peuvent exister les réplicas actifs, temporaires, sauvegardes, instantanés, enregistrements de changement et environnements de restauration. Le rééquilibrage et la maintenance doivent respecter la même limite. Une procédure d’urgence ne doit pas copier des données réglementées dans une région non approuvée par commodité.

Le contrôle d’accès a besoin de limites géographiques et organisationnelles. Les identités de service ne doivent recevoir que les tables et opérations nécessaires. L’accès humain à la production doit être journalisé, limité dans le temps lorsque c’est possible et revu. Des clés de chiffrement liées à la région peuvent ajouter un contrôle, même si la disponibilité des clés et la reprise après sinistre demandent alors leur propre conception.

La relocalisation d’un locataire mérite un flux documenté. Des changements contractuels, une migration client ou une restructuration d’entreprise peuvent nécessiter de déplacer les enregistrements entre juridictions. Le processus doit identifier quand les anciennes copies disparaissent, comment les sauvegardes expirent et quelles preuves confirment l’achèvement.

Le reporting mondial peut nécessiter des jeux de données dérivés

Un tableau de bord mondial peut entrer en conflit avec un placement strict s’il analyse des données clients brutes entre régions. Un traitement régional peut calculer localement des agrégats autorisés, puis publier des résultats non sensibles dans un magasin de reporting central.

Les règles d’agrégation doivent empêcher la reconstruction d’enregistrements restreints. Les petits groupes, champs de texte libre et dimensions détaillées peuvent exposer des informations personnelles même après suppression des identifiants directs. La gouvernance analytique doit donc faire partie de la revue d’architecture, pas d’un projet de reporting ultérieur.

Les charges opérationnelles et analytiques méritent souvent des systèmes distincts. La base transactionnelle protège l’état actuel du produit, tandis que des pipelines limités par région produisent des jeux de données gouvernés pour les rapports. Cette séparation éloigne les longues analyses des transactions sensibles à la latence.

Planification des coûts et des performances

Le SQL distribué coûte plus qu’une base élémentaire dans une seule région, car il maintient une capacité redondante et coordonne le travail à travers le réseau. L’investissement peut rester justifié lorsqu’il remplace un sharding coûteux ou évite des pertes qui dépassent ce surcoût opérationnel.

Le calcul et le stockage incluent le coût de la réplication

Un jeu de données logique de 2 To avec trois réplicas complets commence près de 6 To de données répliquées avant les index secondaires, l’espace temporaire de compaction, les sauvegardes et les métadonnées. La facturation et la compression réelles varient selon le produit. Les estimations doivent donc utiliser le stockage physique mesuré plutôt que la seule taille logique des tables.

Le calcul doit couvrir le travail normal, le traitement du consensus, le rééquilibrage, les sauvegardes et la marge de panne. Les nœuds ne sont pas des unités de débit interchangeables lorsqu’une partition est active. Ajouter de la capacité aide seulement si la charge peut se répartir dessus.

Les index multiplient le travail d’écriture et le stockage. Examinez chaque index secondaire selon la valeur des requêtes, la fréquence de mise à jour et le placement géographique. Un index inutilisé dans un cluster distribué gaspille du disque et rend chaque écriture concernée plus coûteuse.

Les frais réseau peuvent devenir importants

La réplication envoie les écritures entre les emplacements des réplicas. Les requêtes multirégion, flux de changements, sauvegardes et trafic applicatif ajoutent des transferts. Un trafic actif dans plusieurs régions peut produire une facture qu’un benchmark dans une région ne révèle jamais.

Estimez les octets par transaction, le facteur de réplication, le débit d’écriture, l’amplification des index et le sens des transferts. Testez ensuite avec les données de facturation du fournisseur pendant un essai de charge représentatif. Les seuls nombres de requêtes ignorent les grosses charges utiles et les déplacements d’arrière-plan.

Les erreurs de localité augmentent le coût comme la latence. Un service déployé dans une région peut interroger à répétition un coordinateur dans une autre à cause de la sélection du point de terminaison ou du placement du locataire. Le traçage distribué et les ventilations de coût régionales peuvent révéler ce modèle.

Les parcours utilisateurs révèlent la latence accumulée

Modélisez les actions utilisateur complètes plutôt que des instructions isolées. Pour un paiement, comptez chaque commit de base séquentiel, lecture forte, appel API externe et passage de file. Appliquez les temps d’aller-retour régionaux mesurés et les percentiles d’exécution des requêtes au chemin critique.

Supposons qu’un parcours contient deux écritures de quorum séquentielles ajoutant chacune 90 millisecondes de coordination réseau. Cela ajoute environ 180 millisecondes avant le traitement applicatif. Regrouper les changements qui partagent une décision atomique peut supprimer un commit, tandis que paralléliser les lectures indépendantes peut raccourcir le chemin.

Les tests de charge doivent inclure une contention et des tailles de charges utiles réalistes. Un benchmark avec des identifiants aléatoires peut se répartir parfaitement alors que les écritures de production ciblent quelques locataires populaires. Incluez les changements de leadership et le rééquilibrage afin que la latence de queue reflète le fonctionnement normal du cluster.

Comparez le coût total de possession à des alternatives réalistes

La comparaison utile n’oppose pas le SQL distribué à une base imaginaire sans coût d’exploitation. Comparez-le à une alternative précise : PostgreSQL géré, réplicas, services de sharding, reprise régionale, routage applicatif et ingénieurs nécessaires pour les maintenir.

Incluez le travail de migration, la formation, l’observabilité, la réponse aux incidents, les plans de support et les coûts de sortie. L’exploitation gérée peut réduire le travail d’infrastructure, tandis que l’auto-gestion peut satisfaire des exigences de contrôle au prix d’équipes plus spécialisées.

Un modèle financier simple peut comparer le surcoût annuel de la plateforme avec les pertes attendues dues aux pannes, le travail d’ingénierie retardé, l’exposition à la conformité et les revenus affectés par la latence régionale. Utilisez des fourchettes pour les entrées incertaines et identifiez l’hypothèse qui change la décision. Si le résultat dépend d’une estimation de panne invraisemblablement élevée, le système plus simple reste probablement approprié.

Modèles de conception de schéma et d’application

Un schéma SQL distribué fonctionne bien lorsque ses chemins d’accès répartissent le travail indépendant tout en gardant les transactions liées proches. Porter un schéma à nœud unique sans le modifier peut préserver la correction tout en produisant une mauvaise latence ou une contention sévère.

Les clés primaires influencent la distribution

Une clé primaire monotone peut diriger les nouvelles lignes vers l’extrémité d’un seul range. Les identifiants aléatoires répartissent les insertions, mais une distribution totalement aléatoire peut rendre les analyses par locataire ou le placement régional coûteux. Les clés composites équilibrent souvent ces objectifs en commençant par un identifiant de locataire ou de compartiment et en conservant une valeur triable dans ce groupe.

Choisissez le préfixe selon les frontières transactionnelles. Si presque chaque opération est limitée à un locataire, regrouper par locataire peut réduire le travail distribué. Un très grand locataire peut nécessiter des compartiments dans son espace de noms pour que plusieurs partitions acceptent des écritures simultanément.

Changer une clé primaire après la croissance d’une table peut exiger une réécriture majeure des données. Testez les dispositions candidates avec une asymétrie réaliste avant la migration. Examinez l’activité des partitions, l’éventail des transactions, la localité des index et le comportement des analyses plutôt que le débit total seul.

La contention exige une refonte avant la capacité

Un compteur mondial, une ligne de configuration unique ou un solde de commerçant unique peuvent sérialiser des requêtes autrement indépendantes. Davantage de nœuds ne peuvent pas supprimer l’exigence logique selon laquelle chaque transaction met à jour la même valeur.

Remplacez les compteurs mondiaux exacts par des compteurs partitionnés lorsque l’agrégation temporaire est acceptable. Versionnez la configuration au lieu de mettre à jour une ligne à haute fréquence. Pour l’état monétaire, préservez l’invariant comptable et cherchez de la concurrence dans les écritures par ajout ou sous-comptes indépendants au lieu d’affaiblir la correction.

Les longues transactions de lecture-modification-écriture aggravent les conflits. Lisez le plus petit ensemble nécessaire, évitez toute interaction utilisateur dans une transaction et validez rapidement. Si le travail métier prend des minutes, représentez-le comme une machine à états sur plusieurs transactions courtes.

Le comportement de nouvelle tentative fait partie du contrat applicatif

Les pilotes peuvent réessayer des instructions individuelles ou exposer une erreur réessayable au code applicatif. Comprenez quelle couche possède la responsabilité de rejouer la transaction complète. Un rejeu partiel peut utiliser des décisions obsolètes ou omettre des lectures antérieures.

Une boucle de tentative doit avoir un nombre maximal d’essais, un recul aléatoire et de l’instrumentation. Enregistrez le type de conflit, l’opération concernée, le nombre de tentatives et le résultat final. Des tentatives illimitées transforment la contention en latence cachée et peuvent surcharger le cluster.

Les requêtes métier ont besoin d’identifiants stables afin qu’une réponse client incertaine puisse être vérifiée sans danger. Si la base valide mais que la réponse est perdue, le client doit interroger l’opération établie au lieu de soumettre une opération sémantiquement nouvelle.

Les changements de schéma exigent une répétition à l’échelle de production

Les changements de schéma distribués peuvent mettre à jour les métadonnées rapidement alors que les remplissages et créations d’index continuent en arrière-plan. Ces tâches consomment stockage, réseau et CPU, et peuvent interagir avec les écritures en direct.

Utilisez des migrations d’extension puis de contraction. Ajoutez d’abord des champs ou tables compatibles, déployez un code qui fonctionne avec les deux formes, remplissez les données par lots contrôlés, basculez les lectures, puis retirez l’ancienne forme après vérification. Le plan de retour en arrière doit tenir compte des données écrites par la nouvelle version.

Testez les grandes migrations avec un volume et une topologie régionale proches de la production. Un changement qui finit vite sur un petit cluster de préproduction peut prendre des heures en production et concurrencer le trafic client. Surveillez la progression, les contrôles de pause, la marge disque et le comportement de nouvelle tentative avant de commencer.

Checklist d’adoption et preuve de concept

Une preuve de concept utile teste une charge représentative contre des objectifs explicites de correction, de latence, de résilience et de coût. Les benchmarks génériques ne peuvent pas déterminer si un schéma et une application particuliers se comporteront bien.

Choisissez une charge avec de vraies contraintes

Choisissez un flux tel que la réservation d’un article rare, la comptabilisation d’un transfert de grand livre ou le provisionnement d’un locataire dans une région obligatoire. Réutilisez son schéma, ses requêtes, ses frontières de transaction, ses tailles de charge utile et son asymétrie de trafic proches de la production.

Définissez la réussite avant le test :

• Des résultats corrects malgré la concurrence et les nouvelles tentatives
• La latence p50, p95 et p99 par région
• Un débit de pointe soutenu avec une marge de panne
• Le comportement de reprise lors de pannes de nœud et de région
• Le coût mesuré du calcul, du stockage et du réseau

Une marge de sécurité doit venir de la croissance attendue et de la capacité en cas de panne, pas d’un multiplicateur arbitraire. Si la perte d’une région entre dans le périmètre, les emplacements restants doivent absorber la charge redirigée pendant le test.

Construisez une surface applicative réaliste

Une API et une petite interface utilisateur révèlent le séquencement des transactions, le comportement du pilote et la latence perçue par l’utilisateur qu’un outil limité à la base peut manquer. Koder.ai peut créer par chat une interface React, un backend Go et une base PostgreSQL de référence. Son mode de planification peut aider à définir le flux avant la génération, et l’export du code source permet aux ingénieurs d’adapter la couche de données pour une base candidate.

Utilisez cette application générée comme échafaudage de test, pas comme preuve de compatibilité de la base. Exécutez les migrations, inspectez le SQL généré, configurez le pilote officiel et implémentez délibérément les nouvelles tentatives de transaction. Les instantanés et le retour en arrière de Koder.ai peuvent protéger les itérations applicatives, mais ils ne remplacent pas les sauvegardes de base ni les exercices de restauration.

Koder.ai prend aussi en charge le déploiement et l’hébergement, ce qui permet de placer des instances de l’application de test près des régions de la base. Vous pouvez ainsi mesurer le chemin de requête complet au lieu d’émettre chaque benchmark depuis un seul emplacement. Gardez des données de test synthétiques sauf si l’environnement possède les contrôles exigés pour des enregistrements de production.

Testez le fonctionnement normal et les pannes

Le test doit couvrir un trafic stable, des pics, des partitions actives, des requêtes longues, des changements de schéma, le travail de sauvegarde et le remplacement de nœuds. Interrompez ensuite la connectivité et supprimez un domaine de panne dans l’environnement de test approuvé.

Collectez les annulations de transaction, tentatives de reprise, réponses indisponibles, mouvements de leader, profondeur des files, utilisation du disque et transferts régionaux. Notez ce qu’un opérateur a dû faire. Une reprise automatique qui exige une étape manuelle non documentée n’est pas encore prête pour la production.

Restaurez une sauvegarde dans un environnement distinct et vérifiez les invariants applicatifs. Pour l’inventaire, confirmez que les allocations ne dépassent pas le stock. Pour un grand livre, recalculez les soldes et vérifiez l’équilibre des écritures. Pour les locataires SaaS, confirmez que les politiques de placement et d’accès ont survécu à la restauration.

Validez la compatibilité avant la migration

Inventoriez les extensions de base, procédures stockées, déclencheurs, types de données, hypothèses d’isolation, fonctions de l’ORM, requêtes de reporting, outils de sauvegarde et scripts administratifs. Classez chaque élément comme compatible, remplaçable ou bloquant.

Exécutez des migrations représentatives sur une copie complète ou un jeu de données généré à taille réelle. Mesurez la durée du remplissage, le retard de capture des changements de données, le coût de l’exécution en double et le temps de bascule. Si la migration utilise des écritures doubles, définissez comment détecter les écarts et quel système fait autorité à chaque phase.

Les lectures parallèles peuvent comparer les résultats sans modifier l’état de production. Tenez compte des différences de synchronisation et des requêtes volontairement anciennes afin que la comparaison ne considère pas une variation attendue comme une corruption. Toute différence inexpliquée dans les données transactionnelles doit être résolue avant la bascule.

Examinez l’état de préparation à la production

Une revue de production doit attribuer des responsables pour l’exploitation de la base, les nouvelles tentatives applicatives, la sécurité, la politique de résidence, les coûts et la réponse aux incidents. Elle doit inclure des tableaux de bord, alertes, procédures, seuils de capacité, preuves de restauration et un point de décision de retour en arrière.

La décision finale peut toujours être de rester sur PostgreSQL ou MySQL. Une preuve de concept réussit lorsqu’elle produit des preuves fiables, même si elles montrent que l’option distribuée coûte davantage que ce que les exigences actuelles justifient. Lorsque les exigences soutiennent l’adoption, migrez progressivement, mesurez chaque étape et conservez un chemin de retour testé jusqu’à ce que le nouveau système ait fait ses preuves sous une vraie charge.