Avant de commencer
nyc_taxi.trips_small_inferred. Créez-la et chargez-la si ce n’est pas déjà fait :
Configurer l’ensemble de données d’exemple
Configurer l’ensemble de données d’exemple
Le fichier Parquet source fait environ 5,8 Go. Son chargement peut prendre plusieurs minutes, selon votre réseau et les ressources disponibles.
Vue d’ensemble du processus
- Exécutez trois requêtes de charge indépendantes sur le schéma inféré afin d’établir une référence.
- Créez une table avec des types de colonnes plus précis, chargez les mêmes données, puis réexécutez les requêtes.
- Créez une autre table avec le même schéma optimisé et une clé de tri, puis réexécutez les requêtes.
Définir la charge de travail de référence
Ces paramètres permettent de garantir la comparabilité des exécutions répétées lors des tests. Restaurez leurs valeurs précédentes une fois les mesures terminées.
system.query_log.
Filtrer selon la vitesse calculée du trajet
Agréger les trajets sur une plage de dates
Filtrer par nombre de passagers
Les trois requêtes ont lu environ 329 millions de lignes, soit un nombre proche du nombre de lignes de la table. Cela permet d’améliorer deux aspects de la charge de travail : réduire le coût de traitement des colonnes sélectionnées, puis, lorsque les filtres le permettent, réduire le nombre de lignes sélectionnées.
Optimiser le schéma
Évitez les colonnes Nullable inutiles
Nullable stocke un masque de nullité en plus de ses valeurs. Conservez Nullable lorsque la distinction entre une valeur nulle et la valeur par défaut du type est pertinente, mais évitez-le pour les colonnes dont la présence d’une valeur est garantie.
Comptez les valeurs nulles dans les colonnes utilisées par le schéma d’exemple :
ratecode_id, mta_tax et payment_type contiennent des valeurs nulles dans cet ensemble de données. Le schéma optimisé conserve Nullable pour ces colonnes et le supprime pour les autres.
Utiliser LowCardinality pour les valeurs répétées
LowCardinality utilise l’encodage par dictionnaire et peut réduire le stockage et le traitement des colonnes contenant de nombreuses valeurs répétées. Vérifiez le nombre de valeurs distinctes avant de l’appliquer :
LowCardinality, mais il convient tout de même d’en mesurer l’effet sur la charge de travail. Environ 10 000 valeurs distinctes constituent un bon point de départ pour identifier les candidates, et non une limite fixe.
Choisissez des types de données plus précis
Int64 ou un Float64 inféré :
UInt8, même si passenger_count atteint sa valeur maximale de 255. L’exemple utilise également Float32 pour trip_distance et Decimal32 pour les valeurs monétaires. Toutes les valeurs de cet ensemble de données se situent dans les plages cibles, et l’exemple accepte la précision réduite des nombres à virgule flottante ainsi qu’une précision monétaire au centime, car sa charge de travail compare des résultats agrégés. Conservez les types source plus larges lorsque les valeurs source exactes sont nécessaires. L’exemple remplace les colonnes DateTime64 déduites par DateTime dans le même fuseau horaire UTC, car les requêtes de l’exemple ne nécessitent pas de précision à la fraction de seconde.
Ces choix sont spécifiques à cet ensemble de données. Vérifiez les exigences de plage, de précision et de nullabilité des données de production avant d’appliquer les mêmes modifications.
Appliquer les modifications du schéma
nyc_taxi.trips_small_inferred par nyc_taxi.trips_small_no_pk, puis réexécutez les trois requêtes. L’exemple d’origine a donné les résultats représentatifs suivants :
Les requêtes lisent toujours le même nombre de lignes, mais le schéma optimisé réduit la quantité de données représentée par ces lignes. La durée des requêtes et le pic de mémoire s’améliorent donc sans modifier la sélection des données.
Comparez la taille sur disque des deux tables :
Optimiser la clé de tri
MergeTree, la clé de tri détermine la façon dont les lignes sont organisées sur le disque. ClickHouse crée un index primaire creux sur cet ordre afin d’ignorer les granules qui ne peuvent pas répondre aux filtres d’une requête. Contrairement à une clé primaire dans de nombreuses bases de données transactionnelles, elle ne garantit pas l’unicité.
La clé de tri doit refléter les filtres utilisés dans les requêtes importantes et récurrentes. L’ordre des colonnes est important : une clé est plus efficace lorsque la requête filtre sur un préfixe utile. Les colonnes à faible cardinalité constituent parfois de bonnes premières colonnes lorsqu’elles sont fréquemment utilisées comme filtres, et une composante temporelle est souvent utile pour les charges de travail basées sur le temps. Pour des conseils détaillés sur le choix de la clé, consultez Choisir une clé primaire.
Pour cet exemple, utilisez (passenger_count, pickup_datetime, dropoff_datetime). passenger_count possède peu de valeurs distinctes et apparaît dans le filtre sur le nombre de passagers, tandis que pickup_datetime apparaît dans l’agrégation sur une plage de dates. Bien que pickup_datetime ne soit pas la première colonne, ClickHouse peut toujours utiliser les valeurs des colonnes suivantes de la clé pour exclure des données lorsque la première colonne n’est soumise à aucune contrainte. Le filtrage sur un préfixe utile de la clé de tri permet généralement un élagage plus efficace.
Appliquer la modification de la clé de tri
nyc_taxi.trips_small_pk, puis réexécutez les trois requêtes.
Comparez les résultats
L’optimisation du schéma réduit l’espace de stockage et rend le traitement des valeurs sélectionnées moins coûteux. La clé de tri apporte l’amélioration supplémentaire la plus importante pour l’agrégation sur une plage de dates, car ClickHouse peut ignorer les granules en dehors de cette plage. Le filtre sur le nombre de passagers lit également moins de lignes, car il s’applique à la première colonne de la clé. Le filtre sur la vitesse calculée lit toujours l’intégralité de la table, car il est dérivé de
pickup_datetime, dropoff_datetime et trip_distance, plutôt que d’un préfixe utile de la clé de tri.
Examinez l’agrégation sur une plage de dates avec EXPLAIN indexes = 1 :
Dans ClickHouse 25.9 et les versions ultérieures, ces paramètres garantissent que
EXPLAIN indique les index utilisés ainsi que les parties et les granules qu’ils permettent d’éliminer.Appliquez la méthode à votre charge de travail
- Relevez la durée de référence, le nombre de lignes et d’octets lus, ainsi que le pic de mémoire.
- Vérifiez si les colonnes sélectionnées utilisent des types inutilement larges ou permissifs.
- Appliquez les modifications de schéma et mesurez leurs effets sans modifier la disposition des données.
- Testez une clé de tri fondée sur les filtres utilisés par les requêtes importantes et récurrentes.
- Comparez les données sélectionnées avec
EXPLAIN indexes = 1, puis réexécutez les requêtes de référence dans des conditions comparables.