ClickHouse

Yandex.Metrica utilisait précédemment une approche plus classique lorsque les données brutes étaient stockées dans une forme agrégée[12]. Cette approche permet de réduire la quantité de données stockée. Cependant, elle possède plusieurs désavantages et limitations :

• la liste des rapports disponibles doit être prédéterminée, sans possibilité de faire un rapport personnalisé ;
• le volume de données peut augmenter après agrégation ; cela se produit quand les données sont agrégées avec un grand nombre de clés ou en utilisant des clés à grandes cardinalité (comme les URL) ;
• il est difficile de gérer la consistance logique autour des rapports contenant différentes agrégations.

Une approche différente consiste dans le stockage de données non agrégées. Traiter des données brutes requiert un système haute-performance, car tous les calculs sont faits en temps réel. Pour résoudre ce problème, une base de données orientée colonnes est requise afin de pouvoir évoluer à l’échelle d'Internet. Yandex commença donc à développer sa propre solution. Le premier prototype de ClickHouse est apparu en 2009. À la fin de l’année 2014, Yandex.Metrica version 2.0 est publié. La nouvelle version possède une interface pour créer des rapports personnalisés et utilise ClickHouse pour le stockage et le traitement des données.

Les principales caractéristiques de ClickHouse sont[13] :

• Véritable base de données orientée colonnes. Rien n'est stocké avec les valeurs. Par exemple, les valeurs de tailles fixes sont gérées pour éviter de stocker leur taille à côté des valeurs.
• Extension linéaire. Il est possible d’étendre un cluster en ajoutant des serveurs.
• Tolérance aux pannes. Le système est un cluster de fragments, dans lequel chaque fragment est un groupe de replicas. ClickHouse utilise une réplication multi-master asynchrone. Les données sont écrites sur n'importe lequel des replicas disponibles, puis distribuées sur les replicas restants. ZooKeeper est utilise pour synchroniser les processus, mais ne participe pas aux traitements et à l’exécution des requêtes.
• Capacité à stocker et traiter plusieurs péta-octets de données.
• prise en charge de SQL. ClickHouse prend en charge un langage étendu proche de SQL qui inclut les tableaux et les structures de données imbriquées, les approximations et les fonctions URI, et permet la connexion à un stockage clé-valeur externe.
• Haute performance.[14]
  • Les calculs par vecteurs sont utilisés. Les données sont stockées seulement par colonnes, mais sont traitées par vecteurs (portions de colonnes). Cette approche permet d'atteindre de hautes performances CPU.
  • Les calculs par approximation et l’échantillonnage sont gérés.
  • Les traitements de requêtes distribuées et parallèles sont disponibles (incluant les jointures).
• Compression de données.
• Optimisation pour les disques durs. Le système peut traiter des données qui ne tiennent pas en Mémoire vive.
• Clients pour la connexion à la base de données. Les options de connexion a la base de données incluent le client en mode console, HTTP API, ou l'un des wrappers (les wrappers sont disponibles pour les langages de script Python, PHP[15], Node.js[16], Perl[17], Ruby[18] et R[19], ainsi que les langages compilés Rust et Go[20]). Un driver JDBC (en) est également disponible pour ClickHouse[21].
• Documentation détaillée.

ClickHouse possède plusieurs caractéristiques pouvant être considérées comme des désavantages :

• aucune gestion des transactions ;
• par défaut, quand on effectue des agrégations, les états de la requête intermédiaire doivent tenir en RAM sur un serveur unique ; cependant, cela peut être configuré afin de déborder sur le disque dans ce cas de figure ;
• un manque dans l’implémentation complète des UPDATE/DELETE.

ClickHouse est également conçu pour les requêtes OLAP[13].

• Cela fonctionne pour un petit nombre de tables qui contiennent un grand nombre de colonnes.
• Les requêtes peuvent utiliser un grand nombre de lignes extraites de la BDD, mais seulement un sous-ensemble de colonnes.
• Les requêtes sont relativement rares (autour de 100 RPS par serveur).
• Pour des requêtes simples, des latences d'environ 50 ms sont acceptables.
• Les valeurs de colonnes sont raisonnablement petites, consistant en des nombres et de petites chaînes de caractères (par exemple, 60 octets par URL).
• Un haut débit est requis lorsque l'on traite une requête simple (jusqu’à plusieurs milliards de lignes par seconde par serveur).
• Un résultat de requête est souvent filtré et agrégé.
• La mise à jour des données utilise un scenario simple (souvent un batch, sans transactions complexes).

Un des cas courants de ClickHouse serveur est l'analyse de logs. Après avoir peuplé des données dans ClickHouse (il est recommandé d’insérer des données avec un relativement gros batch contenant plus de 1 000 lignes), il est possible d'analyser les incidents avec des requêtes instantanées ou de surveiller les métriques du service, comme le taux d'erreurs, les temps de réponses, etc.

ClickHouse peut aussi être utilisé comme entrepôt de données pour de l'analyse en interne. ClickHouse peut stocker des données de différents systèmes (par exemple Hadoop ou certain logs) et les analystes peuvent construire des tableaux de visualisations avec les données ou réaliser des analyses temps réels à des fins commerciales.

Selon les tests de performance conduits par les développeurs[14], pour les requêtes OLAP, ClickHouse est plus de 100 fois plus rapide que Hive (une BDD basée sur la technologie Hadoop) ou MySQL (RDBMS).

• page officiel de ClickHouse
• dépôt GitHub de ClickHouse