数据分片与路由

在大数据背景下，数据规模已经由GB级别跨越到PB级别，单机明显无法存储与处理如此规模的数据量，只能依靠大规模集群来对这些数据进行存储和处理，所以系统可扩展性成为衡量系统优劣的重要指标。传统并行数据库系统为了支持更多的数据，往往采用纵向扩展( Scale Up)的方式，即不增加机器数量，而是通过改善单机硬件资源配置来解决问题。而目前主流的大数据存储与计算系统通常采用横向扩展( Scale Out )的方式支持系统可扩展性，即通过增加机器数目来获得水平扩展能力。与此对应，对于待存储处理的海量数据，需要通过数据分片( Shard/Partition)来将数据进行切分并分配到各个机器中去，数据分片后，如何能够找到某条记录的存储位置就成为必然要解决的问题，这一般被称为数据路由( Routing)。

数据分片与数据复制是紧密联系的两个概念，对于海量数据，通过数据分片实现系统的水平扩展，而通过数据复制来保证数据的高可用性。因为目前大规模存储与计算系统都是采用普通商用服务器来作为硬件资源池的，形式各异的故障经常发生，为了保证数据在故障常发环境下仍然可用，需要将同一份数据复制存储在多处来获得保证。同时，数据复制还可以增加读操作的效率，客户端可以从多个备份数据中选择物理距离较近的进行读取，既增加了读操作的并发性又可以提高单次读的读取效率。

抽象模型

就是二级索引，一级映射是Key-partition映射，根据key找到数据对应的partition，第二级映射是partition-machine映射，将数据分片映射到物理机器中，这也就是一台物理机可以容纳多个数据分片。

哈希分片与范围分片策略都可以映射到这个抽象模型上来，对于哈希分片来说，因为其主要通过哈希函数来建立key-partition映射关系，所以只支持“点查询”( Point Query)，即根据某个记录的主键( key)获得记录内容，而无法支持“范围查询”( Range Query)，即指定记录的主键范围一次读取多条满足条件的记录。采取哈希分片的实际系统众多，大多数KV (key-value，键值)存储系统都支持这种方式，其中包括Dynamo、Cassandra. Riak 、Voldmort、 Membase 等。相对应地，范围分片的系统则既可以支持点查询也可以支持范围查询，采取范围分片的系统包括Google的BigTable和微软的Azure等系统，但也有系统同时提供两种方式，比如Yahoo的PNUTS系统。

哈希分片

1.Round Robin

也就是哈希取模法，取模得到的结果对应一台物理机，实现起来非常简单，但是会将机器个数与映射函数捆绑在一起，缺乏灵活性。如果增加物理机，需要重新计算，所有数据重新分配，很麻烦。

2.虚拟桶

第一层映射关系是数据哈希取模后得到的结果对应一个虚拟桶，数据和虚拟桶是多对一的映射关系，第二层映射关系是虚拟桶对应物理机，也是多对一关系。像是一个表，类似hbase的metastore，这种存储方式本人感觉就是hbase的存储方式。

3.一致性哈希

哈哈，我也不会。

范围分片

范围分片首先将所有记录的主键进行排序,然后在排好序的主键空间里将记录划分成数据分片，每个数据分片存储有序的主键空间片段内的所有记录。在实现具体存储系统时，往往保持一个数据分片的映射表，记录表每一项记载数据分片的最小主键及其对应的物理机地址。在对记录/增/删/改时，查找映射表就可以找到对应存储这个记录所在数据分片的物理机，至于数据分片在物理机的管理方式往往采用LSM树，这是一种高效写入的数据索引结构。