Cloud Design Pattern - Sharding Pattern(分片模式) [上篇]

1.前言

上一篇我们讨论了云计算设计模式之调度代理主管模式,了解了在多任务处理系统中,如何设计出支持内部异常处理,外部资源访问重试机制的架构.这一篇,我们讨论下数据处理的分片切割模式.该模式的目标是提升系统性能及扩展性,尤其是针对大数据处理方面,能够在不使用Hadoop或者Spark方面最大限度地提升数据处理效率.

2.问题

存储在单一服务器上的数据会受到以下约束:

1）存储空间.大规模的云应用的数据存储往往数据量庞大,增长快速.服务器虽然可以通过给硬盘扩容来增加存储空间,但是容量是有上线的,而且随着应用运行的周期越来越长,硬盘扩容或者替换变得越来越难.

2）计算资源.大规模的云应用往往需要处理多用户并发请求,每个请求都需要对大量数据进行查询,存储和更新操作.单一的服务器难以支撑大量的并发请求,用户请求的响应时间会变得无法接受,甚至返回超时错误.虽然可以通过给服务器增加CPU或者内存,但是这些资源都是有上限的.

3）网络吞吐.系统响应的速度和网络情况有关.如果请求和访问的网络流量大于服务器的网络最大可承载量,则会出现请求失败.

4）地理位置.大型数据处理中心往往分布在不同的地域,因为需要为了为某些地域的用户提供更好的响应速度.

增加磁盘,计算能力,内存和网络可能会延迟这些操作带来的不利影响,但是无法突破限制屏障,这些措施仅仅只是临时解决方案而已.商用的云计算系统必须承载大数据的处理,仅仅支持垂直扩展是不够的.

3.解决方案

将数据水平切分成多个部分,每个部分有相同的数据结构,每个部分的数据包含按照某种分类的一部分.可以根据需求增加硬盘即可.这种方式可以带来如下好处:

1）几乎无限扩容（扩充存储节点）

2）减少系统维护费用;

3）通过在数据存储节点间增加负载均衡机制来提升性能和减少资源冲突.

4）在云中,应用可以选择地理上距离用户比较近的数据来操作。

当把数据划分成若干个部分之后,就不需要通过一种机制去建立从请求到具体数据块的映射。通常我们称之为shard key或者partition key.当应用需要与数据交互的时候,应用通过映射逻辑知道去操作哪个数据块.通常这种映射机制将逻辑地址映射到物理地址。值得注意的是,分区的机制是根据应用的具体应用需求来确定的,比如多租户的数据可以根据租户ID来分区,销售数据可以根据年度来分区等等。通常来说,需要确定系统里面最常用的查询的需求来设计分区策略。

4.分区策略

分区策略虽然需要根据应用需求来设计,但是常见的分区策略如下:

1) The Lookup strategy

2) The Range strategy

3) The Hash strategy

关于这三种模式的优势和需要考虑的问题如下:

常见的分区模式都是上述几种的实现,但是在实际的应用中,您可能还需要有基于需求的更多的考虑(以多租户应用为例):

1) 按照工作负载进行分区.某些用户本身就有很好的数据访问性能,而另外一些则不是,所以需要把数据按照性能高低加以区分来分区.

2) 按照租户的地理位置进行区分.按照租户通常的登录位置来实现数据分区,在线下来做数据迁移，线上业务操作时数据的处理会更快.

3) 根据用户的等级来区分.为一些VIP用户划分单独的高性能数据存储区.

4) 某些由于安全或者特殊需要必须进行隔离的,最好将数据分区放置在单独的服务器上.

5.扩展和数据迁移操作

每一种分区策略都有不同的能力,在横向扩展,纵向扩展,数据迁移,状态维护时的复杂度也不尽相同.官方说法如下(为了方便理解,就不翻译了):

The Lookup strategy permits scaling and data movement operations to be carried out at the user level, either online or offline. The technique is to suspend some or all user activity (perhaps during off-peak periods), move the data to the new virtual partition or physical shard, change the mappings, invalidate or refresh any caches that hold this data, and then allow user activity to resume. Often this type of operation can be centrally managed. The Lookup strategy requires state to be highly cacheable and replica friendly.

The Range strategy imposes some limitations on scaling and data movement operations, which must typically be carried out when a part or all of the data store is offline because the data must be split and merged across the shards. Moving the data to rebalance shards may not resolve the problem of uneven load if the majority of activity is for adjacent shard keys or data identifiers that are within the same range. The Range strategy may also require some state to be maintained in order to map ranges to the physical partitions.

The Hash strategy makes scaling and data movement operations more complex because the partition keys are hashes of the shard keys or data identifiers. The new location of each shard must be determined from the hash function, or the function modified to provide the correct mappings. However, the Hash strategy does not require maintenance of state.

所以,综上所述,在决定使用哪一种分区策略之前,我们需要考虑以下因素...

这一篇比较长,分成上下两篇,未完待续,敬请期待...