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

[经验分享] MongoDB的操作因素和数据模型

[复制链接]

尚未签到

发表于 2018-10-27 06:22:19 | 显示全部楼层 |阅读模式
  MongoDB的建模应用程序数据取决于数据本身,也跟MongoDB的特性有关。比如,不同的数据模型可能提高应用程序的查询效率,提高插入和更新操作的吞吐量,让分片集群更有效的提高分发效率。
  这些处理或记录需求的因素,出现在应用程序以外,但是会影响以MongoDB为数据库的应用。当创建数据模型时,在下述场景下需要考虑应用程序的读操作和写操作。
  文档增长
  
  更新文档可能会导致文档大小的增加,这些更新包括添加元素到数组,添加新字段到文档中等等。如果文档增长的大小打到了文档允许的最大大小,MongoDB会重新分配磁盘上的文档。重新分配文档会占用比更新文档更长的时间,并且可能会导致文档碎片。尽管MongoDB自动填充文档分配来将重新分配的可能性最小化,但数据建模时应尽可能避免文档增长。
  例如,如果你的应用程序更新会增加文档大小,你应该重构数据模型,在不同文档之间使用引用而不是使用非规范化的数据模型(Embeded Data Model)。
  MongoDB的自适应调整有利于减少数据的迁移,你可能想要使用一种预分配的模式避免文档的增长。
  原子性
  在MongoDB中,文档级别的操作都是原子性的,没有一个写操作可以自动影响到多个文档或多个集合。在一个集合中修改多个文档时,需要在每个文档上都操作一次。为确保应用程序在一个文档中存储存储所有原子性需求的字段,如果应用程序能够容忍非原子性两块数据的更新,你可以这些数据存储在不同的文档中。
  使用嵌入式数据模型有利于在一个文档中完成这些原子操作。对于那些将相关数据通过引用模式存储的数据模型,应用程序必须通过不同的读和写操作来完成查询和修改这些相关的数据。
  分片
  
  MongoDB通过分片提供水平扩展。这些集群支持部署大数据集合和高通量操作。分片允许用户将数据库中的一个集合分割成多个Mongod实例或分片的多个文档集合。
  MongoDB使用分片关键字来分发数据和访问量。选择合适的分片关键字可以提高程序的性能,并且能够启动或关闭查询隔离来提高程序的写性能,所以,一定要仔细考虑好分片的字段。
  索引
  
  使用索引能够提高普通的查询性能。索引经常建立在频繁使用查询并且在所有的操作中返回排序的数据。MongoDB会在_id字段上建立索引。
  MongoDB使用索引时,需要考虑以下场景:
  (1)每个索引需要至少8kb的数据空间。
  (2)添加索引会影响写操作的性能。对于那些高速读写的操作,在每次插入或更新时索引的更新代价是高昂的。
  (3)高读写的集合通常受益于额外的索引,索引不会影响没加索引的读操作。
  (4)活动状态下,索引会占用磁盘的硬盘和内存。这种占用是很费资源的,应该监控系统的规划容量,尤其是工作集的大小。
  大数据集合
  
  在某些情况下,可能会考虑将相关的数据存储在几个不同的集合里,而不是在一个集合中存储。
  考虑一下logs集合用来存储不同的环境变量和应用程序的情形,logs集合由以下类型的表单组成:
{ log: "dev", ts: ..., info: ... }  
{ log: "debug", ts: ..., info: ...}
  如果文档的数量太少的话,你可能会按照类型去为文档分组。对于logs来说,考虑维护不同的日志的集合,比如logs_dev和logs_debug。logs_dev集合只会包含开发环境有关的文档。
  一般来说,大量的数据集合不会有显著的性能影响,仍然是高性能的。不同的集合对于高通量的集合是非常重要的。
  当模型中有大量集合时,需要考虑以下场景:
  (1)每个集合都有最少的几kb的开销。
  (2)每个索引,包括_id上的索引,都需要至少8kb的数据空间。
  (3)对每个数据库而言,每个命名空间(.ns文件)存储了数据的所有元数据。并且每个索引和集合有自己条目的命名空间。MongoDB的命名空间文件的大小是有限制的(不能超过2047MB)。
  (4)MongoDB限制命名空间的数量(命名空间的大小除以628)。如果想要知道当前命名空间的序号以便于知道还有多少可以使用命名空间,在Mongo shell中运行以下命令即可:
db.system.namespaces.count()  命名空间的大小取决于.ns文件的大小,默认的命名空间的大小是16MB。
  要改变命名空间文件的大小,在启动server时加入如下参数即可:
--nssize   对于已经存在的数据库,使用-nssize参数启动server后,运行以下命令即可。
db.repairDatabase()  数据生命周期管理
  数据建模也应该把数据生命周期管理考虑在内。
  所有的文档集合在使用一段时间后都会过期,如果应用程序需要存储一些数据在数据库中一段时间,考虑使用TTL(Time To Live)特性。
  另外,如果应用程序仅使用最近插入的文档。考虑使用限制的集合(Capped Collections)。Capped Collections使用先进先出的方式插入文档提高基于顺序插入数据的插入和读取文档的性能。



运维网声明 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-626885-1-1.html 上篇帖子: 如何设计MongoDB数据模型 下篇帖子: MongoDB数据关系建模
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

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

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

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

扫描微信二维码查看详情

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


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


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


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



合作伙伴: 青云cloud

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