clickhouse 速度快的原因-小结

1.clickhouse是一个列式存储的数据库，每一列数据都经过了lz4的压缩，由于列数据之间重复性极高，所以拥有非常可观的压缩比，这样查询一列数据时，扫描速度极快，clickhouse的列式存储具体如下：如果把每一列的数据当成一个大树的话，clickhouse会把一个大树分成一颗颗小树的形式，每一颗小树都是一颗LSM日志合并树，局部有序并且只用LZ4算法压缩，然后再通过稀疏索引的形式来串联起所有的小树，这样clickhouse可以得到非常极端的数据压缩比(正常可达到5：1以上)
2.cpu指令层面的优化，大量使用了向量化的操作的指令，也就是SIMD指令(单指令多数据)，并且非常善于利用cpu的L1，L2，L3缓存，尽量减少读取内存或者磁盘的操作.
3.不同的场景使用不同的算法或者数据结构，比如数据量较小时就是用array数组存储，数据中等大小时就用hashset结构存储，数据量庞大时使用hyperloglog结构存储
4.不同的表引擎，包括合并树表引擎，聚合合并树表引擎，内存表引擎等等，不同的应用场景可以使用不同的表引擎提高性能.
5.内部高性能算法的使用，比如字符串查找的算法选择，clickhouse会去选择速度最快的算法.

ps:
1.clickhouse毕竟是一个olap数据库，对于这些数据库来说，聚合查询的性能是最首要的.
2.LSM合并树的常见实现逻辑：当数据插入到LSM树时，他只是把数据存放到内存中(当然此时为了防止数据丢失，也会把数据顺序插入到事务日志文件中，不过这个顺序io执行很快，不会成为瓶颈)，内存中的数据此时是排好序的，等内存中的数据量达到一定的阈值，他就会把内存中的数据刷新到磁盘上面，此时也是顺序io操作，速度极快，当然此时磁盘上的数据也是局部有序的.

最后不要小看列式存储和压缩的威力，我们可以初略计算一下：
1.假设数据表有100列，需要获取其中的5列数据，对于mysql等行式存储数据库来说，查找数据时每次都要扫描完整的行(也就是100列)，但是对于ck来说，只需要读取5列的数据，IO读写比例是mysql的20分之一，也就是减少了20倍的IO数据量,这是一个很大的IO节省
2.ck的每一列数据都是使用lz4压缩算法压缩过的，由于同一列的数据重复性很高，所以压缩比非常可观，一般都可以达到10倍的压缩比，所以相当于又减少了10倍的IO数据量
所以假设mysql读取数据表的IO数据量是100，经过列式存储后，ck把IO数据量减少到了5，再经过lz4压缩算法发后，IO数据量进一步减少到了0.5，所以总体上IO数据量减少了将近200倍，这是个非常惊人的数字.