Documentation > Guide de l'utilisateur
Le fait de partitioner les tables et de faire porter ces partitions par plusieurs serveurs à l'intérêt de permettre de mettre facilement un grand nombre de processeurs au service d'une base de données. Il implique aussi que l'exécution des requêtes se fait en parallèle, sur des serveurs distincts. Ces serveurs, sont les data brokers et n'ont aucune 'connaissance' du fait qu'ils contribuent à former un cluster SynSql, ni qu'ils ont des homologues. Ils exécutent les requêtes qu'ils reçoivent sur les données qu'ils possèdent.
Il est donc facile de construire un modèle de données SynSql capable de produire des résultats décevants. Pour éviter ceci, il est nécessaire de bâtir le modèle logique des données en respectant certaines règles. L'objet de ce paragraphe est de présenter ces règles.
Il faut aussi souligner que si SynSql se propose de vous aider à gérer des données volumineuses, qu'il vous permet de réunir la puissance de calcul de nombreux serveur plutôt que de devoir utiliser un grand calculateur, il n'a pas vocation à porter des modèles complexes.
La particularité de la clef de hachage est qu'elle n'est pas modifiable. Tout simplement parce que les nouvelles valeurs pouvant présenter une nouvelle valeur de clef, les rangées concernées pourraient ne plus être à leur place dans le segment et devraient être déplacées. Cela n'est pas supporté.
Vous pouvez décider que l'identifiant fonctionnel d'un contact est une adresse mail ou un numéro de téléphone. A ce titre vous en faites la clef de hachage de votre table. Si vous ajoutez une clef unique ou primaire sur cette colonne, vous pouvez garantir l'unicité de la valeur (modulo une réserve présentée plus avant au paragraphe écritures consistantes).
En contrepartie, si votre interlocuteur vous fait part d'un changement d'adresse ou de téléphone ou si vous devez rétablir une erreur, il va falloir créer une nouvelle rangée, copier toutes les données qui conviennent et supprimer l'ancienne ce qui peut s'avérer lourd.
Via un générateur de nombre séquentiels, vous pouvez décider d'utiliser une clef de hachage numérique, sans aucune valeur fonctionnelle. Vous pourrez ajouter un index unique sur cette clef. Il améliorera les performances et préviendra les éventuelles erreur du générateur. Vous pourrez facilement modifier toutes les autres colonnes de la table, mais aucun index unique placé sur ces colonnes ne pourra garantir une unicité globale
Si vous avez impérativement besoin d'une clef primaire ou unique sur une partie des colonnes d'une table et d'une clef unique sur d'autres colonnes de cette même table, n'utilisez pas SynSql.
Comme il est décrit dans le guide des concepts au chapitre exécution des requêtes Les jointures et les instruction update ou delete qui comportent une clause where peuvent créer des difficultés.
Le modèle en étoile peut vous apporter des solutions. Si votre modèle est plus complexe, il vous faudra utiliser des contournements programatiques.
Quand vous insérez une rangée dans une table, c'est le synsql broker qui reçoit l'instruction qui se charge d'analyser la requête, de calculer la clef de hachage et d'expédier l'ordre d'insertion dans les segments qui correspondent à la valeur de la clef.
Le synsql broker calcule la clef de hachage sur la base de ce qu'il lit dans la requête, pas sur celle de l'évaluation de ce qui est fourni. A titre d'exemple, '1+1' et '2' ont la même valeur mais dans tous les cas ou les clef de hachage diffèrent (ce qui dépend du nombre de partitions) les 2 rangées seraient stockées dans des segments distincts.
Donc, même avec un modèle en étoile bien géré avec des clef uniques sur la clef de hachage vous pourrez créer des doublons si vos écritures ne sont pas régulières. La règle de base est de faire en sorte que les valeurs de clef de hachage ne soient jamais des formules.
| 15 Jan 2026 07:18:35 | English version |