ClickHouse为啥会被选择
分析&回答
ClickHouse 非常亲和且具有自己的个性
- 支持完备的SQL操作
- 列式存储与数据压缩
- 向量化执行引擎
- 关系型模型(与传统数据库类似)
- 丰富的表引擎
- 并行处理
- 在线查询
- 数据分片
ClickHouse为何如此之快
- 将硬件性能发挥到极致 基于将硬件功效最大化的目的，ClickHouse会在内存中进行GROUP BY，并且使用HashTable装载数据。
- 算法方面精益求精 在ClickHouse的底层实现中，经常会面对一些重复的场景，例如字符串子串查询、数组排序、使用HashTable等。对于不同的场景会用不同的算法。
- 勇于尝鲜，不行就换 除了字符串之外，其余的场景也与它类似，ClickHouse会使用最合适、最快的算法。如果世面上出现了号称性能强大的新算法，ClickHouse团队会立即将其纳入并进行验证。如果效果不错，就保留使用；如果性能不尽人意，就将其抛弃。
- 特定场景，特殊优化 针对同一个场景的不同状况，选择使用不同的实现方式，尽可能将性能最大化。关于这一点，其实在前面介绍字符串查询时，针对不同场景选择不同算法的思路就有体现了。类似的例子还有很多，例如去重计数uniqCombined函数，会根据数据量的不同选择不同的算法：当数据量较小的时候，会选择Array保存；当数据量中等的时候，会选择HashSet；而当数据量很大的时候，则使用HyperLogLog算法。 对于数据结构比较清晰的场景，会通过代码生成技术实现循环展开，以减少循环次数。接着就是大家熟知的大杀器—向量化执行了。SIMD被广泛地应用于文本转换、数据过滤、数据解压和JSON转换等场景。相较于单纯地使用CPU，利用寄存器暴力优化也算是一种降维打击了。
- 持续测试，持续改进 如果只是单纯地在上述细节上下功夫，还不足以构建出如此强大的ClickHouse，还需要拥有一个能够持续验证、持续改进的机制。由于Yandex的天然优势，ClickHouse经常会使用真实的数据进行测试，这一点很好地保证了测试场景的真实性。与此同时，ClickHouse也是我见过的发版速度最快的开源软件了，差不多每个月都能发布一个版本。没有一个可靠的持续集成环境，这一点是做不到的。正因为拥有这样的发版频率，ClickHouse才能够快速迭代、快速改进。
- 行存储和列存储 分析场景中，我们一般会读大量的行而取少量的列，在列式存储结构下，我们只需要取对应的列数据就可以，不参与计算的列完全不会被扫描到，这会极大的降低磁盘 IO 的消耗。
- 数据压缩 基于列式存储的结构，同一列中的数据属于同一类型，压缩效果会更加显著。列存储往有着高达十倍甚至更高的压缩比，节省了大量的存储空间，降低了存储成本。
向量化执行引擎 SIMD（Single Instruction Multiple Data）即单条指令操作多条数据，它是通过数据并行以提高性能的一种方式，可以简单理解为在寄存器层面对程序中的数据做并行处理，Clickhouse 在能够提升计算效率的地方大量使用了 SIMD，通过使用 SIMD，基本上能带来几倍的性能提升，像阿里云的 PolarDB-X 也引入了向量化执行引擎，为表达式计算带来了几十倍的性能提升。
- 多线程与分布式 分布式领域存在一条定律，计算移动比数据移动更加划算，这也是其核心所在，将数据的计算直接发放到数据所在的服务器，多机并行处理，再把最终的结果汇集在一起；另外 Clickhouse 也通过线程级别并行的方式为效率进一步提速，极致去利用服务器的资源。
- 多样化的表引擎
反思&扩展
ClickHouse VS ES
- ClickHouse写⼊吞吐量⼤，单服务器⽇志写⼊量在50MB到200MB/s，每秒写⼊超过60w记录数，是ES的5倍以上。
- 查询速度快，官⽅宣称数据在pagecache中，单服务器查询速率⼤约在2-30GB/s；没在pagecache的情况下，查询速度取决于磁盘的读取速率和数据的压缩率。。
- ClickHouse⽐ES服务器成本更低。⼀⽅⾯ClickHouse的数据压缩⽐⽐ES⾼，相同数据占⽤的磁盘空间只有ES的1/3到1/30，节省了磁盘空间的同时，也能有效的减少磁盘IO；另⼀⽅⾯ClickHouse⽐ES占⽤更少的内存，消耗更少的CPU资源。。
- 相⽐ES，ClickHouse稳定性更⾼，运维成本更低。ES中不同的Group负载不均衡，有的Group负载⾼，会导致写Rejected等问题，需要⼈⼯迁移索引；在ClickHouse中通过集群和Shard策略，采⽤轮询写的⽅法，可以让数据⽐较均衡的分布到所有节点。ES中⼀个⼤查询可能导致OOM的问题；ClickHouse通过预设的查询限制，会查询失败，不影响整体的稳定性。ES需要进⾏冷热数据分离，ClickHouse按天分partition，⼀般不需要考虑冷热分离，特殊场景⽤户确实需要冷热分离的，数据量也会⼩很多，ClickHouse⾃带的冷热分离机制就可以很好的解决。
- ClickHouse采⽤SQL语法，⽐ES的DSL更加简单，学习成本更低。
缺点：
- 由于是列式数据库，⽆法像ES⼀样提供全⽂检索功能。
- ⽆法动态添加字段，需要提前定义好表schema。
- ⽇志⽆法长期保存，历史数据需定期清理下线，如果有保存历史数据需求，需要通过迁移数据，采⽤ClickHouse_copier或者复制数据的⽅式实现。
- ClickHouse查询速度快，能充分利⽤集群资源，但是⽆法⽀持⾼并发查询，默认配置qps为100。
- Clickhouse并不适合许多⼩数据⾼频插⼊，批量写⼊⽇志会有⼀定延迟。