大规模运行MongoDB应该知道的10件事_MySQL

MongoDB

MongoDB的首席解决方案架构师Asya Kamsky 最近发表了一篇文章，概括了大规模运行MongoDB需要知道的10件事。

1. MongoDB也需要DevOps。MongoDB是一个数据库。和任何其他的数据存储一样，它也需要容量计划、调整、监控和维护。不要因为它很容易安装、入门，同时与关系型数据库相比能够更加自然地满足开发人员的范例就认为MongoDB不需要适当的照顾和喂养。开发时它能在小样本数据集上超快地运行并不意味着你就不需要良好的模式、索引策略以及产品环境所需要的正确的硬件资源了。但是如果你准备的很好，并且理解最佳实践，那么运营大型MongoDB集群就会变得很无聊，而不是令人非常头痛。
2. 成功的MongoDB用户会监控所有的事情，同时会做好增长的准备。在任何数据库系统中跟踪当前的容量以及容量计划都是基本的实践，MongoDB也是如此。你需要知道集群现在能够支撑多少工作，最高使用率时它会处理哪些需求。如果你没有注意到服务器上增长的负载，那么最终会遇到没有足够容量的错误。监控MongoDB可以使用MongoDB管理服务（MMS），通过查看操作计数器（opscounters）图表可视化自己的操作：
3. 你可能并不希望系统随着使用量的增长出现性能扩展障碍。 根据大量用户的部署经验，性能瓶颈通常是（按顺序）：
   • 应用程序访问模式没有使用最优的模式设计
   • 索引不佳或者缺失索引，抑或有太多不必要的索引
   • 磁盘较慢/磁盘IOPS不足
   • 索引没有足够的RAM
4. 必须将数据写刷新到磁盘。如果磁盘利用率达到了100%，那么处理更多写操作的速度比起现在得不到丝毫的提升。可以通过MMS中的“Background flush average”图表查看将数据文件中的脏页刷新到磁盘花费了多长时间。通过这种趋势你会发现，随着写操作的增长，刷新将花费更多的时间。这种问题可以通过使用更快的磁盘解决，将工作拆分到更多的分片上，或者调整应用程序使之减少写数据的总量。你应该记住：写入的所有内容都会被刷新到磁盘两次——立即刷新到日志同时周期性地刷新到数据文件。将这两种操作分离到不同的物理设备上将会消除它们对可用磁盘IO带宽的竞争。
5. 复制 != 备份。所有人都清楚备份的重要性。但是为什么备份这么重要呢？ 想必是因为当某些影响所有复制集节点的灾难性事件发生的时候我们可以恢复数据。复制并不是备份的原因是：它并不能让你避免人为错误——例如某些人突然删除了产品数据，或者部署了错误版本的应用程序代码以致于搞乱了部分或者所有数据。必须要有一个能够让我们从这种场景中恢复数据的备份。通过文件系统快照、mongodump或者MMS备份练习数据恢复。第一次本文来源gaodaimacom搞#^代%!码网@从备份恢复产品数据的操作不应该发生在真正的“数据紧急事件”发生的时候。
6. 复制集的健康不仅仅是复制延迟。“复制延迟”仅仅是复制集健康状况的指标之一。关注复制操作日志（oplog）窗口和监控复制延迟一样重要。它表示的是基于现在的写流量完全“滚动”oplog所要花费的时间。换句话说，它指的是将一个复制节点拿下来以后依然能够重新加入集合而不必对所有数据进行重新同步的时间。随着时间的推移，复制操作日志窗口将会随着写负载的变化而浮动。流量高峰时窗口会缩短。这在容量计划中是非常重要的，你需要为最繁忙的数据吸收时间做好准备。下面是MMS中的一个并行视图，它展示了整个复制集的复制操作日志窗口。
7. MongoDB并不清楚数据需要什么样的安全级别。和其他数据库一样，你应该遵循最小特权原则。必须自己配置数据库的安全。不要让所有人都能访问你的数据。打开MongoDB自己本身的安全机制是非常重要的，但是这样也锁定了从任何地方对集群的访问，除非你确实认为自己的客户端进程可以在那里运行。只修改MongoDB进程的默认端口并不能保证安全。
8. 没必要修改引擎里面的东西。 除非文档或者MongoDB支持告诉你做一些非常特殊的事情，否则你没有必要直接修改系统集合、本地、管理或者配置数据库。你可以借助于管理命令和shell执行所需的操作，如果数据库并不能按照期望运行，或者某些地方发生了错误，那么成功的钥匙并不是试图通过直接操作内部的“bits”强制它运行。你需要熟悉的唯一一个“特殊的”、由系统产生的集合是分析器集合，定期地分析你的查询是确保事情按照期望运行的一个非常好的方式。

喜欢 (0)赏

[搞代码]

分享 (0)