Dans un vrai SGBD orienté colonne, aucune donnée supplémentaire n'est stockée avec les valeurs. Entre autres choses, cela signifie que les valeurs de longueur constante doivent être prises en charge, pour éviter de stocker leur longueur “number” à côté de ces valeurs. Par exemple, un milliard de valeurs de type UInt8 devrait consommer environ 1 Go non compressé, ou cela affecte fortement l'utilisation du processeur. Il est essentiel de stocker des données de manière compacte (sans “garbage”) même lorsqu'il n'est pas compressé, puisque la vitesse de décompression (utilisation du processeur) dépend principalement du volume de données non compressées.
Il est à noter car il existe des systèmes qui peuvent stocker des valeurs de différentes colonnes séparément, mais qui ne peuvent pas traiter efficacement les requêtes analytiques en raison de leur optimisation pour d'autres scénarios. Les exemples sont HBase, BigTable, Cassandra et HyperTable. Dans ces systèmes, vous obtiendriez un débit d'environ cent mille lignes par seconde, mais pas des centaines de millions de lignes par seconde.
Il est également intéressant de noter que ClickHouse est un système de gestion de base de données, pas une seule base de données. ClickHouse permet de créer des tables et des bases de données en cours d'exécution, de charger des données et d'exécuter des requêtes sans reconfigurer et redémarrer le serveur.
Certains SGBD orientés colonne (InfiniDB CE et MonetDB) n'utilisent pas la compression de données. Cependant, la compression des données joue un rôle clé dans la réalisation d'excellentes performances.
Garder les données physiquement triées par clé primaire permet d'extraire des données pour ses valeurs spécifiques ou plages de valeurs avec une faible latence, moins de quelques dizaines de millisecondes. Certains SGBD orientés colonne (tels que SAP HANA et Google PowerDrill) ne peuvent fonctionner qu'en RAM. Cette approche encourage l'allocation d'un budget matériel plus important que ce qui est nécessaire pour l'analyse en temps réel. ClickHouse est conçu pour fonctionner sur des disques durs réguliers, ce qui signifie que le coût par Go de stockage de données est faible, mais SSD et RAM supplémentaire sont également entièrement utilisés si disponible.
Dans ClickHouse, les données peuvent résider sur différents fragments. Chaque fragment peut être un groupe de répliques utilisées pour la tolérance aux pannes. Tous les fragments sont utilisés pour exécuter une requête en parallèle, de façon transparente pour l'utilisateur.
Les données ne sont pas seulement stockées par des colonnes, mais sont traitées par des vecteurs (parties de colonnes), ce qui permet d'atteindre une efficacité élevée du processeur.
ClickHouse prend en charge les tables avec une clé primaire. Pour effectuer rapidement des requêtes sur la plage de la clé primaire, les données sont triées progressivement à l'aide de l'arborescence de fusion. Pour cette raison, les données peuvent être continuellement ajoutées à la table. Pas de verrouillage lorsque de nouvelles données sont ingérés.
Avoir une donnée physiquement triée par clé primaire permet d'extraire des données pour ses valeurs spécifiques ou plages de valeurs avec une faible latence, moins de quelques dizaines de millisecondes.
Faible latence signifie que les requêtes peuvent être traitées sans délai et sans essayer de préparer une réponse à l'avance, au même moment pendant le chargement de la page de l'interface utilisateur. En d'autres termes, en ligne.
1. Fonctions d'agrégation pour le calcul approximatif du nombre de valeurs distinctes, de médianes et de quantiles.
2. L'exécution d'une requête basée sur une partie (échantillon) de données et obtenir un pseudo résultat. Dans ce cas, proportionnellement, moins de données sont récupérées à partir du disque.
3. L'exécution d'une agrégation pour un nombre limité de clés aléatoires, au lieu de toutes les clés. Sous certaines conditions pour la distribution des clés dans les données, cela fournit un résultat raisonnablement précis tout en utilisant moins de ressources.
ClickHouse utilise la réplication multi-maître asynchrone. Après avoir été écrit dans n'importe quelle réplique disponible, toutes les répliques restantes récupèrent leur copie en arrière-plan. Le système conserve des données identiques sur différentes répliques. La récupération après la plupart des échecs est effectuée automatiquement ou semi-automatiquement dans les cas complexes.
2. Manque de capacité à modifier ou supprimer des données déjà insérées avec un taux élevé et une faible latence. Des suppressions et des mises à jour par lots sont disponibles pour nettoyer ou modifier les données, par exemple pour [GDPR](https://gdpr-info.eu).
