Article
· Fév 14, 2023 4m de lecture

Dans quels cas utiliser le stockage en colonne

Avec InterSystems IRIS 2022.2, nous avons introduit le stockage en colonne comme une nouvelle option pour la persistance de vos tables IRIS SQL qui peut booster vos requêtes analytiques d'un ordre de grandeur. La capacité est marquée comme expérimentale dans les versions 2022.2 et 2022.3, mais passera à une capacité de production entièrement prise en charge dans la prochaine version 2023.1.

La documentation du produit et cette vidéo d'introduction, décrivent déjà les différences entre le stockage en ligne, toujours la valeur par défaut sur IRIS et utilisé dans l'ensemble de notre clientèle, et le stockage en table en colonnes et fournissent des conseils de haut niveau sur le choix de la disposition de stockage appropriée pour votre cas d'utilisation. Dans cet article, nous développerons ce sujet et partagerons quelques recommandations basées sur les principes de modélisation des pratiques de l'industrie, les tests internes et les commentaires des participants au Early Access Program. 

En règle générale, nos conseils sur le choix d'une disposition de table appropriée pour votre schéma IRIS SQL sont les suivants :

  1. Si vous déployez une application qui tire parti d'IRIS SQL ou d'objets, telle qu'une application de traitement EHR, ERP ou transactionnelle, il n'est pas nécessaire de modifier sa disposition de stockage de lignes actuelle en une disposition en colonnes. La plupart des requêtes SQL émises pour les applications d'utilisateur final ou les transactions par programme ne récupèrent ou ne mettent à jour qu'un nombre limité de lignes, et les lignes de résultat correspondent généralement aux lignes de table, avec une utilisation très limitée des fonctions d'agrégation. Dans de tels cas, les avantages offerts par le stockage en colonnes et le traitement des requêtes vectorisées ne s'appliquent pas.
  2. Si une telle application intègre également des analyses opérationnelles, envisagez d'ajouter des indices en colonnes si les performances actuelles des requêtes analytiques correspondantes ne sont pas satisfaisantes. Cela inclut, par exemple, des tableaux de bord montrant l'inventaire actuel ou des rapports financiers de base sur des données en direct. Recherchez les champs numériques utilisés dans les agrégations (par exemple, les quantités, les devises) ou les champs à cardinalité élevée utilisés dans les conditions de plage (par exemple, les horodatages). Un bon indicateur de ces opportunités est l'utilisation actuelle d'index bitmap pour accélérer le filtrage d'un grand nombre de lignes, généralement sur des champs à faible cardinalité (par exemple, des champs catégoriels ou ordinaux). Il n'est pas nécessaire de remplacer ces index bitmap ; les index colonnaires supplémentaires fonctionnent bien en conjonction avec eux et sont destinés à éviter les lectures excessives à partir de la carte principale ou des cartes d'index régulières (un seul gref par ligne).
  3. Si vos tables IRIS SQL contiennent moins d'un million de lignes, il n'est pas nécessaire d'envisager le stockage en colonnes. Nous préférons ne pas nous limiter à des nombres spécifiques, mais les avantages du traitement des requêtes vectorisées ne feront probablement pas de différence dans ces plages basses.
  4. Si vous déployez un schéma IRIS SQL pour Data Warehouse, Business Intelligence ou des cas d'utilisation analytiques similaires, envisagez de le remplacer par défaut par le stockage en colonnes. Les schémas en étoile, les schémas en flocon de neige ou d'autres structures de table dénormalisées ainsi que l'utilisation généralisée d'index bitmap et l'ingestion de lots sont de bons indicateurs pour ces cas d'utilisation. Les requêtes analytiques qui bénéficieront le plus du stockage en colonnes sont celles qui analysent un grand nombre de lignes et agrègent les valeurs sur celles-ci. Lors de la définition d'une "table en colonnes", IRIS recourra de manière transparente à une disposition des lignes pour les colonnes de cette table qui ne conviennent pas au stockage en colonnes, telles que les flux, les chaînes longues ou les champs en série. IRIS SQL prend entièrement en charge ces dispositions de table mixtes et utilisera le traitement des requêtes vectorisées pour les parties éligibles du plan de requête. La valeur ajoutée des index bitmap sur les tables en colonnes est limitée, ils peuvent donc être omis.

Le kilométrage variera en fonction des paramètres environnementaux et liés aux données. Par conséquent, nous recommandons vivement aux clients de tester les différentes dispositions dans une configuration représentative. Les index en colonnes sont faciles à ajouter à une table régulière organisée en lignes et fourniront rapidement une perspective réaliste sur les avantages des performances des requêtes. Ceci, associé à la flexibilité des dispositions de table mixtes, est un différenciateur clé d'InterSystems IRIS qui aide les clients à obtenir une amélioration des performances d'un ordre de grandeur.

Nous avons l'intention de rendre ces recommandations plus concrètes au fur et à mesure que nous acquérons une expérience plus réelle sur la version de production complète. De toute évidence, nous pouvons fournir des conseils plus concrets basés sur le schéma et la charge de travail réels des clients via le programme d'accès anticipé et les engagements POC, et attendons avec impatience les commentaires des clients et des membres de la communauté. Columnar Storage fait partie de la licence InterSystems IRIS Advanced Server et est également activé dans l'édition communautaire d'InterSystems IRIS et IRIS for Health. Pour un environnement de démonstration entièrement scripté, veuillez vous référer à ce référentiel GitHub.

Discussion (0)2
Connectez-vous ou inscrivez-vous pour continuer