Partager via

Meilleures pratiques en termes d’optimisation de schéma

  • Article

Un schéma de table définit les noms et les types de données de toutes les colonnes de la table. Le schéma de table peut être défini lors de la création d’une table ou dans le cadre du processus d’ingestion des données en modifiant le mappage d’ingestion applicable. La manière dont un schéma de table est défini peut affecter considérablement les performances de votre requête. Le schéma idéal pour vos données dépend de nombreux facteurs, notamment le cas d’utilisation, les modèles d’accès aux données et les données spécifiques que vous envisagez de stocker. Cet article décrit les meilleures pratiques pour optimiser les performances en concevant des schémas efficaces.

les types de données ;

Pour plus d’informations sur les types de données, consultez la section type de données scalaire.

  • Les champs couramment utilisés doivent être des colonnes typées, et non de type dynamique.

  • Les propriétés JSON fréquemment recherchées ou agrégées dans une colonne dynamique doivent être converties en colonne régulière dans la table avec un type plus spécifique tel que chaîne, long ou réel.

  • Les colonnes éparses qui ne sont pas couramment utilisées pour le filtrage et l’agrégation doivent être collectées en tant que conteneur des propriétés dans une colonne dynamique à l’aide de la DropMappedFields transformation de mappage.

  • Les colonnes Date/Heure doivent être typées comme DateHeure, et non long ou d’autres types de données.

  • Le type décimal fournit une précision exacte, ce qui le rend le plus adapté aux applications financières et autres qui nécessitent une précision exacte. Toutefois, il est beaucoup plus lent que le type réel. Utilisez uniquement le type décimal lorsque c’est nécessaire.

  • Toutes les colonnes d'ID (identification) doivent être typées comme chaînes et non de chiffres. Ce type rend l’index beaucoup plus efficace et peut améliorer considérablement le temps de recherche. Il active également le partitionnement, car le partitionnement ne peut être défini que sur les colonnes de chaîne. Si les filtres de requête utilisés sur cette colonne ne sont que des égalités, par exemple si la colonne contient des guids, vous pouvez utiliser le profil d'encodage Identifier. Pour plus d’informations, consultez la section stratégie d’encodage.

Tables

  • Optimiser pour les tables étroites, qui sont préférées aux tables larges comportant des centaines de colonnes.
  • Pour éviter les jointures coûteuses lors des requêtes, dénormalisez les données de dimension en les enrichissant lors de l'ingestion. Si la table de dimension utilisée pour l’enrichissement est mise à jour et que le scénario nécessite la dernière valeur, utilisez des vues matérialisées pour conserver uniquement la dernière valeur.
  • Si plus de 20 colonnes sont éparses, c’est-à-dire que de nombreuses valeurs sont nulles, et que ces colonnes sont rarement utilisées pour des recherches ou des agrégations, regroupez les colonnes sous forme de conteneur des propriétés JSON dans une colonne dynamique à l’aide de la DropMappedFields transformation de mappage.

Indexation

Les champs qui ne sont jamais recherchés peuvent désactiver l’indexation. Utilisez la stratégie d'encodage avec le profil BigObject pour désactiver l'indexation sur les colonnes typées comme chaînes et dynamiques.

Contenu connexe