Les bases de données colonnaires sont incroyablement rapides. Voici pourquoi.

FrançaisالعربيةDeutschEnglishEspañolहिन्दीBahasa Indonesia日本語한국어PortuguêsРусский中文
BBetter Stack
Computing/Software

Transcript

00:00:00bien que j'adore absolument Postgres, ce n'est pas le meilleur pour tout. Il existe un autre type de
00:00:04base de données appelé base de données en colonnes qui peut exécuter certaines requêtes jusqu'à 40 fois plus rapidement. Ces
00:00:10bases de données fonctionnent en stockant les colonnes ensemble plutôt que les lignes, ce qui vous apporte d'immenses avantages
00:00:15pour certains cas d'utilisation comme les plateformes d'analyse. Bien sûr, tout vient avec son lot de compromis,
00:00:20mais aujourd'hui, nous allons voir exactement ce que sont les bases de données en colonnes et comparer quelques requêtes avec
00:00:25Postgres pour voir les avantages et les inconvénients. Nous allons comparer Postgres avec ClickHouse et DuckDB,
00:00:31donc restez avec nous et à la fin, vous aurez une solide compréhension des bases de données orientées colonnes
00:00:36et de quand choisir la bonne technologie.
00:00:43Au début, j'ai dit qu'on pouvait exécuter certaines requêtes 40 fois plus vite, et c'est vrai. Si l'on prend une
00:00:49table de base de données — ici, j'ai chargé cent millions de lignes —, et que je lance une requête group by avec
00:00:55Postgres, cela prend environ 9,7 secondes à s'exécuter, car nous agrégeons le chiffre d'affaires de chaque
00:01:00ligne. Si nous exécutons la même requête sur le même jeu de données en utilisant une base de données en colonnes — et c'est
00:01:06littéralement exactement le même SQL, ClickHouse et DuckDB ayant une syntaxe SQL similaire à Postgres, donc vous vous
00:01:13sentirez en terrain connu —, ClickHouse arrive à 0,28 seconde et DuckDB à 0,24 seconde, soit plus de 40 fois plus rapide.
00:01:22Comment est-ce possible ? Cela semble incroyable, n'est-ce pas ? Les mêmes 100 millions de lignes traitées en seulement 0,24 seconde.
00:01:30Eh bien, les bases de données en colonnes font simplement des ordres de grandeur de travail en moins pour nous donner les mêmes résultats.
00:01:36Voyons une autre requête en action. Et petite note rapide, les gars, nous publions constamment du contenu sur l'IA et la tech,
00:01:42alors si c'est quelque chose que vous appréciez, pourquoi ne pas vous abonner à Better Stack ? Cette fois, nous comptons
00:01:47le nombre d'événements entre deux horodatages où le code pays est gb. Dans notre cas, nous regardons les données de
00:01:53mars. Résultats : Postgres à 5,9 secondes, ClickHouse à 0,06 seconde et DuckDB à 0,03 seconde. Mars contient
00:02:02environ 13 % du total des événements ici, donc Postgres a toujours besoin d'analyser des millions de lignes. Nous pourrions
00:02:09ajouter un index agressif pour améliorer les choses, mais cela ne nous approchera pas de ClickHouse et DuckDB. Alors pourquoi
00:02:15les magasins de colonnes sont-ils tellement plus rapides ici ? Eh bien, ClickHouse n'indexe pas du tout les lignes individuelles. Lorsque vous créez
00:02:20une table, vous lui donnez une clé de tri, et comme les données sont triées par horodatage, il divise les données triées en blocs de...
00:02:32...et il garde simplement une note du premier horodatage dans chacun d'eux. Pour 100 millions de lignes, cela fait environ 12 000 notes,
00:02:39ce qui est assez petit pour tenir en mémoire. Donc, lorsque nous demandons le mois de mars, il effectue une recherche rapide dans ces
00:02:44notes, trouve les blocs susceptibles de contenir mars et ne lit que ceux-là. Dans notre cas, cela fait 1 633 blocs sur
00:02:5212 208, et tout le reste sur le disque est ignoré. DuckDB fait quelque chose de similaire en conservant un minimum
00:03:00et un maximum pour chaque segment d'une colonne. Ainsi, nous pouvons examiner un segment, voir que les horodatages vont de janvier à
00:03:06février, et sauter tout le bloc sans le lire. Ajoutez à cela l'astuce précédente qui consiste à n'ouvrir
00:03:10que les colonnes nécessaires, et vous obtenez 0,03 seconde. Mais les choses prennent un virage à 180 degrés lorsque vous voulez
00:03:17sélectionner une seule ligne par ID. Cette simple requête en révèle long : Postgres prend deux millisecondes, ClickHouse 168
00:03:26millisecondes et DuckDB, de manière intéressante, est toujours à deux millisecondes. Postgres possède un index d'arbre binaire sur
00:03:32l'ID, il parcourt donc l'arbre, atterrit sur l'unique page qui contient la ligne et c'est réglé en seulement deux
00:03:37millisecondes. Mais avec ClickHouse, nous avons un problème : son seul index est cette clé de tri, et cette table est
00:03:43triée par horodatage d'abord et par ID ensuite. Donc, lorsque nous demandons un seul ID, il n'a aucune idée du bloc où se trouve
00:03:51cet ID, et il finit par vérifier chacun des 12 208 blocs. Et une fois qu'il a trouvé la ligne, il doit encore
00:03:57ouvrir les huit fichiers de colonnes et réassembler cette ligne, ce qui représente beaucoup de travail pour une
00:04:03requête aussi simple. Alors, comment DuckDB s'en sort-il ? Il a eu de la chance avec nos données : les ID ont été insérés en
00:04:09ordre, de sorte que le minimum et le maximum de chaque segment correspondent parfaitement à l'ID, et DuckDB peut sauter directement au bon
00:04:16bloc. Si les ID avaient été mélangés, il aurait parcouru toute la colonne, tout comme ClickHouse. Examinons maintenant
00:04:21la mise à jour d'une ligne. Nous avons une requête pour Postgres et DuckDB, et une version légèrement différente pour
00:04:26ClickHouse. Postgres arrive à cinq millisecondes, ClickHouse à 5,8 secondes, et DuckDB encore une fois à quelques dizaines
00:04:34de millisecondes. Postgres réécrit simplement une ligne et met à jour une entrée d'index. Dans ClickHouse, les fichiers de données
00:04:40sont immuables, ils ne sont jamais modifiés sur place. Donc, pour changer une seule valeur de chiffre d'affaires, il doit réécrire
00:04:46tout le fichier de la colonne de chiffre d'affaires pour ce segment de la table. ClickHouse vous oblige même à écrire cela comme un
00:04:51ALTER TABLE parce qu'il traite cela comme une mutation de toute la table. Il existe une mise à jour plus légère en
00:04:56version bêta, mais elle n'est prévue que pour un petit nombre de lignes (environ 10 % de la table au maximum). DuckDB se situe entre
00:05:03les deux, car son fichier peut être modifié sur place, de sorte qu'une mise à jour d'une seule ligne prend quelques dizaines
00:05:08de millisecondes. Enfin, comptons le nombre d'utilisateurs distincts dans notre table — encore une fois avec une légère
00:05:14variation de la requête pour ClickHouse. Les résultats sont : Postgres 38,4 secondes, ClickHouse 0,78 seconde
00:05:22et DuckDB moins d'une seconde. Encore une fois, Postgres souffre : agréger sur toute une table aussi grande
00:05:28nécessite simplement une quantité énorme de travail. Maintenant, on aimerait souvent utiliser des bases de données en colonnes pour des choses comme l'analyse,
00:05:34où l'agrégation de données à travers diverses colonnes est une tâche courante. Ici, nous avons examiné deux options : ClickHouse
00:05:41est un serveur hébergé, open source et disponible sur la plupart des grandes plateformes. Pour l'exécuter localement, vous devez lancer
00:05:47un serveur ClickHouse sur votre machine, ce qui se rapproche davantage du fonctionnement de Postgres. DuckDB, en revanche, ressemble plus à SQLite :
00:05:54c'est une bibliothèque qui s'exécute dans son propre processus et toute la base de données réside dans un seul fichier sur le disque. Ainsi,
00:06:00ce fichier peut être verrouillé pendant qu'une mise à jour est en cours, ce qui nuit à la concurrence. Toutes deux sont des bases de données
00:06:06en colonnes, mais adoptent des approches très différentes. Le choix de la base de données que vous finirez par utiliser dépend donc de bien plus
00:06:12que ce que je peux supposer ici. Il ne s'agit pas seulement de la vitesse de requête brute lors de l'exécution de démonstrations sur votre machine locale,
00:06:17il s'agit de la scalabilité, de la redondance et de l'extensibilité. Bien sûr, Postgres possède un riche écosystème de plugins pour
00:06:24étendre ses fonctionnalités de nombreuses manières, ce que vous pouvez voir dans cette prochaine vidéo.

Key Takeaway

Les bases de données colonnaires comme ClickHouse et DuckDB accélèrent considérablement les requêtes d'analyse sur des millions de lignes grâce au stockage par colonne et au saut de blocs, mais Postgres conserve l'avantage sur les recherches de lignes uniques et les mises à jour.

Highlights

  • Les bases de données colonnaires exécutent certaines requêtes analytiques jusqu'à 40 fois plus rapidement que Postgres.

  • ClickHouse traite une requête d'agrégation sur cent millions de lignes en 0,28 seconde, tandis que Postgres nécessite 9,7 secondes.

  • ClickHouse divise les données triées par horodatage en 12 208 blocs et conserve seulement les horodatages initiaux en mémoire.

  • DuckDB s'exécute sous forme de bibliothèque dans son propre processus avec une base de données résidant dans un fichier unique.

  • Postgres effectue une recherche par index d'arbre binaire sur une ligne unique en deux millisecondes, surpassant ClickHouse dans ce cas spécifique.

Timeline

Comparaison des performances sur les requêtes analytiques

  • Les bases de données colonnaires stockent les données par colonnes plutôt que par lignes pour optimiser l'analyse.
  • Une requête group by sur cent millions de lignes prend 9,7 secondes avec Postgres.
  • ClickHouse exécute la même requête en 0,28 seconde et DuckDB en 0,24 seconde.

Postgres gère les données par lignes, ce qui ralentit les opérations d'agrégation sur de grands volumes. Les bases de données en colonnes réduisent la quantité de travail nécessaire en n'ouvrant que les colonnes utiles à la requête. La syntaxe SQL reste similaire, ce qui facilite l'utilisation de ClickHouse et DuckDB pour des utilisateurs habitués à Postgres.

Mécanismes d'indexation et traitement des blocs

  • ClickHouse utilise une clé de tri pour diviser les données en blocs sans indexer les lignes individuelles.
  • Douze mille notes environ suffisent pour stocker le premier horodatage de chaque bloc pour cent millions de lignes.
  • DuckDB utilise des valeurs minimales et maximales par segment pour ignorer les blocs non pertinents.

L'indexation par blocs permet d'ignorer la majeure partie des données stockées sur le disque lors d'un filtrage par période. Pour un filtre sur le mois de mars, ClickHouse ne lit que 1 633 blocs sur 12 208 et ignore tout le reste. Cette méthode de saut de segments permet d'atteindre des temps d'exécution de l'ordre de quelques centièmes de seconde.

Limites des bases de données colonnaires sur les lignes uniques et les mises à jour

  • Postgres trouve une ligne unique par ID en deux millisecondes grâce à son index d'arbre binaire.
  • ClickHouse nécessite 168 millisecondes pour la même recherche car la table est triée par horodatage.
  • Les modifications de données exigent la réécriture complète des fichiers de colonnes dans ClickHouse.

L'architecture colonnaires pénalise les opérations de recherche unitaire et de mise à jour fréquente. ClickHouse traite les modifications de valeurs comme des mutations globales de table car ses fichiers de données sont immuables. DuckDB modifie ses fichiers sur place, offrant de meilleures performances sur les mises à jour. Le choix final de la technologie dépend de la scalabilité, de la concurrence et des cas d'utilisation spécifiques.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video