Stockage en colonne en 2022.3

Comme vous vous en souvenez peut-être du Global Summit 2022 ou du webinaire de lancement 2022.2, nous lançons une nouvelle fonctionnalité passionnante à inclure dans vos solutions d'analyse sur InterSystems IRIS. Le stockage en colonnes introduit une autre façon de stocker vos données de table SQL qui offre une accélération d'ordre de grandeur pour les requêtes analytiques. Publié pour la première fois en tant que fonctionnalité expérimentale en 2022.2, le dernier Developer Preview 2022.3 comprend un tas de mises à jour qui, selon nous, valaient la peine d'être publiées ici.

Un récapitulatif rapide

Si vous n'êtes pas familier avec le stockage en colonnes, veuillez regarder cette brève vidéo d'introduction ou la session GS2022 sur le sujet. En bref, nous encodons les données de la table en morceaux de 64k valeurs par colonne en utilisant un nouveau type de données $vector. $vector est un type de données interne uniquement (pour l'instant) qui exploite des schémas de codage adaptatifs pour permettre un stockage efficace des données clairsemées et denses. L'encodage est également optimisé pour un tas d'opérations $vector dédiées, telles que le calcul d'agrégats, de regroupements et de filtres de blocs entiers de valeurs de 64k à la fois, en tirant parti des instructions SIMD lorsque cela est possible. 

Au moment de la requête SQL, nous tirons parti de ces opérations en créant un plan de requête qui fonctionne également sur ces morceaux, ce qui, comme vous pouvez l'imaginer, entraîne une réduction massive de la quantité d'E/S et du nombre d'instructions ObjectScript pour exécuter votre requête, par rapport au classique traitement ligne par ligne. Bien sûr, les E/S individuelles sont plus grandes et les opérations $vector sont un peu plus lourdes que les homologues à valeur unique du monde orienté ligne, mais les gains sont énormes. Nous utilisons le terme plans de requête vectorisés pour les stratégies d'exécution qui traitent des données $vector, en poussant des morceaux entiers à travers une chaîne d'opérations individuelles rapides.

Juste plus rapide

Surtout, les choses se sont accélérées. Nous avons élargi la compréhension de l'optimiseur des index en colonnes et vous verrez désormais plus de requêtes utiliser des index en colonnes, même si certains des champs demandés ne sont pas stockés dans un index en colonnes ou une carte de données. En outre, vous verrez qu'il combine des index en colonnes et des index bitmap dans un certain nombre de cas, ce qui est idéal si vous commencez par ajouter des index en colonnes à un schéma existant.

Le nouveau kit comprend également un ensemble de modifications dans la pile qui améliorent les performances, allant des optimisations à ces opérations $vector de bas niveau en passant par certaines améliorations du traitement des requêtes et un ensemble plus large de plans de requête vectorisés qui peuvent être parallélisés. Certaines méthodes de chargement des données, telles que les instructions INSERT .. SELECT, utiliseront désormais également un modèle tamponné que nous utilisions déjà pour créer des index et permettent désormais une création très performante de tables entières.

JOIN vectorisés

La fonctionnalité la plus intéressante que nous ayons ajoutée dans cette version est la prise en charge de JOINing de données en colonnes de manière vectorisée. En 2022.2, lorsque vous vouliez combiner les données de deux tables dans une requête, nous recourions toujours à une stratégie JOIN ligne par ligne robuste qui fonctionne aussi bien sur les données en colonnes que sur les données organisées en lignes. Désormais, lorsque les deux extrémités du JOIN sont stockées au format colonne, nous utilisons une nouvelle API du noyau pour les JOINDRE en mémoire, en conservant leur format $vector. Il s'agit d'une autre étape importante vers des plans de requête entièrement vectorisés, même pour les requêtes les plus complexes.

Voici un exemple de requête qui tire parti de la nouvelle fonction, en effectuant une auto-JOINTURE de l'ensemble de données New York Taxi que nous avons utilisé dans les démonstrations précédentes :

SELECT 
   COUNT(*), 
   MAX(r1.total_amount - r2.total_amount) 
FROM
   NYTaxi.Rides r1, 
   NYTaxi.Rides r2
WHERE 
   r1.DOLocationID = r2.PULocationID 
   AND r1.tpep_dropoff_datetime = r2.tpep_pickup_datetime 
   AND r2.DOLocationID = r1.PULocationID 
   AND r1.passenger_count > 2 
   AND r2.passenger_count > 2

Cette requête recherche des paires de voyages avec plus de 2 passagers, où le deuxième voyage a commencé là où le premier s'est terminé, exactement à la même heure et où le deuxième voyage a ramené un à l'endroit où le premier a commencé. Pas une analyse super utile, mais je n'avais qu'une seule vraie table dans ce schéma et la clé composite JOIN rendait cela un peu moins trivial. Dans le plan de requête de cette instruction, vous verrez des extraits tels que Apply vector operation %VHASH (pour construire la clé composite JOIN) et Read vector-join temp-file A, qui indiquent que notre nouveau menuisier vectorisé est en train de travailler ! Cela peut sembler être une petite pépite triviale dans un plan de requête assez long, mais cela implique beaucoup d'ingénierie intelligente sur les composants internes, et il existe un certain nombre de fournisseurs de bases de données en colonnes de haut niveau qui n'autorisent tout simplement aucun de cela et mettez de sévères contraintes sur la mise en page de votre schéma, alors s'il vous plaît REJOIGNEZ-NOUS pour nous JOINDRE à cela ! :-)

Lorsque le plan de requête continue à lire ce fichier temporaire, vous remarquerez peut-être qu'il y a encore du traitement ligne par ligne dans le travail post-jointure, ce qui nous amène à...

Et après?

Columnar Storage est toujours marqué comme "expérimental" en 2022.3, mais nous nous rapprochons de la préparation de la production et de cette vectorisation complète de bout en bout pour les requêtes multi-tables. Cela inclut le travail de post-jointure mentionné ci-dessus, une prise en charge plus large dans l'optimiseur de requête, un chargement encore plus rapide des tables en colonnes et d'autres améliorations de la jointure telles que la prise en charge de la mémoire partagée. En bref : c'est le moment idéal pour essayer tout cela pour la première fois avec l'ensemble de données New York Taxi dataset (maintenant sur IPM ou avec docker scripts)

en utilisant l'édition communautaire 2022.3, il vous suffit donc d'appuyer sur "Exécuter" au moment de la sortie de 2023.1 !

Si vous êtes intéressé par des conseils plus personnalisés sur la façon d'exploiter le stockage en colonnes avec vos propres données et requêtes, veuillez me contacter ou contacter directement votre équipe de compte, et nous nous rencontrerons peut-être au Global Summit 2023 ;-).