Introduction
Nous améliorons continuellement les performances de Rockset et évaluons différentes offres matérielles pour trouver celle offrant le meilleur rapport qualité-prix pour l’ingestion de streaming et les requêtes à faible latence.
Grâce à l’amélioration continue des performances, nous avons publié un logiciel qui exploite les processeurs Intel® Xeon® Scalable de 3e génération, nommé Ice Lake. Avec le passage à un nouveau matériel, les requêtes Rockset sont désormais 84 % plus rapides qu’auparavant sur le Star Schema Benchmark (SSB), une référence standard de l’industrie pour les performances des requêtes typiques des applications de données.
Bien que les logiciels exploitant Intel Ice Lake aient contribué à des performances plus rapides sur le SSB, plusieurs autres améliorations de performances ont bénéficié aux modèles de requêtes courants dans les applications de données :
- Expressions de table communes matérialisées (CTE) : Rockset matérialise les CTE pour réduire le temps d’exécution global des requêtes.
- Pushdown de prédicat basé sur des statistiques : Rockset utilise des statistiques de collecte pour adapter sa stratégie de push-down de prédicat, ce qui entraîne des requêtes jusqu’à 10 fois plus rapides.
- Cache de magasin de lignes : un cache MVCC (Multiversion Concurrency Control) a été introduit pour le magasin de lignes afin de réduire la surcharge des méta-opérations et ainsi la latence des requêtes lorsque l’ensemble de travail rentre dans la mémoire.
Dans ce blog, nous décrirons la configuration SSB, les résultats et les améliorations de performances.
Configuration et résultats
Le SSB est une référence bien établie basée sur TPC-H qui capture les modèles de requêtes courants pour les applications de données.
Pour comprendre l’impact d’Intel Ice Lake sur les charges de travail d’analyse en temps réel, nous avons effectué une comparaison avant et après à l’aide du SSB. Pour ce benchmark, Rockset a dénormalisé les données et a réduit la taille de l’ensemble de données à 100 Go et 600 millions de lignes de données, soit un facteur d’échelle de 100. Rockset a utilisé son instance virtuelle (VI) XLarge avec 32 vCPU et 256 Go de mémoire.
Le SSB est une suite de 13 requêtes analytiques. L’intégralité de la suite de requêtes s’est terminée en 733 ms sur Rockset avec Intel Ice Lake, contre 1 347 ms auparavant, ce qui correspond à une accélération globale de 84 %. D’après les résultats de l’analyse comparative, Rockset est plus rapide en utilisant Intel Ice Lake dans les 13 requêtes SSB et a été 95 % plus rapide sur la requête avec l’accélération la plus importante.
Figure 1 : Graphique comparant l’exécution de l’instance virtuelle Rockset XLarge sur les requêtes SSB avant et après l’utilisation d’Intel Ice Lake. La configuration est de 32 vCPU et 256 Go de mémoire.
Figure 2 : Graphique illustrant l’exécution de l’instance virtuelle Rockset XLarge sur les requêtes SSB avant et après l’utilisation d’Intel Ice Lake.
Nous avons postulé regroupement à l’index en colonnes et a exécuté chaque requête 1 000 fois sur un cache de système d’exploitation réchauffé, indiquant la durée d’exécution moyenne. Aucune forme de mise en cache des résultats de requête n’a été utilisée pour l’évaluation. Les heures sont signalées par le serveur API de Rockset.
Améliorations des performances du Rockset
Nous mettons en évidence plusieurs améliorations de performances qui offrent une meilleure prise en charge d’une gamme de modèles de requête trouvés dans les applications de données.
Expressions de table communes matérialisées (CTE)
Rockset matérialise les CTE pour réduire le temps global d’exécution des requêtes.
Les CTE ou sous-requêtes sont un modèle de requête courant. Le même CTE est souvent utilisé plusieurs fois dans l’exécution d’une requête, ce qui entraîne sa réexécution et augmente le temps d’exécution global. Vous trouverez ci-dessous un exemple de requête dans laquelle un CTE est référencé deux fois :
WITH maxcategoryprice AS
(
SELECT category,
Max(price) max_price
FROM products
GROUP BY category ) hint(materialize_cte = true)
SELECT c1.category,
sum(c1.amount),
max(c2.max_price)
FROM ussales c1
JOIN maxcategoryprice c2
ON c1.category = c2.category
GROUP BY c1.category
UNION ALL
SELECT c1.category,
sum(c1.amount),
max(c2.max_price)
FROM eusales c1
JOIN maxcategoryprice c2
ON c1.category = c2.category
GROUP BY c1.category
Avec les CTE matérialisés, Rockset n’exécute un CTE qu’une seule fois et met en cache les résultats pour réduire la consommation de ressources et la latence des requêtes.
Pushdown de prédicat basé sur les statistiques
Rockset utilise les statistiques de collecte pour adapter sa stratégie de poussée des prédicats, ce qui entraîne des requêtes jusqu’à 10 fois plus rapides.
Pour le contexte, un prédicat est une expression vraie ou fausse, généralement située dans la clause WHERE ou HAVING d’une requête SQL. Un refoulement de prédicat utilise le prédicat pour filtrer les données de la requête, rapprochant ainsi le traitement des requêtes de la couche de stockage.
Rockset organise les données dans un Indice Convergé™, un index de recherche, un index basé sur des colonnes et un magasin de lignes, pour une récupération efficace. Pour les requêtes de recherche hautement sélectives, Rockset utilise ses index de recherche pour localiser les documents correspondant aux prédicats, puis récupère les valeurs correspondantes dans le magasin de lignes.
Les prédicats d’une requête peuvent contenir des prédicats largement sélectifs ainsi que des prédicats étroitement sélectifs. Avec des prédicats largement sélectifs, Rockset lit davantage de données à partir de l’index, ralentissant ainsi l’exécution des requêtes. Pour éviter ce problème, Rockset a introduit des refoulements de prédicats basés sur des statistiques qui déterminent si le prédicat est largement sélectif ou étroitement sélectif en fonction des statistiques de collecte. Seuls les prédicats étroitement sélectifs sont poussés vers le bas, ce qui entraîne des requêtes jusqu’à 10 fois plus rapides.
Voici une requête qui contient des prédicats à la fois largement et étroitement sélectifs :
SELECT first name, last name, age
FROM students
WHERE last name= ‘Borthakur’ and age= ‘10’
Le nom de famille Borthakur est rare et constitue un prédicat étroitement sélectif ; l’âge de 10 ans est courant et constitue un prédicat largement sélectif. Le refoulement des prédicats basé sur les statistiques ne poussera que WHERE last name = ‘Borthakur’ pour accélérer le temps d’exécution.
Cache de magasin de lignes
Nous avons conçu un Contrôle de concurrence multiversion (MVCC) cache pour le magasin de lignes afin de réduire la surcharge des méta-opérations et ainsi la latence des requêtes lorsque l’ensemble de travail rentre dans la mémoire.
Considérons une requête de la forme :
SELECT name
FROM students
WHERE age = 10
Lorsque la sélectivité du prédicat est faible, nous utilisons l’index de recherche pour récupérer les identifiants de document pertinents (c’est-à-dire : WHERE age = 10), puis le magasin de lignes pour récupérer les valeurs du document et leurs colonnes (c’est-à-dire : nom).
Utilisations de Rockset RochesDB en tant que moteur de stockage intégré, stockant les documents sous forme de paires clé-valeur (c’est-à-dire : identifiant du document, valeur du document). RocksDB fournit un cache en mémoire, appelé cache de blocs, qui conserve en mémoire les blocs de données fréquemment consultés. Un bloc contient généralement plusieurs documents. RocksDB utilise une opération de recherche de métadonnées, composée d’une technique d’indexation interne et de filtres Bloom, pour trouver le bloc et la position à l’intérieur du bloc avec la valeur du document.
L’opération de recherche de métadonnées occupe une proportion importante de la mémoire de travail, ce qui a un impact sur la latence des requêtes. De plus, l’opération de recherche de métadonnées est utilisée dans l’exécution de chaque requête individuelle, ce qui entraîne une consommation de mémoire accrue dans les charges de travail QPS élevées.
Nous avons conçu un cache MVCC complémentaire maintenant un mappage direct de l’identifiant du document à la valeur du document pour le magasin de lignes, en contournant la mise en cache basée sur les blocs et l’opération de métadonnées. Cela améliore les performances des requêtes pour les charges de travail où l’ensemble de travail tient en mémoire.
Le différentiel de performances du cloud
Nous investissons continuellement dans les performances de Rockset et rendons les analyses en temps réel plus abordables et accessibles. Avec la sortie d’un nouveau logiciel exploitant les processeurs Intel® Xeon® Scalable de 3e génération, Rockset est désormais 84 % plus rapide qu’auparavant sur le Star Schema Benchmark.
Rockset est natif du cloud et les améliorations de performances sont automatiquement mises à la disposition des clients sans nécessiter de réglage de l’infrastructure ou de mises à niveau manuelles. Découvrez l’impact des améliorations de performances sur votre application de données en rejoignant le programme d’accès anticipé disponible ce mois-ci.
