Tout utilisateur est autorisé à créer ses propres tables. Il peut gérer table par table les privilèges qu'il octroie aux autres utilisateurs, mais :
- L'espace des noms des tables est unique. Deux tables de deux utilisateurs distincts ne peuvent porter le même nom.
- Le nombre des privilèges est réduit. Il n'existe pas de privilege système. L'option "with grant option" de la commande grant n'est pas implémentée.
Le jeu d'instructions SynSql est réduit par rapport à celui d'un serveur de données classique. Et les instructions elles mêmes acceptent moins d'options. SynSql comporte des instructions spécifiques (comme deploy table) et des options spécifiques (comme alter table set datacenter...).
A titre d'exemple, la commande create index n'existe pas. Mais il faut noter que son utilité serait réduite. Elle viserait à recenser les index et leurs colonnes dans le dictionnaire de données puis à propager leur definition vers les différents data brokers qui portent la table. Une fois un index créé, SynSql n'en aurait aucun usage : la gestion des index est le travail des serveurs de données des data brokers. Pour autant, le fait de définir des index est un besoin indispensable.
Pour répondre àu point précédent comme à tous les cas où il est nécessaire de faire exécuter une instruction particulière et où SynSql n'a aucune valeur ajoutée, nous avons conçu l'instruction "execute query". Cette instruction vise un ou tous les databrokers portant une table. Et son objet est de faire exécuter la requête fournie en argument.
SynSql ne fait aucun contrôle de la requête à exécuter. L'instruction "execute query" doit être utilisée avec précaution car elle est très puissante. Elle peut conduire au résultat souhaité tout comme à la destruction ou la corruption irrémédiable des données.
SynSql présente des limites quand aux requêtes de type select soumises sur des tables possédant plusieurs partitions. Voir le paragraphe précedent.
SynSql ne sait pas gérer les transactions. Toute instruction est exécutée à réception et ne peut subir de rollback.
De plus, il n'y a pas de mécanisme pour isoler les requêtes concurrentes simultanées. Dans le modèle sql classique, si une requête veut modifier une rangée qui vient d'être changée par une autre requête toujours en cours d'exécution, elle attent qu'un verrou se libère. C'est exactement ce qui se passe si deux requêtes concurrentes se voient exécutées au sein d'un même data broker. Il n'existe pas de mécanisme de verrou global qui serait réparti sur l'ensemble des data brokers et qui permettrait d'isoler les requêtes.
Les requêtes de définition de données n'échappent pas au point ci dessus. Si deux utilisateurs demandent simultanément l'ajout d'une colonne à une table, en utilisant le même nom et des types de donnée différents, il est possible que chacun parvienne à mettre à jour un master broker et voie sa requête échouer sur le master broker mis à jour par l'autre utilisateur (la colonne existe déjà).
Si un incident quelconque vient à scinder un cluster SynSql en deux ou plusieurs parties, chacune d'entre-elles va réagir en fonction de son contexte.
Toute partie comprenant au minimum un client, un synsql server, un master broker et un data broker va permettre au client de se reconnecter automatiquement sur un des synsql broker de la partie, et de créer des rangées dans les segments portés par les data brokers présents dans cette partie.
Si deux parties distinctes ont conduit à créer des rangées distinctes dans des segments homologues distincts, le cluster est corrompu.
Si les parties du cluster formées par le split-brain constituent une partition du cluster au sens mathématique du terme (les parties n'ont pas d'éléments en commun), un cluster corrompu peut être resynchronisé sur la base de l'une des parties. Les modifications faites par les autres parties seraient perdues. Mais ce cas de figure ne semble pas être le plus fréquent. Dans un cas où une partie des synsql brokers ne voit plus que la moitié des master brokers quand les synsql brokers restants ne voient exactement que l'autre moitié des master brokers, si tous les synsql brokers voient tous les data brokers, la désynchronisation peut être fatale.
La solution proposée par SynSql pour réduire la probabilité d'un split-brain est de placer tous les master brokers dans un même réseau physique.
| 15 Jan 2026 05:36:24 | English version |