Share via

Stratégie de partitionnement

  • Article

La stratégie de partitionnement définit si et comment les étendues (partitions de données) doivent être partitionnées pour une table spécifique ou une vue matérialisée.

La stratégie déclenche un processus en arrière-plan supplémentaire qui a lieu après la création des étendues, après l’ingestion des données. Ce processus inclut la réutilisation des données à partir des étendues sources et la production d’étendues homogènes , dans lesquelles toutes les valeurs de la colonne désignée comme clé de partition résident dans une seule partition.

L’objectif principal de la stratégie de partitionnement est d’améliorer les performances des requêtes dans des scénarios pris en charge spécifiques.

Notes

Par défaut, lorsqu’une stratégie de partitionnement des données n’est pas définie (est null), les étendues sont partitionnées par heure de création (ingestion). Dans la plupart des cas, il n’est pas nécessaire de définir une stratégie de partitionnement des données.

Scénarios pris en charge

Voici les seuls scénarios dans lesquels la définition d’une stratégie de partitionnement des données est recommandée. Dans tous les autres scénarios, la définition de la stratégie n’est pas recommandée.

  • Filtres fréquents sur une cardinalité string ou une colonne moyenne ou guid élevée :
    • Par exemple : solutions multilocataires ou table de métriques où la plupart ou toutes les requêtes filtrent sur une colonne de type string ou guid, comme ou TenantId .MetricId
    • La cardinalité moyenne est d’au moins 10 000 valeurs distinctes.
    • Définissez la clé de partition de hachage sur la string colonne ou guid et définissez la propriété sur PartitionAssigmentModeuniform.
  • Agrégations ou jointures fréquentes sur une colonne ou guid une cardinalité string élevée :
    • Par exemple, des informations IoT provenant de nombreux capteurs différents ou des enregistrements académiques de nombreux étudiants différents.
    • La cardinalité élevée est d’au moins 1 000 000 valeurs distinctes, où la distribution des valeurs dans la colonne est approximativement égale.
    • Dans ce cas, définissez la clé de partition de hachage comme étant la colonne fréquemment groupée par ou jointe, puis définissez la PartitionAssigmentMode propriétéByPartitionsur .
  • Ingestion de données en désordre :
    • Les données ingérées dans une table peuvent ne pas être triées et partitionnées en étendues (partitions) en fonction d’une colonne spécifique datetime qui représente l’heure de création des données et est couramment utilisée pour filtrer les données. Cela peut être dû à un remplissage à partir de fichiers sources hétérogènes qui incluent des valeurs datetime sur une longue période.
    • Dans ce cas, définissez la clé de partition datetime de plage uniforme sur la datetime colonne .
    • Si vous avez besoin de stratégies de rétention et de mise en cache pour s’aligner sur les valeurs datetime dans la colonne, au lieu de s’aligner sur l’heure d’ingestion, définissez la OverrideCreationTime propriété sur true.

Attention

  • Aucune limite codée en dur n’est définie sur le nombre de tables avec la stratégie de partitionnement définie. Toutefois, chaque table supplémentaire ajoute une surcharge au processus de partitionnement des données en arrière-plan qui s’exécute sur les nœuds du cluster. La définition d’une stratégie sur plus de tables entraîne l’utilisation d’un plus grand nombre de ressources de cluster et un coût plus élevé en raison des transactions de stockage sous-jacentes. Pour plus d’informations, consultez capacité.
  • Il n’est pas recommandé de définir une stratégie de partitionnement si la taille compressée des données par partition est censée être inférieure à 1 Go.
  • Le processus de partitionnement génère des artefacts de stockage résiduels pour toutes les étendues remplacées pendant le processus de partitionnement et pendant le processus de fusion. La plupart des artefacts de stockage résiduels sont censés être supprimés pendant le processus de nettoyage automatique. L’augmentation de la valeur de la MaxPartitionCount propriété augmente le nombre d’artefacts de stockage résiduels et peut réduire les performances de nettoyage.
  • Avant d’appliquer une stratégie de partitionnement sur une vue matérialisée, passez en revue les recommandations relatives à la stratégie de partitionnement des vues matérialisées.

Clés de partition

Les types de clés de partition suivants sont pris en charge.

Genre Type de colonne Propriétés de la partition Valeur de partition
Code de hachage string ou guid Function, MaxPartitionCount, Seed, PartitionAssignmentMode Function(ColumnName, MaxPartitionCount, Seed)
Plage uniforme datetime RangeSize, Reference, OverrideCreationTime bin_at(ColumnName, RangeSize, Reference)

Clé de partition de hachage

Si la stratégie inclut une clé de partition de hachage, toutes les étendues homogènes qui appartiennent à la même partition seront affectées au même nœud de données dans le cluster.

Notes

L’opération de partitionnement des données ajoute une charge de traitement importante. Nous vous recommandons d’appliquer une clé de partition de hachage sur une table uniquement dans les conditions suivantes :

  • Si la majorité des requêtes utilisent des filtres d’égalité (==, in()).
  • La majorité des requêtes agrège/jointure sur une colonne spécifique de type string ou guid qui est de grande dimension (cardinalité de 10M ou plus), telle qu’une device_IDcolonne , ou user_ID.
  • Le modèle d’utilisation des tables partitionnées est à haute charge de requête d’accès concurrentiel, par exemple dans les applications de supervision ou de tableau de bord.
  • Une fonction de hachage-modulo est utilisée pour partitionner les données.
  • Les données dans des étendues homogènes (partitionnés) sont ordonnées par la clé de partition de hachage.
    • Vous n’avez pas besoin d’inclure la clé de partition de hachage dans la stratégie d’ordre de ligne, si une clé est définie sur la table.
  • Les requêtes qui utilisent la stratégie de lecture aléatoire et dans lesquelles le shuffle key utilisé dans join, summarize ou make-series est la clé de partition de hachage de la table, sont censées être plus performantes, car la quantité de données requises pour se déplacer entre les nœuds de cluster est réduite.

Propriétés de la partition

Propriété Description Valeur(s) prise(s) en charge Valeur recommandée
Function Nom d’une fonction de hachage-modulo à utiliser. XxHash64
MaxPartitionCount Nombre maximal de partitions à créer (argument modulo de la fonction hash-modulo) par période. Dans la plage (1,2048]. Des valeurs plus élevées entraînent une surcharge accrue du processus de partitionnement des données sur les nœuds du cluster et un nombre plus élevé d’étendues pour chaque période. 128 est la valeur recommandée. Les valeurs plus élevées augmentent considérablement la surcharge liée au partitionnement des données après ingestion et la taille des métadonnées, et ne sont donc pas recommandées.
Seed Utilisez pour la randomisation de la valeur de hachage. Entier positif. 1, qui est également la valeur par défaut.
PartitionAssignmentMode Mode utilisé pour affecter des partitions aux nœuds du cluster. ByPartition: toutes les étendues homogènes (partitionnés) qui appartiennent à la même partition sont attribuées au même nœud.
Uniform: les valeurs de partition d’une étendue sont ignorées. Les étendues sont attribuées uniformément aux nœuds du cluster.		 Si les requêtes ne rejoignent pas ou ne s’agrègent pas sur la clé de partition de hachage, utilisez Uniform. Sinon, utilisez ByPartition.

Exemple de clé de partition de hachage

Clé de partition de hachage sur une stringcolonne de type -nommée tenant_id. Il utilise la XxHash64 fonction de hachage, avec MaxPartitionCount la valeur 128recommandée et la valeur par défaut Seed .1

{
  "ColumnName": "tenant_id",
  "Kind": "Hash",
  "Properties": {
    "Function": "XxHash64",
    "MaxPartitionCount": 128,
    "Seed": 1,
    "PartitionAssignmentMode": "Uniform"
  }
}

Clé de partition datetime de plage uniforme

Notes

Appliquez uniquement une clé de partition datetime de plage uniforme sur une datetimecolonne de type -dans une table quand il est peu probable que les données ingérées dans la table soient triées en fonction de cette colonne.

Dans ce cas, vous pouvez remaniez les données entre les étendues afin que chaque étendue inclue des enregistrements d’un intervalle de temps limité. Ce processus entraîne l’efficacité des filtres sur la datetime colonne au moment de la requête.

La fonction de partition utilisée est bin_at() et n’est pas personnalisable.

Propriétés de la partition

Propriété Description Valeur recommandée
RangeSize Constante timespan scalaire qui indique la taille de chaque partition datetime. Commencez par la valeur 1.00:00:00 (un jour). Ne définissez pas une valeur plus courte, car la table peut avoir un grand nombre de petites étendues qui ne peuvent pas être fusionnées.
Reference Constante datetime scalaire qui indique un point fixe dans le temps, selon lequel les partitions datetime sont alignées. Commencez par 1970-01-01 00:00:00. S’il existe des enregistrements dans lesquels la clé de partition datetime a null des valeurs, leur valeur de partition est définie sur la valeur de Reference.
OverrideCreationTime bool indiquant si les durées de création minimale et maximale de l’étendue du résultat doivent être remplacées par la plage des valeurs dans la clé de partition. La valeur par défaut est false. Définissez sur true si les données ne sont pas ingérées dans l’ordre d’heure d’arrivée. Par exemple, un fichier source unique peut inclure des valeurs datetime qui sont distantes, et/ou vous pouvez appliquer la rétention ou la mise en cache en fonction des valeurs datetime plutôt que de l’heure d’ingestion.

Lorsque OverrideCreationTime est défini sur true, les étendues peuvent être manquées dans le processus de fusion. Les étendues sont manquées si leur heure de création est antérieure à la Lookback période de la stratégie de fusion Étendues de la table. Pour vous assurer que les étendues sont détectables, définissez la propriété sur LookbackHotCache.

Exemple de partition datetime de plage uniforme

L’extrait de code montre une clé de partition de plage datetime uniforme sur une datetime colonne typée nommée timestamp. Il utilise datetime(2021-01-01) comme point de référence, avec une taille de 7d pour chaque partition, et ne remplace pas les heures de création des extensions.

{
  "ColumnName": "timestamp",
  "Kind": "UniformRange",
  "Properties": {
    "Reference": "2021-01-01T00:00:00",
    "RangeSize": "7.00:00:00",
    "OverrideCreationTime": false
  }
}

Par objet de stratégie

Par défaut, la stratégie de partitionnement des données d’une table est null, auquel cas les données de la table ne seront pas repartitionnées après leur ingestion.

La stratégie de partitionnement des données a les propriétés main suivantes :

  • PartitionKeys :

  • EffectiveDateTime :

    • Dateheure UTC à partir de laquelle la stratégie est effective.
    • Cette propriété est facultative. Si elle n’est pas spécifiée, la stratégie prend effet pour les données ingérées après l’application de la stratégie.

Attention

  • Vous pouvez définir une valeur datetime dans le passé et partitionner les données déjà ingérées. Toutefois, cette pratique peut augmenter considérablement les ressources utilisées dans le processus de partitionnement.
  • Dans la plupart des cas, il est recommandé de ne partitionner que les données nouvellement ingérées et d’éviter le partitionnement de grandes quantités de données historiques.
  • Si vous choisissez de partitionner des données historiques, envisagez de le faire progressivement, en définissant EffectiveDateTime sur une étape précédente datetime allant jusqu’à quelques jours chaque fois que vous modifiez la stratégie.

Exemple de partitionnement de données

Objet de stratégie de partitionnement des données avec deux clés de partition.

  1. Clé de partition de hachage sur une stringcolonne de type -nommée tenant_id.
    • Il utilise la XxHash64 fonction de hachage, avec MaxPartitionCount la valeur 128recommandée et la valeur par défaut Seed .1
  2. Clé de partition de plage datetime uniforme sur une datetime colonne de type nommée timestamp.
    • Il utilise datetime(2021-01-01) comme point de référence, avec une taille de 7d pour chaque partition.
{
  "PartitionKeys": [
    {
      "ColumnName": "tenant_id",
      "Kind": "Hash",
      "Properties": {
        "Function": "XxHash64",
        "MaxPartitionCount": 128,
        "Seed": 1,
        "PartitionAssignmentMode": "Uniform"
      }
    },
    {
      "ColumnName": "timestamp",
      "Kind": "UniformRange",
      "Properties": {
        "Reference": "2021-01-01T00:00:00",
        "RangeSize": "7.00:00:00",
        "OverrideCreationTime": false
      }
    }
  ]
}

Propriétés supplémentaires

Les propriétés suivantes peuvent être définies dans le cadre de la stratégie. Ces propriétés sont facultatives et nous vous recommandons de ne pas les modifier.

Propriété Description Valeur recommandée Valeur par défaut
MinRowCountPerOperation Cible minimale pour la somme du nombre de lignes des étendues sources d’une opération de partitionnement de données unique. 0
MaxRowCountPerOperation Cible maximale pour la somme du nombre de lignes des étendues source d’une opération de partitionnement de données unique. Définissez une valeur inférieure à 5M si vous voyez que les opérations de partitionnement consomment une grande quantité de mémoire ou de processeur par opération. 0, avec une cible par défaut de 5 000 000 enregistrements.
MaxOriginalSizePerOperation Cible maximale pour la somme de la taille d’origine (en octets) des étendues source d’une opération de partitionnement de données unique. Si les opérations de partitionnement consomment une grande quantité de mémoire ou de processeur par opération, définissez une valeur inférieure à 5 Go. 0, avec une cible par défaut de 5 368 709 120 octets (5 Go).

Processus de partitionnement des données

  • Le partitionnement des données s’exécute en tant que processus en arrière-plan post-ingestion dans le cluster.
    • Une table qui est continuellement ingérée dans est censée avoir toujours une « queue » de données qui n’a pas encore été partitionnée (étendues non homogènes).
  • Le partitionnement des données s’exécute uniquement sur des étendues à chaud, quelle que soit la valeur de la EffectiveDateTime propriété dans la stratégie.

Vous pouvez surveiller le partitionnement status de tables avec des stratégies définies dans une base de données à l’aide de la commande .show database extents partitioning statistics.

Capacité de partitionnement

  • Le processus de partitionnement des données entraîne la création d’autres étendues. Le cluster peut augmenter progressivement sa capacité de fusion d’étendues, afin que le processus de fusion des étendues puisse suivre.
  • S’il existe un débit d’ingestion élevé ou un nombre suffisant de tables pour lesquelles une stratégie de partitionnement est définie, le cluster peut augmenter progressivement sa capacité de partition Étendues, afin que le processus de partitionnement des étendues puisse suivre.
  • Pour éviter de consommer trop de ressources, ces augmentations dynamiques sont limitées. Vous devrez peut-être les augmenter progressivement et linéairement au-delà du plafond, s’ils sont entièrement utilisés.
    • Si l’augmentation des capacités entraîne une augmentation significative de l’utilisation des ressources du cluster, vous pouvez effectuer un scale-up du cluster/, soit manuellement, soit en activant la mise à l’échelle automatique.

Limites

  • Les tentatives de partitionnement de données dans une base de données qui a déjà plus de 5 000 000 étendues seront limitées.
    • Dans ce cas, la EffectiveDateTime propriété des stratégies de partitionnement des tables de la base de données est automatiquement retardée de plusieurs heures, ce qui vous permet de réévaluer votre configuration et vos stratégies.

Valeurs hors norme dans les colonnes partitionnée

  • Les situations suivantes peuvent contribuer à une distribution déséquilibrée des données entre les nœuds du cluster et dégrader les performances des requêtes :
    • Si une clé de partition de hachage inclut des valeurs beaucoup plus répandues que d’autres, par exemple, une chaîne vide ou une valeur générique (telle que null ou N/A).
    • Les valeurs représentent une entité (telle que tenant_id) qui est plus répandue dans le jeu de données.
  • Si une clé de partition datetime de plage uniforme a un pourcentage suffisant de valeurs qui sont « éloignées » de la majorité des valeurs de la colonne, la surcharge du processus de partitionnement des données est augmentée et peut entraîner de nombreuses petites étendues dont le cluster devra effectuer le suivi. Les valeurs datetime du passé ou du futur lointain sont un exemple d’une telle situation.

Dans ces deux cas, « corrigez » les données ou filtrez les enregistrements non pertinents dans les données avant ou au moment de l’ingestion, afin de réduire la surcharge du partitionnement des données sur le cluster. Par exemple, utilisez une stratégie de mise à jour.

Contenu connexe