Exécution du partitionnement de table

Dans un système multi-hôte, chaque serveur d'index est généralement affecté à son propre hôte pour des performances maximales. SAP HANA prend en charge les différentes façons suivantes de distribuer les données entre les hôtes :

• Une table partitionnée fractionne ses données en plusieurs blocs (partitions) et ces partitions peuvent être stockées sur différents serveurs d'index.

• Différentes tables peuvent être affectées à différents serveurs d'index.

• Une table peut être répliquée sur plusieurs serveurs d'index pour améliorer les performances des requêtes et des jointures.

Lorsque vous créez de nouvelles tables ou partitions, elles sont distribuées sur les hôtes disponibles par le système. Par défaut, une méthode de distribution "round-robin" est utilisée, mais les tables peuvent également être positionnées à l'aide des règles de placement des tables ou en spécifiant un numéro d'hôte et de port avec l'instruction SQL CREATE TABLE dans la clause d'emplacement. Cela donne au développeur un contrôle complet sur le positionnement des tables individuelles.

Des applications spécifiques peuvent avoir des règles de répartition de table prédéfinies et, dans certains cas, des fichiers de configuration et de la documentation sont disponibles dans les notes SAP pour vous aider à configurer les règles de partitionnement et de placement des tables nécessaires.

La fonctionnalité de partitionnement de la base de données SAP HANA fractionne horizontalement les tables stockées en colonnes en sous-tables ou partitions disjonctives. De cette façon, les grandes tables peuvent être décomposées en parties plus petites et plus gérables.

Le partitionnement est disponible uniquement pour les tables situées dans le stockage en colonnes. Le stockage en lignes ne prend pas en charge le partitionnement.

Le partitionnement de table est transparent pour l'application de sorte que les applications fonctionnent correctement avec toutes les stratégies de partitionnement. Néanmoins, le partitionnement peut avoir un impact sur les performances, ce qui peut faire une différence pour l'utilisateur final et la charge du système, à la fois de manière positive et négative. Pour minimiser le risque de régressions de performance, il est important de mettre en œuvre une bonne stratégie de partitionnement.

Le partitionnement est transparent pour les requêtes SQL et les instructions du langage de manipulation de données (DML). Les instructions de définition de données supplémentaires (DDL) suivantes sont disponibles pour le partitionnement :

• Exécuter l'opération Delta Merge sur certaines partitions
• Créer des partitions de table
• Repartitionner les tables
• Fusionner les partitions dans une table
• Ajouter ou supprimer des partitions
• Déplacer les partitions vers d'autres hôtes

Lorsqu'une table est partitionnée, le fractionnement est effectué de telle sorte que chaque partition contienne un ensemble différent de lignes de la table. Plusieurs alternatives sont disponibles pour indiquer la manière dont les lignes sont affectées aux partitions d'une table, par exemple, le partitionnement de hachage, le partitionnement tourniquet ou le partitionnement par plage.

Dans la figure Exemples de partitionnement de table, la table HA201_DEMO_TABLE est créée avec trois partitions. La spécification de partitionnement mononiveau est HASH sur la colonne Hay.

L'exemple ci-dessus crée une nouvelle table partitionnée lors de la création. Dans la vie réelle, il se peut également que vous deviez fusionner une ou plusieurs tables partitionnées ou partitionner une table existante. Les cas d'utilisation peuvent être que la table se rapproche de la limite de 2 milliards d'enregistrements ou que la performance de la requête n'est pas optimale. À l'aide des instructions SQL mentionnées, vous pouvez fusionner des tables partitionnées ou partitionner des tables existantes dans la base de données SAP HANA.

Il n'y a pas de nouveau partitionnement automatique lorsque les valeurs seuils sont dépassées. Au lieu de cela, il est proposé lors de la prochaine exécution du processus de redistribution.

Les valeurs saisies pour le partitionnement doivent être cohérentes avec l'infrastructure physique, en particulier le nombre de nœuds de serveur disponibles.

Si un nouveau partitionnement est nécessaire, les tables ne sont repartitionnées qu'en doublant le nombre de partitions (initiales) existantes. Cette opération est effectuée pour des raisons de performance. Le nombre maximal de partitions (de premier niveau) atteint par ce processus est défini par le paramètre global.ini > [table_placement] > max_partitions (par défaut : 12).

Par défaut, le système ne crée pas plus de partitions que le nombre d'hôtes disponibles (ou plus précisément d'emplacements possibles). Par exemple, si INITIAL_PARTITIONS est défini sur 3, mais que la base de données SAP HANA distribuée a cinq emplacements possibles, le repartitionnement de trois à six partitions n'a pas lieu. Une table peut avoir plusieurs partitions par hôte si le paramètre global.ini > [table_placement] > max_partitions_limited_by_locations est défini sur false (valeur par défaut : true). Cette règle n'est pas prise en compte si un nombre plus élevé de partitions de premier niveau est requis pour les groupes de partitions contenant plus de 2 milliards d'enregistrements (global.ini > [table_placement] > max_rows_per_partition, valeur par défaut = 2 000 000 000).

Si une table est distribuée à plusieurs partitions, elle affiche l'hôte qui stocke chacune de ces partitions. Les partitions existantes peuvent être déplacées vers différents hôtes en générant un plan de redistribution spécifique. Vous pouvez également équilibrer la répartition des tables après avoir ajouté de nouveaux hôtes au système. Contrôlez, optimisez, comprimez, défragmentez, chargez la table, Delta Merge et évaluez le nouveau partitionnement des tables qui ne sont pas partitionnées sur d'autres hôtes également.

Pour créer un plan de partitionnement optimal, vous devez essayer de suivre les meilleures pratiques de partitionnement de table dans la figure « Meilleures pratiques pour le partitionnement de table ».

• Limiter le nombre de tables partitionnées

  Ne partitionnez les tables que si vous voyez un avantage clair sans régressions significatives.

• Maintenez le nombre de partitions par table bas.

  Un nombre inutilement élevé de partitions entraîne des frais généraux car certaines requêtes peuvent avoir à accéder à toutes les partitions pour trouver les données :

  • Un grand nombre de canaux réseau sont ouverts et le système risque donc d'atteindre la limite maximale de canaux (note SAP : 2222200) et d'aboutir à des interruptions liées au réseau.

  • Certaines opérations telles que la détermination des statistiques de colonne (note SAP : 2114710) doivent être exécutées individuellement pour chaque partition.

  Prenez donc en compte les règles générales suivantes avant de définir un certain nombre de partitions :

  • Si vous partitionnez des tables en raison de la limite de 2 milliards, il est généralement acceptable si des partitions individuelles contiennent jusqu'à 1,5 milliard d'enregistrements (moins si vous vous attendez à une croissance future significative).

  • Si vous partitionnez par date, vous devez éviter d'utiliser des plages granulaires (comme des jours ou des semaines) entraînant un nombre élevé de partitions.

  • Si vous utilisez une partition RANGE sur des colonnes avec des données qui ne sont pas réparties uniformément (comme une colonne de tranches de numéros avec plusieurs tranches de numéros différentes), vous devez vérifier la répartition des valeurs réelles et définir les limites de plage en conséquence.

• Maintenez le nombre de colonnes clés bas.

  Le moins de colonnes de clé de partition possible. Il est utile de limiter le nombre de colonnes de clés de partition au minimum pour les raisons suivantes :

  • L'élagage de partition de hachage ne peut être utilisé que si toutes les colonnes de partitionnement sous-jacentes sont spécifiées avec "=" ou "IN" dans la clause WHERE.

  • La détermination de l'élagage de la partition peut prendre beaucoup de temps si de nombreuses clés de partition sont impliquées.

    Pour plus d'informations, voir la note SAP : 2000002 « Quelles sont les approches habituelles pour ajuster des instructions SQL coûteuses en temps ? » et "Temps d'exécution plus élevé que prévu, impact négatif du partitionnement existant".

  Dans le cas du partitionnement de hachage, il est souvent utile d'utiliser uniquement la colonne de clé primaire la plus sélective comme colonne de clé de partition.

• Pour SAP Suite sur HANA, conservez toutes les partitions sur le même hôte.

  Dans les environnements SAP Suite on HANA de scale-out, il est avantageux de conserver toutes les partitions d'une table sur le même hôte. À partir de SPS08, cela peut être réalisé avec une configuration de placement de table appropriée.

  Comme option de secours, vous pouvez utiliser un partitionnement de premier niveau fictif (par exemple, sur MANDT) et effectuer le partitionnement réel au deuxième niveau. Dans ce cas, toutes les partitions sont situées sur le même hôte.

• Règles de repartitionnement

  Lors du nouveau partitionnement, sélectionnez le nouveau nombre de partitions comme multiple ou diviseur du nombre actuel de partitions.

  Si une table est déjà partitionnée, il est plus efficace de choisir un nouveau nombre de partitions qui est un facteur 2 multiple ou diviseur du nombre actuel de partitions (par exemple 4 -> 8 ou 6 -> 3 partitions). Ce n'est que dans ce cas que le repartitionnement peut avoir lieu en parallèle sur différents groupes de partitions et hôtes ("split/merge parallèle").

• Éviter les contraintes uniques

  Lors de la création de partitions, essayez d'éviter de créer des contraintes uniques supplémentaires. Évitez les tables de partitionnement avec des contraintes uniques supplémentaires (comme un index secondaire unique), car les contrôles d'unicité imposent des frais généraux importants.

  Remarque

  Note SAP : 2000002 fournit des informations sur l'optimisation SQL de SAP HANA et décrit les symptômes qui peuvent être introduits par un partitionnement inadéquat.

La vue système M_CS_PARTITIONS fournit des informations sur la partition des tables de colonnes.

1
select * from "M_CS_PARTITIONS" where "TABLE_NAME" = 'sap.hana.democontent.epm.data::PO.Item';

La sortie affiche le nombre de partitions. Dans l'exemple de la figure Éditeur SQL : Afficher les informations de la table partitionnée, nous avons trois partitions.

La vue système M_CS_TABLES fournit des données d'exécution pour des tables de colonnes ou des partitions de tables de colonnes.

1
select * from "M_CS_PARTITIONS" where "TABLE_NAME" = 'sap.hana.democontent.epm.data::PO.Item';

La sortie affiche l'hôte sur lequel se trouve la partition et la quantité de mémoire utilisée par la table.

La vue système M_EFFECTIVE_TABLE_PLACEMENT fournit des informations sur l'emplacement de placement de la table. Cette vue contient également des informations sur les seuils de partitionnement. Vous pouvez afficher le(s) site(s) valide(s) en fonction de la configuration, les valeurs réelles pour chaque paramètre de partitionnement et, dans les colonnes _MATCH correspondantes, le motif (règle de comparaison) pour ces sites.

Les informations de table sont également disponibles dans le cockpit SAP HANA. Dans l'application Afficher répartition de table actuelle, recherchez la table requise et sélectionnez-la. Dans la fenêtre pop-up, sélectionnez l'option Afficher données d'exécution. Dans l'écran Données d'exécution, la définition de table est affichée par défaut. Cliquez sur le bouton Partitions pour obtenir une synthèse de la manière dont la table est partitionnée et de l'emplacement des partitions. La plage de partition est également affichée.

Pour garantir la cohérence des tables partitionnées, exécutez des contrôles et des instructions de réparation, si nécessaire.

Vous pouvez appeler des contrôles généraux et de cohérence des données pour les tables partitionnées afin de vérifier, par exemple, que la spécification de partition, les métadonnées et la topologie sont correctes.