ClickHouse基础知识及与MySQL性能对比( 五 ) _索引

索引文件
会在每个分区目录下生成一个索引文件.idx，记录了主键排序后按照索引粒度采样的值，以二进制的方式存储，可以通过od命令进行查看:
[root@slave3 20201216_22_22_0]# od -l -j 0 -N 80 --width=8 primary.idx000000016080876000015620000010160808796674150100000201608087637579224000003016080881720943130000040160808767459469900000501608087862362366000006016080877128350910000070160808787594233200001001608087750685288000011016080882517772910000120
标记文件
因为是稀疏索引，所以显然只靠一级索引文件是无法精确定位到数据的，这时候就需要标记文件登场了。在分区目录下，你可以看到很多后缀为.bin和.mrk2的文件，其中.bin是真实的数据内容，.mrk2就是我们要说的标记文件。因为底层是按列进行存储的，因此每一列会对应一个.bin文件和.mrk2文件。
[root@slave3 20201216_22_22_0]# od -l -j 0 -N 240 --width=24 ./city.mrk200000000081920000030032768819200000602950819200001102953276881920000140590081920000170590327688192000022088508192000025088532768819200003008856468000000330
一行标记数据使用一个元组表示，元组内包含数据压缩块位置（在.bin文件中数据是切分成若干个数据块压缩存储的），数据块内偏移和索引粒度的大小。
标记文件并不能常驻内存，俄日是使用LRU缓存策略加快其读取速度。
索引工作方式
是如何利用.idx和.mr2文件检索到具体的文件内容的呢？首先索引文件和标记文件在行上是对齐的，从上面索引文件和标记文件的示例可以看出来，二者的行数是一样的，如图：
在查询的时候，会先根据要索引的值或范围，在.idx文件中确定一个行号范围（具体确定的过程这里就不详细展开了，基本上就是一个递归交集的判断），然后按照相同的行号范围在每一列的.mrk中查询，得到要查询的值在数据文件.bin的哪一个压缩块，以及将该压缩块解压之后在什么位置，然后将查询到的数据结果返回。
通过 + 一级索引 + 标记文件，层层缩小数据扫描范围，达到了其快速检索的目的。
疑问：上面所说的都是查询条件命中索引的情况，如果没有的话是怎么处理的呢？
当然只能是每个挨个扫描了，不过因为.bin文件分了若干个小的压缩块，利用多线程读取压缩块的方式在一定程度上也可以加速查找过程。
性能单个查询吞吐量
如果数据被放置在page cache中，则一个不太复杂的查询在单个服务器上大约能够以2-10GB／s（未压缩）的速度进行处理（对于简单的查询，速度可以达到30GB／s）。如果数据没有在page cache中的话，那么速度将取决于你的磁盘系统和数据的压缩率。例如，如果一个磁盘允许以400MB／s的速度读取数据，并且数据压缩率是3，则数据的处理速度为1.2GB/s 。这意味着，如果你是在提取一个10字节的列，那么它的处理速度大约是1-2亿行每秒。对于分布式处理，处理速度几乎是线性扩展的，但这受限于聚合或排序的结果不是那么大的情况下。
处理短查询的延时时间
数据被page cache缓存的情况下，它的延迟应该小于50毫秒(最佳情况下应该小于10毫秒) 。否则，延迟取决于数据的查找次数。延迟可以通过以下公式计算得知：查找时间（10 ms） * 查询的列的数量 * 查询的数据块的数量。
处理大量短查询
可以在单个服务器上每秒处理数百个查询（在最佳的情况下最多可以处理数千个）。但是由于这不适用于分析型场景。建议每秒最多查询100次。
数据写入性能
建议每次写入不少于1000行的批量写入，或每秒不超过一个写入请求。当使用tab-格式将一份数据写入到表中时，写入速度大约为50到200MB/s 。如果您写入的数据每行为1Kb，那么写入的速度为50，000到200，000行每秒。如果您的行更小，那么写入速度将更高。为了提高写入性能，您可以使用多个进行并行写入，这将带来线性的性能提升。