当数据大小超过单机容量时，需要将数据拆分成为分区，又成为分片。（这里的分区对应着HBase中的region， bigtable中的tablet）
- 分区通常和复制结合使用， 即每个分区在多个节点上都存有副本，考虑主从复制模型，一个节点可能是某个分区的主副本，也是其它分区的从副本。
参见google file system中的块与Chunkserver的关系, 在spanner以及tikv中也有类似的设计，将分区与节点的概念分离，以便每个节点都尽可能地能承担主节点的责任，以充分利用集群资源
- 基于关键字的区间分区。 为每个区间分配一段关键字区间范围（分布式数据库中通常采用主键），关键字在这个区间内的数据的请求全部发往这个区间。 区间内数据还可以再排序，以更好地支持范围查询
- 缺点： 某些访问模式会导致热点，某些写入模式会导致某个区间的数据量远大于其他区间，即数据倾斜
- 解决方案：1、将数据分区拆分成较细粒度的分区（如200MB～800MB），然后由master在节点之间进行平衡，将某个分区从负载高的节点移动到负载低的节点。参见Bigtable与Tikv；2、对于数据量过大的区间，进行区间的分裂，即将分区[a,c)分裂成[a,b) 与[b,c)，其中a<b<c，如果该节点总体数据量过大，则移动[a,b)或[b,c)到另一个节点, 以保证每一个节点的数据量都尽可能均衡
- 基于关键字哈希值分区。一个好的哈希函数可以处理数据倾斜并使其均匀分布。
- 缺点： 失去了良好的区间查询特性，如果想要支持区间查询，则必须将查询请求发送给所有的分区，并汇总所有分区的查询结果。
- 极端情况下，当所有读写操作都是针对同一个关键字时， 哈希分区仍然无法避免负载倾斜与热点，例如社交网络上的名人发布的热门微博。
- 当采取主键分区时，如果又对别的列建立了二级索引，那么查询代价会非常大，他必须查询所有分区中的二级索引，然后再合并查询结果。如MongoDB，Ha3
- 另一种办法是建立全局的二级索引，例如Tikv，由于这样会导致索引和文档数据完全不在同一个分区，因此势必引起显著的写放大，同时如果索引要随着写入保持实时更新，还需要一个跨分区的分布式事务支持（见Percolator)）
- 见上文对于数据倾斜的解决方案
- 一致性哈希算法
- 给予强一致性共识算法的协调服务（如ZooKeeper、Etcd）