主题

有关于clickhouse的内容比较多，我从另外一种场景下简要的说明，希望能为选型或使用带来一定的参考意义

行数据库

在传统的行式数据库系统中，数据按如下顺序存储：

处于同一行中的数据总是被物理的存储在一起。
常见的行式数据库系统有：MySQL、Postgres和MS SQL Server

列数据库

在列式数据库系统中，数据按如下的顺序存储：

不同的数据存储方式适用不同的业务场景，clickhose属于列数据库之列

联机分析(OLAP)场景的关键特征

• 绝大多数是读请求
• 数据以相当大的批次(> 1000行)更新，而不是单行更新;或者根本没有更新。
• 已添加到数据库的数据不能修改。
• 对于读取，从数据库中提取相当多的行，但只提取列的一小部分。
• 宽表，即每个表包含着大量的列
• 查询相对较少(通常每台服务器每秒查询数百次或更少)
• 对于简单查询，允许延迟大约50毫秒
• 列中的数据相对较小：数字和短字符串(例如，每个URL 60个字节)
• 处理单个查询时需要高吞吐量(每台服务器每秒可达数十亿行)
• 事务不是必须的
• 对数据一致性要求低
• 每个查询有一个大表。除了他以外，其他的都很小。
• 查询结果明显小于源数据。换句话说，数据经过过滤或聚合，因此结果适合于单个服务器的RAM中

很容易可以看出，OLAP场景与其他通常业务场景(例如,OLTP或K/V)有很大的不同， 因此想要使用OLTP或Key-Value数据库去高效的处理分析查询场景，并不是非常完美的适用方案。例如，使用OLAP数据库去处理分析请求通常要优于使用MongoDB或Redis去处理分析请求

输入/输出

1. 针对分析类查询，通常只需要读取表的一小部分列。在列式数据库中你可以只读取你需要的数据。例如，如果只需要读取100列中的5列，这将帮助你最少减少20倍的I/O消耗。
2. 由于数据总是打包成批量读取的，所以压缩是非常容易的。同时数据按列分别存储这也更容易压缩。这进一步降低了I/O的体积。
3. 由于I/O的降低，这将帮助更多的数据被系统缓存。

例如，查询«统计每个广告平台的记录数量»需要读取«广告平台ID»这一列，它在未压缩的情况下需要1个字节进行存储。如果大部分流量不是来自广告平台，那么这一列至少可以以十倍的压缩率被压缩。当采用快速压缩算法，它的解压速度最少在十亿字节(未压缩数据)每秒。换句话说，这个查询可以在单个服务器上以每秒大约几十亿行的速度进行处理。这实际上是当前实现的速度

上图总结

61亿的数据，表列50多，装在一张表里面，一般一个单表存储性能好不好，看排序和表列，记录数，磁盘的占用空间数一般的应用很少关注这个，涉及到服务器存储方面，如果你粗略估算以下，像是系统日志的处理之前经历的按实践分表、时序或者es、但总的来说都是通过软件技术层面的难度去解决这个问题的，以下是条件排序的处理验证300多万的数据排序查询，预期还是很可观的，至于数据库语法层面的东西，没啥太大的差异性。

总结

基本上从数据存储、复杂分析的实施易用性、业务宽表需求，属于一个居中理想化的组合，比如常规的时序数据库存储，一定程度上能解决连续的时序数据存储，但对上层的业务分析，始终面临着数据的宽表信息结构及数据统计的10年以上存储，如果业务层按分表那种操作进行，又会给应用层带来体验交互层面的限制，且为了提升这种体量的支持，不得不对软件层面的代码进行改造和处理，不计成本的折腾，我想好多人已经受够了在代码层级去弥补数据库的性能问题。