ClickHouse的独特特性
真正的列式数据库管理系统
在真正的列式数据库管理系统中，值不会存储额外的数据。这意味着必须支持常量长度的值，以避免将其长度“数字”与值一起存储。例如，十亿个UInt8类型的值应该在未压缩时占用大约1 GB，否则这会严重影响CPU使用。即使在未压缩的情况下，存储数据时必须紧凑（没有任何“垃圾”），因为解压缩的速度（CPU使用）主要取决于未压缩数据的体积。
这与可以将不同列的值分开存储但无法有效处理分析查询的系统相反，例如HBase、BigTable、Cassandra和HyperTable。在这些系统中，您可以获得每秒数十万行的吞吐量，但不是数亿行每秒。
最后，ClickHouse是一个数据库管理系统，而不是单个数据库。它允许在运行时创建表和数据库、加载数据并运行查询，而无需重新配置和重新启动服务器。
数据压缩
一些列式数据库管理系统不使用数据压缩。然而，数据压缩在实现出色性能方面起着关键作用。
除了具有不同磁盘空间和CPU消耗之间的权衡的高效通用压缩编解码器之外，ClickHouse还提供了用于特定数据类型的专门的编解码器，这使得ClickHouse能够与更专业的数据库（例如时间序列数据库）竞争并超越它们。
数据的磁盘存储
按主键物理排序数据使得可以在不到几十毫秒的时间内以低延迟提取特定值或值范围的数据。一些列式数据库管理系统，例如SAP HANA和Google PowerDrill，只能在RAM中工作。这种方法需要分配比实时分析所需的更大的硬件预算。
ClickHouse旨在在常规硬盘上工作，这意味着数据存储成本低，但如果可用，SSD和额外的RAM也会被充分利用。
多核并行处理
大型查询自然地并行化，利用当前服务器上的所有必要资源。
多服务器分布式处理
几乎没有列式数据库管理系统具有分布式查询处理的支持。
在ClickHouse中，数据可以驻留在不同的分片上。每个分片可以是用于容错的副本组。所有分片都用于并行运行查询，对用户透明。
SQL支持
ClickHouse支持基于SQL的声明性查询语言，在许多情况下与ANSI SQL标准相同。
支持的查询包括GROUP BY、ORDER BY、FROM子查询、JOIN子句、IN运算符、窗口函数和标量子查询。
在写作时，不支持相关（依赖）子查询，但可能在将来提供。
矢量计算引擎
数据不仅以列的形式存储，还以矢量（列的一部分）的形式处理，这有助于实现高CPU效率。
实时数据插入
ClickHouse支持具有主键的表。使用合并树递增地对数据进行排序，可以快速执行主键范围的查询。由于这一点，数据可以持续添加到表中。在插入新数据时不会锁定。
主索引
通过主键物理排序数据使得可以在不到几十毫秒的时间内以低延迟提取特定值或值范围的数据。
二级索引
与其他数据库管理系统不同，ClickHouse中的二级索引不指向特定行或行范围。相反，它们允许数据库提前知道某些数据部分中的所有行都不会匹配查询过滤条件，并且根本不读取它们，因此它们被称为数据跳过索引。
适用于在线查询
大多数OLAP数据库管理系统并不专注于具有次秒级延迟的在线查询。在其他系统中，报告构建时间通常被认为是可以接受的，通常为数十秒甚至几分钟。有时需要更长的时间，这迫使系统提前（提前或通过“稍后再来”）准备报告。
在ClickHouse中，“低延迟”意味着查询可以在没有延迟的情况下处理，而不是试图提前准备答案，就在用户界面页面加载的同时。换句话说，是在线的。
支持近似计算
ClickHouse提供了各种方法来在性能和准确性之间进行权衡：
- 用于近似计算不同值数量、中位数和分位数的聚合函数。
- 基于部分（样本）数据运行查询并获得近似结果。在这种情况下，从磁盘检索的数据量会相应减少。
- 仅对一定数量的随机键运行聚合，而不是对所有键运行。在数据中的某些条件下，这提供了一个相当准确的结果，同时使用更少的资源。
自适应连接算法
ClickHouse自适应地选择如何连接多个表，优先选择哈希连接算法，如果有多个大表，则退而使用合并连接算法。
数据复制和数据完整性支持
ClickHouse使用异步多主复制。在写入任何可用副本后，所有剩余的副本都会在后台检索它们的副本。系统在不同副本上维护相同的数据。大多数故障后的恢复都是自动进行的，或者在复杂情况下是半自动进行的。
有关更多信息，请参见数据复制部分。
基于角色的访问控制
ClickHouse使用SQL查询实现用户帐户管理，并允许配置类似于ANSI SQL标准和流行的关系数据库管理系统的基于角色的访问控制。
可能被视为缺点的特性
- 没有完整的事务。
- 无法以高速率和低延迟修改或删除已插入的数据。可以使用批量删除和更新来清理或修改数据，例如以符合GDPR的要求。
- 稀疏索引使得ClickHouse对于通过其键检索单个行的点查询不那么高效。