Une base de données ou un sous-ensemble d'une base de données peut être réparti sur plusieurs serveurs ; chaque division est appelée partition. Stratus et Teradata ont développé les premières bases de données à traitement massivement parallèle (MPP) avec leur propre matériel spécialisé. Oracle a créé la première base de données MPP portable fonctionnant sur du matériel de différents fournisseurs. Oracle, Mainframe DB2 et Snowflake utilisent une architecture "shared-everything", où chaque instance de base de données peut voir l'ensemble de la base de données partitionnée et la propriété dynamique des blocs de données qu'un gestionnaire complexe de verrous distribués doit gérer.
D'autres fournisseurs utilisent une approche plus directe de base de données fédérée dans laquelle chaque instance de base de données ne voit que sa partition. Vous pouvez utiliser le partitionnement sur un seul nœud si vous avez des requêtes liées à l'E/S. Dans ce cas, vous pouvez explicitement partitionner vos données sur différents canaux d'E/S et périphériques de stockage. Dans ce cas, vous pouvez explicitement partitionner vos données sur différents canaux d'E/S et périphériques de stockage.
Par exemple, si vous disposez d'un serveur puissant qui doit effectuer un balayage complet d'une très grande table, vous pouvez partitionner le serveur sur plusieurs disques physiques pour surmonter les contraintes physiques d'un seul périphérique, telles que la bande passante du bus et les temps de recherche initiaux lents dus au retard de rotation des disques physiques. Le partitionnement permet d'échelonner les entrées-sorties afin d'optimiser la capacité du processeur et les durées globales d'analyse.
Avantages du partitionnement des données
Les raisons les plus courantes pour lesquelles les organisations partitionnent une base de données physique sont l'amélioration des performances, de la disponibilité et de l'équilibrage de charge. Les performances s'améliorent grâce à l'exécution des requêtes en parallèle sur un plus grand nombre de processeurs qu'un seul serveur. La disponibilité est améliorée en limitant l'impact d'une panne de serveur à la seule partition des données qu'il gère. Les serveurs de base de données compatibles avec le parallélisme créent des plans de requête qui répartissent les charges de travail sur les nœuds de serveur en réseau afin de distribuer le traitement et de renvoyer les résultats plus rapidement.
Par exemple, si vous avez une application de tarification mondiale qui doit être très réactive, vous pouvez répartir ses données dans trois centres de données géographiques. Comme une base de données géographiquement locale contient cette tarification régionale, elle sera plus réactive qu'une base de données mondiale unique, et la disponibilité sera améliorée car une maintenance en dehors des heures de pointe sur le serveur des États-Unis n'aura pas d'incidence sur la disponibilité des serveurs de la région EMEA et de l'Asie.
Lorsque les applications dépassent la capacité d'un seul serveur, il n'est pas nécessaire d'en provisionner un plus grand pour suivre le rythme. Si votre base de données fonctionne sur un système en grappe, l'ajout d'un petit nœud supplémentaire peut s'avérer plus rentable. Dans l'informatique dématérialisée, vous pouvez approvisionner les serveurs et le stockage à la demande pour répondre aux pics de charge.
Cloud gestion des données Stratégie
Les centres de données sur site doivent approvisionner les serveurs avec des contraintes physiques telles que la taille du centre de données. Les plateformes cloud public d'Amazon, de Microsoft et de Google offrent une capacité supérieure à celle d'un centre de données interne . La plateforme de données Actian fonctionne sur des plateformes cloud public ; le stockage est découplé des ressources de calcul, de sorte que la puissance de calcul peut augmenter ou diminuer en fonction de la à la demande, indépendamment des partitions physiques.
Quand partitionner une table ?
Le partitionnement complique la gestion de la base de données, c'est pourquoi vous ne devez l'utiliser que lorsque vous pouvez obtenir des performances adéquates sans partitionnement. Utilisez le partitionnement lorsque vous devez adapter les performances de la base de données pour support volumes de transactions importants et des requêtes très volumineuses.
Stratégies de partitionnement
Vous pouvez partitionner les données de plusieurs façons, en fonction des besoins de l'application et du contenu des données. Si l'objectif principal est la performance, vous devez prévoir de répartir la charge de manière uniforme afin d'obtenir le débit le plus élevé. Par exemple, vous pouvez mettre en place 64 partitions par serveur et utiliser un hachage calculé pour répartir les données de manière uniforme ou distribuer les données à l'aide d'un schéma round-robin. Si les données ont une valeur clé naturellement aléatoire avec une cardinalité élevée, elles peuvent être réparties en plages de valeurs par partition. En général, les données sont partitionnées horizontalement pour répartir la charge de travail sur de nombreux serveurs. Dans le cas d'un partitionnement vertical, vous pouvez décider de diviser vos données en trois régions mondiales, de sorte que vous disposez d'un tableau de haut niveau avec des valeurs globales. Des tableaux détaillés en dessous pour une région géographique peuvent support autonomie régionale.
Méthodes de partitionnement
Les bases de données qui support clusters ou les configurations MPP offrent plusieurs méthodes de partitionnement. Vous trouverez ci-dessous une sélection de méthodes de partitionnement :
- Partitionnement par plage - divise les lignes en fonction d'une plage de valeurs clés. Si votre application effectue une analyse des ventes par région, il peut être judicieux de diviser les données par plages de codes postaux.
- Partitionnement en liste - organise les données sur la base d'une liste de valeurs. Par exemple, les valeurs de la liste contenant "Écosse", "Angleterre", "Irlande du Nord" et "Pays de Galles" pourraient être placées dans une partition nommée "Royaume-Uni".
- Partitionnement en colonnes - est utilisé pour diviser une grande table en colonnes où les colonnes statiques sont stockées dans une table, et les colonnes plus dynamiques sont placées sur une table et un serveur différents, une vue étant utilisée pour les relier en tant qu'objet unique. Une base de données en colonnes peut être considérée comme partitionnée verticalement, car chaque colonne est une table.
- Partitionnement "Round Robin" - insère de nouvelles lignes dans une partition différente dans un ordre séquentiel et répétitif spécifique.
- Partitionnement par hachage - génère un identifiant de partition en nombres entiers aléatoires basé sur une valeur calculée qui peut utiliser une clé basée sur la valeur insérée.
- Partitionnement par clé - il est similaire au partitionnement par hachage, à la différence qu'il peut évaluer les valeurs de plusieurs colonnes pour déterminer la partition cible.
- Partitionnement composite - imbrique plusieurs niveaux de partitionnement. Par exemple, le premier niveau de partitionnement peut être basé sur une plage, et le second niveau peut être un round robin dans cette plage.
Partitionnement Élagage
L'élagage des partitions est une optimisation qui permet à une requête de ne pas évaluer les partitions pour une requête particulière afin d'améliorer les performances. Par exemple, si vous ne souhaitez requête qu'une certaine plage de codes postaux, vous pouvez spécifier une clause WHERE indiquant les limites inférieures et supérieures. L'optimiseur de requête générera une clause IN contenant uniquement les valeurs de la plage, en ignorant les autres partitions.
plateforme de données Actian Partitioning
Le partitionnement est une stratégie essentielle dans le déploiement de la plateforme de données Actian , car elle est conçue pour le parallélisme. La plateforme de données Actian est conçue pour fonctionner efficacement, en utilisant au mieux les ressources de la grappe lorsqu'au moins une table de toute requête non triviale (jointive) est partitionnée. L'absence de partitionnement approprié peut avoir un impact sur les performances, c'est pourquoi vous devez envisager de mettre en œuvre le partitionnement lorsqu'il est approprié.
Le partitionnement dans la plateforme de données Actian répartit les lignes d'une table entre des sous-tables (partitions). Un schéma de partitionnement détermine quelles lignes sont envoyées à quelles partitions.
Le partitionnement est géré automatiquement. Pour définir une table avec un plan de partitionnement explicite, utilisez l'option PARTITION= dans la clause WITH de l'instruction CREATE TABLE. Le partitionnement automatique étant la valeur par défaut, il n'est pas nécessaire de spécifier explicitement la clause WITH PARTITION.
La plateforme de données Actian prend en charge deux schémas de partitionnement qui définissent une règle (schéma de distribution) pour l'affectation des lignes aux partitions. Conceptuellement, une dimension définit un ensemble de partitions logiques. Les types de distribution suivants sont disponibles :
- HASH - Distribue les lignes de manière égale entre les partitions en utilisant une valeur de hachage (au lieu d'une valeur aléatoire). Compte tenu d'une valeur de partitionnement des colonnes, une requête peut prédire quelle partition contient des lignes ayant la valeur correspondante. Ainsi, une requête peut limiter sa recherche à un sous-ensemble de partitions. HASH dépend des données et nécessite la clause ON.
- AUTOMATIQUE - (Par défaut) Distribue aléatoirement les lignes entre les partitions.
Le schéma de distribution peut être une valeur par défaut définie au niveau du système. Les noms des partitions logiques facultatives doivent être uniques pour chaque table. Le même nom de partition peut apparaître dans d'autres tables partitionnées. Si un nom de partition est omis, le système génère un nom (de la forme iipartnn).
Syntaxe de partitionnement
La définition d'une partition de table a le format suivant :
PARTITION = (dimension)
La syntaxe pour chaque dimension de la partition est la suivante :
dimension = règle partitionspec{, partitionspec}
règle
Définit le type de schéma de distribution pour l'affectation des lignes aux partitions. Les valeurs valides sont les suivantes :
HASH ON column{, column}
Distribue les lignes de manière égale entre les partitions en fonction d'une valeur de hachage.
ON column{,column}
spécifie les colonnes sur lesquelles la table doit être partitionnée.
AUTOMATIQUE
(Par défaut) Distribue les lignes de façon aléatoire entre les partitions.
partitionspec
Définit le nombre de partitions et éventuellement leur nom :
partitionspec = PARTITIONS PAR DÉFAUT | [nn] PARTITION[S] [ ( nom{, nom} ) ]
où :
PARTITIONS PAR DÉFAUT
Utilise le nombre de partitions par défaut configuré pour des performances optimales en fonction de la taille de votre entrepôt.
L'instruction renvoie une erreur si la valeur par défaut de la partition n'est pas définie.
nn
Est le nombre de partitions, qui est par défaut de 1 s'il est omis.
nom
Identifie la partition. Lorsque le nombre de partitions est égal ou supérieur à deux, une liste de noms séparés par des virgules peut remplacer la valeur par défaut.
Valeur par défaut : iipartNN
Lignes directrices pour les tables partitionnées
Vous devez choisir la clé de partition parmi les colonnes qui ont des valeurs uniformes, par exemple les clés primaires/étrangères. Si vous vous attendez à avoir de nombreuses requêtes qui joignent les tables A et B à la condition A.fk_col = B.col, les bonnes clés de partitionnement pour A et B sont respectivement fk_col et col.
Il est recommandé d'utiliser une partition par cœur et par nœud :
num_partitions = num_nœuds * K
où K est un diviseur du nombre de cœurs physiques par nœud.
La création d'un index sur les colonnes qui définissent une relation étrangère n'est pas autorisée lorsque les tables reliées par la relation étrangère n'ont pas le même nombre de partitions ou ne sont pas partitionnées sur les colonnes (ou un sous-ensemble correspondant) utilisées pour la relation de clé étrangère. Par exemple :
Les éléments suivants sont autorisés :
CREATE TABLE X (a i4 NOT NULL, b i4 NOT NULL, c i4 NOT NULL) WITH PARTITION=(HASH ON a,c 2 PARTITIONS) ; ALTER TABLE X ADD CONSTRAINT pk_x PRIMARY KEY (a,c) ; CREATE TABLE Y (c i4 NOT NULL, d i4 NOT NULL, e i4) WITH PARTITION=(HASH ON d,e 2 PARTITIONS) ; ALTER TABLE Y ADD CONSTRAINT fk_y FOREIGN KEY(d,e) REFERENCES X(a,c) ; CREATE INDEX idx_y ON Y(d,e) ;
La répartition des clés sur c pour X et e pour Y est également valable.
Le schéma de partitionnement AUTOMATIQUE par défaut répartit aléatoirement les lignes entre les partitions. Contrairement aux tables distribuées par hachage, les lignes ayant des valeurs égales ne sont pas assurées d'être affectées à la même partition. Par conséquent, le système doit généralement réorganiser les données avant de résoudre la requête. Par exemple, pour joindre deux tables à partitionnement automatique, il faut généralement remanier les lignes. Cette étape supplémentaire peut dégrader les performances de la requête .
Le partitionnement AUTOMATIQUE doit être utilisé dans les cas suivants :
- Lorsque l'on manque de perspicacité pour créer une bonne clé de hachage. C'est-à-dire lorsque :
- Il n'y a pas de clé d'assemblage évidente
- Il n'y a pas de bon candidat pour la distribution par hachage de la table (données arbitraires).
- La table ne partage pas de clé de jointure commune avec d'autres tables.
- La table est une table de transit temporaire
- Lorsque vous définissez une table partitionnée automatiquement comme étape préparatoire à la création d'une bonne clé de répartition, vous pouvez utiliser CREATE STATISTICS puis SELECT pour obtenir les valeurs minimales et maximales des colonnes et les COUNT afin de mieux choisir les colonnes à utiliser comme clé de répartition HASH.
Schéma de distribution par défaut
Vous pouvez attribuer un schéma de distribution par défaut lors de la création de tables partitionnées. Le paramètre de distribution par défaut peut être remplacé au niveau de la session à l'aide de l'instruction SET PARTITION_SCHEME. Vous pouvez attribuer un nombre de partitions par défaut lors de la création de tables partitionnées. Spécifiez WITH PARTITION = (règle ON column DEFAULT PARTITIONS) lors de la création ou de la modification de tables. La table sera partitionnée selon le nombre de partitions configuré. Le nombre de partitions par défaut peut être modifié au niveau de la session à l'aide de l'instruction SET PARTITION_PARTS.
Exemples de TABLE DE CRÉATION
Pour Google Cloud, créez une table avec le partitionnement AUTOMATIQUE par défaut :
CREATE TABLE customer ( custid INT NOT NULL DEFAULT 0, zip CHAR(5) NOT NULL)
Créer une table sans partitionnement :
CREATE TABLE customer ( custid INT NOT NULL DEFAULT 0, zip CHAR(5) NOT NULL) AVEC NOPARTITION ;
Créez une table partitionnée HASH avec 16 partitions réparties en fonction de la colonne emp_no :
CREATE TABLE employee ( emp_no INTEGER NOT NULL NOT DEFAULT, emp_name CHAR(32) NOT NULL NOT DEFAULT, dept_no INTEGER, emp_rating INTEGER) AVEC JOURNALISATION, PARTITION = (HASH ON emp_no 16 PARTITIONS) ;
Créer une table partitionnée HASH en utilisant le nombre de partitions par défaut :
CREATE TABLE employee ( emp_no INTEGER NOT NULL NOT DEFAULT, emp_name CHAR(32) NOT NULL NOT DEFAULT, dept_no INTEGER, emp_rating INTEGER) AVEC JOURNALISATION, PARTITION = (HASH ON emp_no DEFAULT PARTITIONS) ;
Créez un tableau dans lequel le numéro de sécurité sociale est crypté à l'aide d'un cryptage AES 128 bits. Ne pas saler la valeur (ajouter 16 octets de bits aléatoires au champ pour obscurcir davantage la valeur cryptée) :
CREATE TABLE socsectab ( fname CHAR(10), lname CHAR(20), socsec CHAR(11) ENCRYPT NOSALT ) WITH ENCRYPTION=AES128, PASSPHRASE='this is a secret', NOPARTITION ;
Créez une table dans laquelle les données de la colonne c2, qui contient les données salariales, sont cryptées à l'aide d'un cryptage AES 256 bits. Le sel est ajouté au champ par défaut :
CREATE TABLE t1 ( c1 CHAR(20) NOT NULL, c2 MONEY ENCRYPT) WITH ENCRYPTION=AES256, PASSPHRASE='decoder ring', NOPARTITION ;
Créez une table avec un index min-max échantillonné sur deux colonnes :
CREATE TABLE sales_fact ( sales_date ANSIDATE, value INTEGER2, quantité FLOAT8) WITH MINMAX=(sales_date, quantity), MINMAX_SAMPLES ;
Créez une table dont les colonnes adresse et salaire sont masquées :
CREATE TABLE employee( nom VARCHAR(20), address VARCHAR(20) MASKED, salaire FLOAT MASQUÉ AS 0) ;
Créez un tableau partitionné dont les lignes sont réparties automatiquement (c'est-à-dire de manière aléatoire) :
CREATE TABLE employee ( emp_no INTEGER NOT NULL NOT DEFAULT, emp_name CHAR(32) NOT NULL NOT DEFAULT, dept_no INTEGER, emp_rating INTEGER) AVEC PARTITION = (8 PARTITIONS AUTOMATIQUES) ;
Créez la table "films" sans partitionnement :
CREATE TABLE movies AS SELECT * FROM cinema WITH NOPARTITION ;
Créez la table "livres" avec le partitionnement AUTOMATIQUE par défaut :
CREATE TABLE books AS SELECT * FROM titles ;
