你好，我是阿迈达。 是个有趣的网络软件工程师。 从专业的角度分析技术原理，以幽默的态度解读科技网络信息。
(在这里添加了社团卡。 请在今天的顶级客户那里看。 )
什么是ClickHouse
ClickHouse是为YandexMetrica全球第二大网络分析平台开发的。 多年来，它一直作为该系统的核心组件在该系统中使用。 迄今为止，该系统在ClickHouse有13万亿件以上的记录，每天处理200亿件以上的事件。 这样可以直接从原始数据动态查询并生成报告。Yandex.Metrica根据用户定义的字段，为连接会话生成实时访问和统计报告。 这些需求通常需要复杂的聚合方法，例如重新定位访问用户。 生成报告的数据将实时接收存储的新数据。
截至2014年4月，Yandex.Metrica每天跟踪约120亿个事件(用户点击和浏览)。 要创建自定义报告，必须保存所有这些事件。 同时，这些查询可能需要在数百毫秒内扫描数百万行数据，也可能需要在几秒内扫描数亿行数据。
联机分析(OLAP)的列式数据库管理系统
ClickHouse是用于在线分析(OLAP )的DBMS )列型数据库管理系统。在传统的线数据库系统中，数据按以下顺序存储：
同一行上的数据总是物理存储在一起。 典型的线数据库系统是MySQL、Postgres和MySQL服务器。
在基于列的数据库系统中，数据按以下顺序存储：
此示例仅显示了列数据库中数据的排序顺序。 对于存储，基于列的数据库总是将同一列的数据存储在一个数据库中，而不同列的数据也总是分别存储。
典型的列数据库包括垂直、分区访问(Aatianmatrix，Amazon Redshift )、系统智商、Exasol、信息存储库、信息数据库、迷你数据库) vecca
各种保存方法适用于各种场景。 这里的查询场景如下。
使用数据集中大小和本地数据集的使用事务，以及查询发生的频率、每个查询的百分比查询读取的数据行数、列数、字节数读取数据和写入数据之间的关系数据复制机制和数据完整性要求，包括每种类型的查询所需的延迟和吞吐量。 系统负荷越高，根据使用场景进行定制就越重要，定制就越精细。 显然，没有适用于不同场景的系统。 当系统应用于广泛的场景时，在负载较重的情况下，可以公平地处理所有场景，但不能有效地处理某些场景。
OLAP场景的关键特征
在大多数情况下，读请求数据总是以非常大的批处理(1000 rows )写入，并且每次查询都从数据库中读取大量行，但同时只需要列宽很小的表。 也就是说，一个表中包含的查询很少，通常每秒服务器不超过数百个。 在简单查询中，允许延迟约50毫秒的列中的数据相对较小。 使用数字和短字符串(例如，每URL 60字节)处理一个查询时，需要很高的吞吐量。 每台服务器每秒最多几十亿行(不需要事务处理)。 不需要数据的完整性。 除了大表以外，每个查询都显示比源数据小得多的查询结果。 换言之，从数据被过滤或聚合后可以容纳在一台服务器的内存中也可以看出，OLAP的场景与其他普通场景(OLTP和K/V等)有很大不同，因此OLTP和key -。 例如，使用OLAP数据库处理分析请求通常优于使用MongoDB和Redis处理分析请求
列式数据库更适合OLAP场景的原因
列数据库适用于OLAP场景。 在大多数查询中，处理速度至少提高了一百倍。 其理由详细说明如下。 图像更容易直观理解。LINE
列式
utiaoimg.com/origin/pgc-image/261d434f87cb41eab7ddf21e4234746c?from=pc">看到差别了么？下面将详细介绍为什么会发生这种情况。
输入/输出
针对分析类查询，通常只需要读取表的一小部分列。在列式数据库中你可以只读取你需要的数据。例如，如果只需要读取100列中的5列，这将帮助你最少减少20倍的I/O消耗。由于数据总是打包成批量读取的，所以压缩是非常容易的。同时数据按列分别存储这也更容易压缩。这进一步降低了I/O的体积。由于I/O的降低，这将帮助更多的数据被系统缓存。例如，查询«统计每个广告平台的记录数量»需要读取«广告平台ID»这一列，它在未压缩的情况下需要1个字节进行存储。如果大部分流量不是来自广告平台，那么这一列至少可以以十倍的压缩率被压缩。当采用快速压缩算法，它的解压速度最少在十亿字节(未压缩数据)每秒。换句话说，这个查询可以在单个服务器上以每秒大约几十亿行的速度进行处理。这实际上是当前实现的速度。
CPU
由于执行一个查询需要处理大量的行，因此在整个向量上执行所有操作将比在每一行上执行所有操作更加高效。同时这将有助于实现一个几乎没有调用成本的查询引擎。如果你不这样做，使用任何一个机械硬盘，查询引擎都不可避免的停止CPU进行等待。所以，在数据按列存储并且按列执行是很有意义的。
有两种方法可以做到这一点：
向量引擎：所有的操作都是为向量而不是为单个值编写的。这意味着多个操作之间的不再需要频繁的调用，并且调用的成本基本可以忽略不计。操作代码包含一个优化的内部循环。代码生成：生成一段代码，包含查询中的所有操作。这是不应该在一个通用数据库中实现的，因为这在运行简单查询时是没有意义的。但是也有例外，例如，MemSQL使用代码生成来减少处理SQL查询的延迟(只是为了比较，分析型数据库通常需要优化的是吞吐而不是延迟)。
请注意，为了提高CPU效率，查询语言必须是声明型的(SQL或MDX)， 或者至少一个向量(J，K)。 查询应该只包含隐式循环，允许进行优化。