Shard

Shard 指对数据的水平切分,每一个切分的部分都可以叫做一个shard,它们拥有相同的 schema,但却拥有不同的数据集。对数据库来说，是指对数据库的表按行进行切分(与按列的垂直切分对应)，不同的 shard 可能位于不同的数据库服务器或者物理机器上。它的优势体现在以下几点:

• 表的大小减少,索引体积减小,提升查询性能(某些方面)
• 如果数据本身有比较明显的分区(比如国家,地区等),那么做 shard 很容易并且查询很大程度上都能落在一个 shard 上。
• 水平扩展性好，可以通过添加新节点来扩充

劣势有以下几点:

• 查询需要跨多个 shard 时会增加 latency
• 因为 shard 经常只能做到某一位维度。所以在这一维度的查询的性能可能提高，但其他维度的查询的性能则可能会下降。
• 跨 shard 的数据一致性和可用性也更加复杂和难以保障

shard 本身的问题让他成为一个迫不得已的选择。尽量在没有其他优化方式的情况下选择 shard.理想情况下，应该有底层框架来处理 shard 而让应用层做到对 shard 无感知，不然还不如不用。

如果将数据集进行 shard,有很多策略可以选择，常见的有

The Lookup strategy

用 shard key 做一个映射表，包含不同 shard key 的请求会转发到相应的 shard 上。这种情况下，不同 shard key 的数据可能会落在同一个 shard 上，但相同 shard key 的数据则一定在同一个 shard 上.shard 与物理地址的映射也不能是一对一的，可以用类似于 consistent hashing 里面的那种 virtual node 的方式，设置一些virtual shard，几个 virtual shard 可以对应于同样的物理位置(reblancing 的时候对上层代码的影响很小)。

The Range strategy

适用于需要获取区间连续数据的场景。与第一种策略类似，用 shard key 做分区，但 shard key 是按顺序排列的，每个 shard 内部的数据也经是有序的.(通常有一个 row key 用来在内部排序).

The Hash strategy

为了分散数据和请求，也可以用 hash 函数对数据做分片。上面两种策略避免不了的一个问题是,假如有一些数据是热点数据，那么他们很可能是位于少量的几个 shard 上，这样就造成了负载的不均衡。而利用 hash 函数则能尽量将热点数据分散开，必要时还可以加入一些随机元素来提高随机性.

Block Range Index.是一种作用于数据库索引上的类似于 shard 的技术。图示；

数据库里的数据在磁盘里存储时也是按 block 存储，通常也是按 key 的顺序。那么 BRIN 相当于对每一个 block 的一个描述:我拥有的最大值是多少，最小值是多少。对于查询来说，它知道了这个信息之后，发现目标值不在这个 block 的最小和最大值范围之间，那就可以直接跳过这个 block.因为对于每个 block 只需要存一个 tuple 的值，内存占用很小，所以所有的 BRIN 信息都可以放在内存中(相比较而言 B-Trees 的 index 信息如果全放置在内存中占用会比较高)

• 对于读的场景来说，尤其是需要顺序扫描索引，用 B-tree 结合 BRIN 能够提高查询速度
• 索引的一个坏处是会降低写入的速度，因为在写入的时候要一直维护索引。已经有各种优化措施，但是也比较复杂，很多场景也不实用。考虑用 BRIN 来代替普通索引的话，能够极大地减少维护索引的开销
• 对于非常大的数据集，B-tree 索引可能需要水平切分.创建 BRIN 的开销相比而言就要小的多，并且速度也更快。

对于随机性比较强的数据集或者有明显热点数据集的场景,BRIN 不是很合适。因为它的作用是用来排除区间，上述两种场景并不能有效地排除有效的数据区间。