真正的面向列的数据库管理系统
在一个真正的列式数据库数据库中，没有额外的数据与值一起存储。 其中，这意味着必须支持常量长度值，以避免将它们的长度“数字”存储在值旁边。 例如，10亿个 uint8类型的值实际上应该消耗大约1gb 的未压缩空间，否则将严重影响 CPU 的使用。 即使在未压缩的情况下，紧凑地存储数据(没有任何“垃圾”)也非常重要，因为解压缩的速度(CPU 使用率)主要取决于未压缩数据的体积。
这是值得注意的，因为有些系统可以分别存储不同列的值，但是由于对其他场景的优化，它们不能有效地处理分析查询。 例如 HBase、 BigTable、 Cassandra 和 HyperTable。 在这些系统中，您将获得每秒大约10万行的吞吐量，而不是每秒数亿行的吞吐量。
同样值得注意的是 ClickHouse 是一个数据库管理系统，而不是一个单独的数据库。 Clickhouse 允许在运行时创建表和数据库、加载数据和运行查询，而无需重新配置和重新启动服务器。
数据压缩
一些面向列的dbms（InfiniDB CE和MonetDB）不使用数据压缩。然而，数据压缩在获得优异性能方面确实起着关键作用
数据的磁盘存储
通过按主键对数据进行物理排序，可以提取其特定值或值范围的数据，并且延迟时间短于几十毫秒。 某些面向列的DBMS（例如SAP HANA和Google PowerDrill）只能在RAM中工作。 这种方法鼓励分配比实时分析实际所需的更大的硬件预算。 ClickHouse专为在常规硬盘上工作而设计，这意味着每GB数据存储的成本较低，但是，如果可用，还可以充分利用SSD和额外的RAM。
多核并行处理
大型查询以自然的方式并行化，占用当前服务器上可用的所有必要资源。
多服务器上的分布式处理
上面提到的列式dbms几乎都不支持分布式查询处理。在ClickHouse中，数据可以驻留在不同的碎片上。每个碎片可以是一组用于容错的副本。查询在所有碎片上并行处理。这对用户是透明的。
SQL支持
ClickHouse支持基于SQL的声明式查询语言，在许多情况下，该语言与SQL标准相同。支持的查询包括GROUPBY、ORDERBY、FROM、in和JOIN子句中的子查询以及标量子查询。不支持依赖子查询和窗口函数。
向量引擎
数据不仅由列存储，而且由向量（列的一部分）处理。这使我们能够实现高CPU效率。
实时数据更新
ClickHouse支持带有主键的表。为了快速对主键的范围执行查询，使用合并树对数据进行增量排序。因此，数据可以不断地添加到表中。当接收到新数据时，不会执行任何锁定。
索引
通过按主键对数据进行物理排序，可以提取特定值或值范围的数据，且延迟较低，小于几十毫秒。
适合即席查询
低延迟意味着在加载用户界面页面的同时，可以毫不延迟地处理查询，而无需提前准备答案。换句话说，就是快。
支持近似计算
ClickHouse提供了多种方式来权衡准确性和性能：
-
用于近似计算不同值、中位数和分位数个数的聚合函数。
-
基于部分(样本)数据运行查询并获得大致的结果。 在这种情况下，从磁盘中检索的数据比例较小。
-
为有限数量的随机键而不是为所有键运行聚合。 在数据中密钥分配的某些条件下，这样可以在使用较少资源的情况下提供相当准确的结果。
数据复制和数据完整性支持
使用异步多主机复制。在写入任何可用的副本后，数据将被分发到后台的所有剩余副本。系统在不同的副本上维护相同的数据。大多数故障后的恢复都是自动执行的，在复杂的情况下是半自动的
来源：CSDN
作者：HeartisTiger
链接：https://blog.csdn.net/weixin_43704599/article/details/104479528