设为首页 收藏本站
查看: 968|回复: 0

[经验分享] MongoDB Sharding学习理论篇

[复制链接]
累计签到:1 天
连续签到:1 天
发表于 2015-1-7 08:16:11 | 显示全部楼层 |阅读模式
MongoDB Sharding技术是MongoDB为了解决随着数据量的增加和读写请求的增加,单个MongoDB实例无法应对的问题.通过使用Sharding,MongoDB将数据切分成多个部分,将数据分布存放在多个shard上.Sharding技术使单个shard处理请求减少和存储容量减小,同时,随着集群的扩大,整个集群的吞吐量和容量都会扩大.



sharded-collection.png




Sharded cluster分片集群有以下几个组件:shards,query routers,config servers.
shards: 用来存储数据,为这个分片集群提供高可用和数据一致性。在一个生产环境中,每个shard都是一个replica set。


query routers: 或者是mongos实例,用于与应用程序交互,将请求转发到后端的shards,然后将请求结果返回给客户端。一个分片集群可以有多个query router即mongos实例用于分摊客户端的请求压力。

config servers: 用于存储分片集群的元数据。这些元数据包含整个集群的数据集合data sets与后端shards的对应关系。query router使用这些元数据来将客户端请求定位到后端相应的shards。生产环境的分片集群正好有3个config servers。



sharded-cluster-production-architecture.png




MongoDB Sharding是在Collection即集合层面来分布存储数据的,Sharding依据shard key来讲一个集合的数据来分布存储。
为了将一个集合的数据进行分片,首先需要选择一个shard key。一个shard key可以是存在于一个集合中每个文档的索引字段或者符合索引字段。MongoDB将这个shard key的值切分成多个数据块,然后将这些数据块均匀分布到后端的shard上。MongoDB使用range based partitioning 或者 hash based partitionning来讲一个shard key的值进行切分。


Range Based Sharding
sharding-range-based.png
Given a range based partitioning system, documents with “close” shard key values e likely to be in the same chunk, and therefore on the same shard.


Hash Based Sharding

对于hash based partitionning,MongoDB会先计算一个字段值得哈希值,然后使用这些哈希值来创建数据块。


sharding-hash-based.png




With hash based partitioning, two documents with “close” shard key values are unlikely to be part of t same chunk. This ensures a more random distribution of a collection in the cluster.



Performance Distinctions between Range and Hash Based Partitioning
Range based partitioning支持更有效的范围查询。对于一个shard key给定一个范围查询,query router可以更容易地判断将请求只路由到包含相应数据库的shard上。

Range based partitioning可能会导致数据分布不均,这样会对sharding产生负面作用,比如会出现大部分请求被分发到同一个shard的情况发生。



Hash based partitioning可以确保数据平均分布,但是这样会导致经过哈希处理的值在各个数据块和shard上随机分布,进而使制定的范围查询range query不能定位到某些shard而是在每个shard上进行查询。



Customized Data Distribution with Tag Aware Sharding
MongoDB允许使用tag aware sharding来根据shard key的范围创建并关联一些tag到后端的shards。主要用于同一个分片集群数据分布到多个数据中心的情况。




Maintaining a Balanced Data Distribution

随着数据的增加或者是服务器的增加都会导致整个分片集群的数据分布不均衡,比如一个shard比其他shard上的数据库chunk明显多了很多,或者一个数据块chunk的大小明显比其他chunk大很多。

MongoDB使用两个后台进程来确保一个均衡的分片集群,它们分别是splitting和balancer.


Splitting
Splitting是一个防止chunk变得太大的后台进程,当一个chunk大小超过了指定的大小,MongoDB将会把这个chunk分成两半。插入和更新操作都会触发split。
sharding-splitting.png


Balancing
balancer是一个用于管理chunk迁移的后台进程。

当一个分片集群中一个分片集合的数据分布不均衡时,balancer进程会把拥有最多chunk的shard上的chunk迁移到拥有最少chunk的shard上,直到这个集合的数据分布均衡为止。例如,集合user在shard 1上拥有100个chunk,在shard2上拥有50个chunk,balancer进程会将shard1上的chunk迁移到shard2,直到两个shard上的chunk数量保持均衡位置。
向一个分片集群中添加或删除shard都会影响整个集群的均衡性。


Primary shard

每个数据库都会有一个primary shard存储这个数据库中所有未被分片的集合数据。


sharded-cluster-primary-shard.png


运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-40305-1-1.html 上篇帖子: 【MongoDB学习笔记17】MongoDB的查询:find中的数组查询 下篇帖子: 【MongoDB学习笔记18】MongoDB的查询:find查询内嵌文档
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表