Un cluster SynSql peut regrouper des milliers de serveurs.
Pour les processus clients, le point d'entrée d'un cluster est constitué de plusieurs serveurs appelés synsql brokers. Ils sont en charge d'identifier les connexions des processus clients et d'exécuter leur requêtes. Leur nombre est limité à 32.
Les différents objets gérés par un cluster SynSql sont stockés dans un dictionnaire de données. Ce dictionnaire est servi par des machines dédiées qui portent chacune une image miroir du dictionnaire.
SynSql supporte jusqu'à 16 master brokers.
Les data brokers sont des machines qui portent des serveurs de base de données SQL. Ils sont dédiés au stockage des tables et des index du cluster. Le nombre de data brokers d'un cluster est contrôlé par une licence mais il n'existe pas de limite physique. Par contre, si rien n'interdit de créer un cluster basé sur plusieurs milliers de data brokers, ce dernier n'aura de sens que si les machines dédiées aux synsql servers possèdent suffisemment de coeurs pour fournir le résultat des requêtes de sélection dans le délai attendu : l'exécution d'une requête select comportant une clause order by sur une table possédant 1000 partitions suppose l'exécutions de 2000 processus concurrents.
Quand un SynSql broker reçoit un ordre Select, il compare le nombre de coeurs qu'il possède aux nombre de partitions de la première table de la requête. Si le nombre de coeurs est inférieur à 10% du nombre de partition, le broker va exécuter la requête seul. Nous parlons alors de sélection simple. Les étapes sont les suivantes :
Le client connecte le dernier broker SynSql connu. Si ce broker ne répond pas, le client se connecte silencieusement au prochain broker disponible.
Le broker SynSql reçoit la requête. Il en extrait le nom de la première table de la sélection.
Le SynSql broker se connecte au dernier master broker qu'il a utilisé. Si le master broker ne répond pas, le SynSql broker se connecte automatiquement au prochain master broker disponible et tous les SynSql brokers oublient le master broker fautif.
Le SynSql broker demande les caractéristiques de la table au master broker et effectue des vérifications. Il note en particulier le nombre de partitions de la table.
Si le nombre de coeurs du SynSql broker dépasse 10% du nombre de partitions de la table, il exécute la requête seul, comme décrit au paragraphe suivant. Si le nombre de coeurs est trop faible, le SynSql broker va tenter de faire appel à d'autre SynSql brokers pour partager la charge de l'exécution de la requête et continue son exécution comme décrit au paragraphe 6.
Le SynSql broker lance un ensemble de processus dédiés à l'exécution de la requête. Une partie de ces processus sont chargés de la lecture d'une partition, les autres assemblent et au besoin trient les rangées.
Chaque processus de lecture se connecte au premier data broker de la partition qui l'intéresse et retourne les rangées vers lers processus assembleurs.
- Si la connexion échoue et si la partition a plusieurs images, le processus de lecture marque le data broker comme indisponible et tente de continuer avec le data broker suivant. S'il n'a aucun suivant disponible la requête retourne une erreur.
- Si un processus lecteur voit que le data broker qu'il interrogeait cesse de fonctionner, il marque le data broker comme indisponible et retourne une erreur.
Le SynSql broker demande la liste des autres SynSql brokers disponibles et compte le nombre de coeurs cumulés. S'il ne parvient pas à réunir le nombre de coeurs souhaités( au moins 10% du nombre de partitions de la table sélectionnée), il exécute la requête comme décrit au paragraphe précédent.
Le SynSql broker détermine le nombre de partitions que chaque SynSql broker sous-traitant va pouvoir exécuter en fonction de son nombre de coeurs.
Les partitions sont distribuées par intervalles, chaque SynSql broker sous traitant recevant son propre intervalle. Ainsi, une table répartie sur 100 partitions pourrait être distribuée sur trois SynSql brokers sous traitants comme suit:
- Le premier sous-traitant qui a 4 coeurs traitera les partitions de 0 à 39,
- Le deuxième sous-traitant qui a deux coeurs traitera les partitions de 40 à 59,
- Le troisième sous-traitant qui a 4 coeurs traitera les partitions de 60 à 99.
Le SynSql broker lance un ensemble de processus dédié à la requête. Une partie de ces processus va se charger de l'arrangement et du tri éventuel des rangées. Les autres vont chacun se connecter à un SynSql broker sous traitant pour lui demander d'exécuter la requête sur une partie des partitions de la table comme prévu à l'étape précédente.
Chaque broker SynSql sous traitant reçoit la requête et, en utilisant des techniques similaires au traitement d'une requête simple, exécute la requête su les partitions convenues. Les rangées sont retournées aux processus d'assemblage du broker SynSql initial qui se charge de retourner les rangées au processus client.
Les brokers SynSql sous-traitants s'exécutent en parallèle sur des machines différentes. La distribution de la requête est effective à la fois sur les brokers SynSql sous-traitants et sur les data brokers.
| 15 Jan 2026 04:12:48 | English version |