mongodb学习笔记

346279055

前一段时间研究了一下mongodb的官方手册（mongodb2.6），对其中一些进行了总结，供大家参考

每个数据库都有一个”主分片” [1] 用来存储这个数据库中所有未开启分片的集合的数据.
--------------------------------------------------------------------------------------------------------------------
分片为应对高吞吐量与大数据量提供了方法.
    使用分片减少了每个分片需要处理的请求数,因此,通过 水平扩展 ,集群可以提高自己的存储容量和吞吐量.
    举例来说,当插入一条数据时,应用只需要访问存储这条数据的分片.
    使用分片减少了每个分片存储的数据.
    举例来说,如果一个数据库有1TB数据,并有4个分片,则每个分片只需要存储256GB数据,如果数据库有40个分片,则每个分片只需要存储25GB数据.
在某些情况下,使用分片是 唯一 的解决办法,在以下情况下使用 集群 :
    你的数据接近或者超过一个MongoDB实例所能容纳的上限.
    系统中 working set 的大小接近系统的内存 上限 .
    单一的MongoDB实例不能满足写性能要求,并且所有其他方法都没有明显作用.
    如果这些特性在你的系统中都没有出现,使用分片只会增加系统的复杂程度,而不会带来什么好处.
-------------------------------------------------------------------------------------------------------------------
在测试与开发环境下,每个 分片 可以是单独的 mongod 而不用必须是复制集.在生产环境中 必须 部署3台配置服务器.
-------------------------------------------------------------------------------------------------------------------
基于范围的分片方式与基于哈希的分片方式性能对比
基于范围的分片方式提供了更高效的范围查询,给定一个片键的范围,分发路由可以很简单地确定哪个数据块存储了请求需要的数据,并将请求转发到相应的分片中.
不过,基于范围的分片会导致数据在不同分片上的不均衡,有时候,带来的消极作用会大于查询性能的积极作用.比如,如果片键所在的字段是线性增长的,一定时间内的所有请求都会落到某个固定的数据块中,最终导致分布在同一个分片中.在这种情况下,一小部分分片承载了集群大部分的数据,系统并不能很好地进行扩展.
与此相比,基于哈希的分片方式以范围查询性能的损失为代价,保证了集群中数据的均衡.哈希值的随机性使数据随机分布在每个数据块中,因此也随机分布在不同分片中.但是也正由于随机性,一个范围查询很难确定应该请求哪些分片,通常为了返回需要的结果,需要请求所有分片.
------------------------------------------------------------------------------------------------------------------
配置服务器在 config 数据库 中存储了集群的元信息, mongos 缓存了这个数据库用来做读写的路由分发.
如果集群中一个或者两个配置服务器不可用,集群的元信息将变为 可读 ,你还可以从分片中读写信息,但是数据块的迁移以及数据块的分裂在所有配置服务器都恢复可用之前不能够进行.
如果所有的三个配置服务器都不可用,在重启 mongos 之前集群依然可用. 但是一旦试图重启 mongos ,集群将不能提供任何服务.
没有集群的元信息,集群将不能正常工作,因此,要 时刻 保持配置服务器的可用和完整.因此,配置服务器的备份是很重要的.与分片中的数据相比,配置服务器存储的信息要小很多.这意味着配置服务器有相对较小的请求负载,而且对于集群的正常运行,并不需要所有配置服务器任意时刻都可用,所以,备份配置服务器是一件容易的事情.
如果集群使用的配置服务器变换了ip或者域名,你需要重启 所有 的 mongod 和 mongos .可以在集群部署时使用CNAMEs避免重启.
------------------------------------------------------------------------------------------------------------------
MongoDB中默认的 chunk 大小是64M,你可以 调整数据块的大小,但要注意到这有可能会集群造成性能影响.
    数据块大小较小时可以使得分片间的数据更均衡,但是是以频繁的迁移为代价的,会对 mongos 造成压力.
    数据块大小较大时会使得均衡较少,这从网络传输 与 mongos 的角度来说更高效,但是,这种高效是通过数据不均衡的加重为代价的.
在很多情况下,以分片间数据略微的不均衡来防止频繁的迁移或者无效的迁移,是合理的.
-------------------------------------------------------------------------------------------------------------------
为了使均衡对集群性能的影响减小到最低,在不同分片之间的数据块数量差异达到阈值时, balancer 不会开始工作,阈值是指集群中 chunks 最多的分片与数据块最少的分片之间数据块数量的差,均衡器有以下阈值:
在 2.2 版更改: 以下的阈值在版本2.2首次出现,在此之前,只有在集群中不同分片之间数据块的数量差达到8个时,均衡才会开始.
数据块的数量      迁移阈值
少于20个              2
20到79                4
80 and greater     8
-------------------------------------------------------------------------------------------------------------------
按照顺序操作分片:
    records 数据库中的 people 集合使用 { "zipcode": 1, "name": 1 } 片键开启分片.
    这个集合使用 zipcode 字段重新分配数据.如果很多文档都有相同的 zipcode 值, chunk 会按照 name 的值进行 分裂.
    people 数据库中的 addresses 集合使用片键 { "state": 1, "_id": 1 }.
    这个片键使用 state 字段重新分配数据.如果很多文档都有相同的 state 值, chunk 会按照 _id 的值进行 分裂.
    assets 数据库中的 chairs 集合使用 { "type": 1, "_id": 1 } 做片键.
    这个片键使用 type 字段重新分配数据.如果很多文档都有相同的 type 值, chunk 会按照 _id 的值进行 分裂.
    events 数据库中的 alerts 集合使用 { "_id": "hashed" } 做片键.
-------------------------------------------------------------------------------------------------------------------
在第一个 mongos 连接到一组 配置服务器 时, 会以默认的64M大小的数据块初始化集群,在大多数情况下,默认的大小工作得很好.然而,如果你发现在默认的数据块大小下,自动迁移锁花费的I/O超过了系统可承受的极限,可以将数据块大小调小.对于自动分裂和迁移,较小的数据块可以使得迁移速度较快且较频繁.合法的数据块大小在1M到1024M之间,包含1M和1024M
配置 chunkSize 和选项 --chunkSize 作为启动参数启动 mongos ,在初始化集群之后 不要 影响数据块大小.
为避免引起混乱,只使用 save() 修改数据块大小,而不使用在启动 mongos 时传递参数修改.
-------------------------------------------------------------------------------------------------------------------
在GridFS存储中,对 chunks 集合进行分片时, 只有 两个片键可以选择,``{ files_id : 1 , n : 1 }`` 与 {  files_id : 1 } .
-------------------------------------------------------------------------------------------------------------------