Mindon.IDEA

Air off, Mind on ~ / Javascript+Golang, Sci, Health… /

Notes on MongoDB

MongoDB资料汇总专题 http://blog.nosqlfan.com/html/3548.html

MongoDB 最佳实践

Original from http://www.oschina.net/question/12_38878

1. 始终启用备份

备份能保证你应用的高可用性。假如你的一个节点down了,第 二节点可以迅速启用,你的应用不会中断。

2. 使用最新版本

10gen在不断的发布更新,特别是2.0.x包含了很高的性能提升 和并行改进,索引改进和bug修复。如果你还在使用 1.6.3的话 ,你应该尽快升级。

3. 不要在32位的系统上跑MongoDB

MongoDB在32位系统上有“2.5GB数据限制”。它的存储引擎使用 内存映射来读取文件以获得更好的性能。这个功能依赖于内存 寻址,而32位系统的内存不能超过4GB。

4. 默认开启日志

MongoDB支持数据库操作的提前日志(write-ahead journaling )。这个功能有助于灾难恢复。

5. 注意你数据文件的位置

你应该保证你的MongoDB的数据文件是存储在物理驱动器上,例 如 /data/mongodb。当然你也可以使用虚拟的驱动器,但是必 须非常小心。因为它有可能会影响到你的集群架构。我们建议 你使用 Amazon EBS 来存放你的数据库文件。

6. 保证足够大的内存

为了保证整个集群的性能,你要确保整个所有MongoDB的工作实 例(working set)包括索引可以完全装入内存。如果你发现 “page faults”的概率在增加,很有可能mongoDB的数据量超出 了你的内存。在这种情况下你有两种选择:加内存,或者创建 分片集群(Sharding)。我们建议你先考虑加内存。

7. 保持 65% 以内的压力

如果你发现你的集群压力达到了65%,那么你应该考虑扩大你的 集群了。通常,你应该保证数据库压力低于65%。

8. 特别小心分片集群

分片集群需要你充分理解你应用的数据访问方式。你应该充分 了解MongoDB的分片工作方式,并且确认你确实需要这个功能。 还有,选择一个分片钥匙(sharding key)是对于性能也是很 重要的。

配置服务器对于一个集群的健康也是很重要的。在分片集群的 环境中,你必须有三台配置服务器。永远不要删除配置服务器 的数据,时常备份这些数据。这些配置服务器也需要64位的环 境。还有,不要把三台配置服务器放在同一台机器上!

9. 使用 Mongo MMS 来图形化的监控你的数据库

如果你还没有使用 Mongo MMS的话,我强烈推荐这个工具。 10gen 正在大力开发这个产品。它提供了一个非常友好的可视 化的界面来监控你的MongoDB集群。

10. MongoDB 资源

技术总是在不断进步,你需要市场关注这些信息:

MongoDB Best Practices 中文

MongoDB运行状态、性能监控,分析: http://blog.nosqlfan.com/html/3346.html

MongoDB容量规划: http://blog.nosqlfan.com/html/3322.html

MongoQ: https://github.com/zzdhidden/mongoq

MongoSpy, MongoWatch及MongoDB数据压缩

http://blog.nosqlfan.com/html/3205.html

五步优化你的MongoDB

  1. 查询优化 确认你的查询是否充分利用到了索引,用explain命令查看一下查询执行的情况,添加必要的索引,避免扫表操作。

  2. 搞清你的热数据大小 可能你的数据集非常大,但是这并不那么重要,重要的是你的热数据集有多大,你经常访问的数据有多大(包括经常访问的数据和所有索引数据)。使用MongoDB,你最好保证你的热数据在你机器的内存大小之下,保证内存能容纳所有热数据。

  3. 选择正确的文件系统 MongoDB的数据文件是采用的预分配模式,并且在Replication里面,Master和Replica Sets的非Arbiter节点都是会预先创建足够的空文件用以存储操作日志。这些文件分配操作在一些文件系统上可能会非常慢,导致进程被Block。所以我们应该选择那些空间分配快速的文件系统。这里的结论是尽量不要用ext3,用ext4或者xfs。

  4. 选择合适的硬盘 这里的选择包括了对磁盘RAID的选择,也包括了磁盘与SSD的对比选择。

  5. Shard分片 在单个节点压力太大时,我们可以考虑使用MongoDB的auto-sharding机制来将数据分片到多个节点以缓解压力。

火丁筆記: 记一次MongoDB性能问题

NUMA Problem(Warn) http://www.mongodb.org/display/DOCS/NUMA

shell> numactl –interleave=all /path/to/mongod

NUMA下,内存是按照物理CPU来划分的,不是按逻辑CPU/核划分的

每个核访问分配给自己的内存会比访问分配给其它核的内存要快,有下面几种访问控制策略:

  1. 缺省(default):总是在本地节点分配(分配在当前进程运行的节点上);

  2. 绑定(bind):强制分配到指定节点上;3.交叉(interleave):在所有节点或者指定的节点上交织分配;

  3. 优先(preferred):在指定节点上分配,失败则在其他节点上分配。

Comments