Consignes pour la planification de serveurs de bases de données fédérés
La création d'une fédération de serveurs de bases de données consiste à concevoir un jeu de vues partitionnées réparties sur les serveurs. Le partitionnement fonctionne correctement lorsque les tables de la base de données sont naturellement divisibles en partitions similaires, où la plupart des lignes accessibles par une instruction SQL peuvent être placées sur le même serveur membre. Les tables sont des clusters d'unités associées. Par exemple, l'entrée d'une commande fait référence aux tables Orders, Customers, et Parts, ainsi qu'aux tables qui enregistrent les relations entre les clients, les commandes et les pièces. Les partitions fonctionnent plus efficacement lorsque toutes les lignes d'un cluster logique peuvent être placées sur le même serveur membre.
Partitions symétriques
Le partitionnement est optimal si toutes les tables d'une base de données peuvent être partitionnées symétriquement comme suit :
Les données associées sont placées sur le même serveur membre, de sorte que la plupart des instructions SQL routées vers le serveur membre approprié auront besoin de peu de données, voire aucune, sur les autres serveurs membres. L'objectif de création d'une vue partitionnée distribuée peut se résumer à une règle des 80/20 : créez les partitions pour que la plupart des instructions SQL puissent être routées vers un serveur membre, où résident au moins 80 % des données, et où les requêtes distribuées représentent tout au plus 20 % des données. Pour tester cette règle, il suffit de déterminer si la partition permet à toutes les lignes d'être placées sur le même serveur membre que l'ensemble des lignes de clés étrangères de référence. Les créations de bases de données répondant à cet objectif sont particulièrement adaptées pour un partitionnement.
Les données sont partitionnées de manière uniforme sur les serveurs membres.
Par exemple, une société a découpé l'Amérique du Nord en régions. Chaque employé travaille dans une région, et les clients effectuent la plupart de leurs achats dans l'État ou la province de leur lieu de résidence. Les tables des régions et des employés sont partitionnées selon les régions. Les clients sont partitionnés entre les régions par leur État ou leur province. Tandis que certaines requêtes nécessitent des données provenant de plusieurs régions, les données nécessaires à la plupart des requêtes se trouvent sur le serveur d'une région. Les applications acheminent les instructions SQL vers le serveur membre contenant la région associée au contexte des entrées utilisateur.
Partitions asymétriques
Bien que les partitions symétriques représentent la structure idéale, la plupart des applications possèdent des modèles complexes d'accès aux données qui empêchent le partitionnement symétrique. Il en résulte des partitions asymétriques sur certains serveurs membres dont les rôles sont les plus importants. Par exemple, seules certaines tables d'une base de données peuvent être partitionnées, tandis que les tables non partitionnées demeurent sur le serveur d'origine. Les partitions asymétriques peuvent assurer la plupart des performances d'une partition symétrique, avec les avantages importants ci-après :
Amélioration sensible des performances d'une base de données qui ne peut pas être partitionnée symétriquement, en partitionnant de manière asymétrique certaines de ses tables.
Partitionnement efficace d'un système de grande taille en effectuant une série d'améliorations itératives asymétriques. Les tables choisies pour le partitionnement à chaque étape sont généralement celles qui produiront le gain de performance le plus élevé.
Dans une approche asymétrique, le serveur d'origine conserve généralement certaines tables n'ayant pas pu être insérées dans le schéma de partition. Les performances de ces tables restantes sont généralement meilleures que dans le système d'origine, car les tables membres sont déplacées vers les serveurs membres, ce qui réduit la charge du serveur d'origine.
De nombreuses bases de données peuvent être partitionnées de plusieurs façons. Les partitions spécifiques choisies pour l'implémentation doivent être celles qui répondent le mieux aux exigences de la série d'instructions SQL courantes exécutées par le niveau des services d'entreprise.