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

[经验分享] MongoDB分片之数据分割方式

[复制链接]

尚未签到

发表于 2015-7-6 10:50:52 | 显示全部楼层 |阅读模式
随着移动互联网的发展,大量的非结构化数据随之产生,不仅对数据库存储大数据提出了新的要求,同时对于查询数据和进行大数据分析也提出了苛刻的要求,这些显然是单服务器处理能力无法满足的,自然建立一个集群是不可避免的。集群的复杂性大家众所周知,而MongoDB的优势之一正式可以帮助我们解决这些问题。
分片(sharding)
分片是MongoDB提供的一种机制,其可以将大型的集合分割保存到不同的服务器上。与其他的分区方案相比,MongoDB几乎能自动为我们完成所有事情。只要我们进行简单的配置,并告诉MongoDB要分配的数据,它就可以自动维护数据在不同服务器之间的平衡。同时根据需要增减服务器,MongoDB也会自动移动平移已有数据。
分片机制提供了如下三种优势
1. 对集群进行抽象,让集群“不可见”。
MongoDB自带了一个叫做mongos的专有路由进程。mongos就是掌握统一路口的路由器,其会将客户端发来的请求准确无误的路由到集群中的一个或者一组服务器上,同时会把接收到的响应拼装起来发回到客户端。
2.保证集群总是可读写。
MongoDB通过多种途径来确保集群的可用性和可靠性。将MongoDB的分片和复制功能结合使用,在确保数据分片到多台服务器的同时,也确保了每分数据都有相应的备份,这样就可以确保有服务器换掉时,其他的副本可以立即接替坏掉的部分继续工作。
3.使集群易于扩展。
当系统需要更多的空间和资源的时候,MongoDB使我们可以按需方便的扩充系统容量。
实现数据分割
分片(shard)是集群中存储集合数据子集的一台或者多台服务器。在生产环境中一个分片通常是一个副本集(replica set)
DSC0000.png
片键(key)MongoDB以其作为依据来确定需要在不同分片服务器之间移动的数据。例如我们可以选择用户名(username)字段作为分片键,现有一用户名区间[“p”,”z”],那么wufengtinghai是属于这一区间的,那么数据最终会保存到与此区间对应的分片服务器上。
分配数据到分片服务器
分配数据到分片服务器可以使用不同的方式,了解不同的方式可以加深我们对MongoDB使用方式的理解。
一分片一区间
分配数据到分片最简单的方式莫过于一个区间一个分片。假设我们有四个分片存储用户的相关信息,则我们可能会得到如下的分片和区间的对应关系。
DSC0001.png
这种分片方式非常简单易懂,但是在一个大型繁忙的系统中却会带来许多的不便。假如大量的用户使用首字母在【“a”,”f”)中的名字来注册,这将会导致分片1比较大,因此需要将其一部分文档移动到分片2上,我们可以调整分片1对应区间【”a”,”c”),使分片2的区间变成【”c”,”n”)
DSC0002.png

如果移动数据后,分片2因此过载怎么办?假设分片1和分片2各有500G数据,而分片3和分片4各自有300G数据。那么按照这个方案,最终需要一连串的复制,总共算下来需要移动400G数据,考虑到需要在集群的服务器之间移动这些数据,可见移动数据量之大。
DSC0003.png

如果需要新加分片服务器进行水平扩展呢?假设此时每个分片上都有了500G数据,那么我们现在需要将分片4上的400G数据移动到分片5,将分片3300G数据移动到分片4,将分片2200G数据移动到分片3,将分片1100G数据移动到分片2,整整移动了1T的数据!
DSC0004.png

随着分片数量和数据量的增长,这种噩梦将会持续下去,因此MongoDB不会采用这种方式。
一分片多区间
如果我们采用一分片多区间的方式,我们可以将分片1上的数据划分为两个区间,【”a”,”d”)包含400G数据,【”d”,”f”)包含100G数据,同样我们也可以对分片2做类似的处理,得到区间【”f”,”j”)和【“j”,”n”)。现在我们只需要将分片1上的【”d”,”f”)数据移动到分片4,将分片2的【“j”,”n”)的数据移动到分片3。这样我们仅仅只需要移动200G数据。
DSC0005.png

如果要添加新分片,可以从每个分片顶端取100G数据并将其移动到新的分片上,这样仅仅只需要移动400G数据即可。
DSC0006.png


MongoDB就是利用这种方式,当一个分片的数据越来越大时,其会自动分割片键区间,并将分片的数据进行分割并移动到其他分片。

运维网声明 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-83761-1-1.html 上篇帖子: NOSQL数据库大比拼:Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase 下篇帖子: mongodb性能优化
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

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

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

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

扫描微信二维码查看详情

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


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


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


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



合作伙伴: 青云cloud

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