加入收藏 | 设为首页 | 会员中心 | 我要投稿 惠州站长网 (https://www.0752zz.com.cn/)- 办公协同、云通信、物联设备、操作系统、高性能计算!
当前位置: 首页 > 教程 > 正文

带着问题学习分布式系统之数据分片

发布时间:2018-09-17 14:27:32 所属栏目:教程 来源:xybaby
导读:副标题#e# 正文 在前文中,提出了分布式系统(尤其是分布式存储系统)需要解决的两个最主要的问题,即数据分片和数据冗余,下面这个图片(来源)形象生动的解释了其概念和区别: 其中数据即A、B属于数据分片,原始数据被拆分成两个正交子集分布在两个节点上。而

上面的三种方式都提到了对数据的分片是基于关键值、特征值的。这个特征值在不同的系统中有不同的叫法,比如MongoDB中的sharding key, Oracle中的Partition Key,不管怎么样,这个特征值的选择都是非常非常重要的。

那么。怎么选择这个特征值呢?《Distributed systems for fun and profit》给出了言简意赅的标准:

  • based on what you think the primary access pattern will be

大概翻译为:基于最常用的访问模式。访问时包括对数据的增删改查的。比如上面的列子,我们选择“id”作为分片的依据,那么就是默认对的数据增删改查都是通过“id”字段来进行的。

如果在应用中,大量的数据操作都是通过这个特征值进行,那么数据分片就能提供两个额外的好处:

  • (1)提升性能和并发,操作被分发到不同的分片,相互独立
  • (2)提升系统的可用性,即使部分分片不能用,其他分片不会受到影响

如果大量操作并没有使用到特征值,那么就很麻烦了。比如在本文的例子中,如果用name去查询,而元数据记录的是如何根据按照id映射数据位置,那就尴尬了,需要到多有分片都去查一下,然后再做一个聚合!

另外一个问题,如果以单个字段为特征值(如id),那么不管按照什么分布方式,在多条数据拥有相同的特征值(如id)的情况下,这些数据一定都会分布到同一个节点上。在这种情况下有两个问题,一是不能达到节点间数据的均衡,二是如果数据超过了单个节点的存储能力怎么办?关键在于,即使按照分布式系统解决问题的常规办法 -- 增加节点 --也是于事无补的。

在这个时候,单个字段做特征值就不行了,可能得再增加一个字段作为“联合特征值”,类似数据库中的联合索引。比如,数据是用户的操作日志,可以使用id和时间戳一起作为hash函数的输入,然后算出特征值;但在这种情况下,如果还想以id为查询关键字来查询,那就得遍历所有节点了。

所以说没有最优的设计,只有最符合应用需求的设计。

下面以MongoDB中的sharding key为例,解释特征值选择的重要性以及对数据操作的影响。如果有数据库操作基础,即使没有使用过MongoDB,阅读下面的内容应该也没有问题。

以MongoDB sharding key为例

关于MongoDB Sharded cluster,之前也写过一篇文章《通过一步步创建sharded cluster来认识mongodb》,做了简单介绍。在我的工作场景中,除了联合查询(join)和事务,MongoDB的使用和Mysql还是比较相似的,特别是基本的CRUD操作、数据库索引。MongoDb中,每一个分片成为一个shard,分片的特征值成为sharding key,每个数据称之为一个document。选择适合的字段作为shardingkey非常重要,why?

(编辑:惠州站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

推荐文章
    热点阅读