电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛

标题: Mongodb的生僻问题分析（3） [打印本页]

作者: look_w 时间: 2019-4-17 19:22 标题: Mongodb的生僻问题分析（3）

分片太迟

分片是把数据拆分到多台机器上，通常被用于Replica Set运行过慢时进行性能提升。MongoDB支持自动分片。然而如果你让分片进行太迟的话，问题就产生了。因为对数据的拆分和块的迁移需要时间和资源，所以如果当服务器资源基本上耗尽时很可能会导致在你最需要分片时却分不了片。

解决的方法很简单，使用一个工具对MongoDB进行监视。对你的服务器做最准确的评估，并且在占整体性能的80%前进行分片。类似的监视工具有：MMS、Munin（+Mongo Plugin）和CloudWatch。

如果你确定从一开始就要分片处理，那么更好的建议会是选用AWS或者类似的云服务进行分片。而在小型服务器上，关机或者是调整机器明显比转移成千上万条数据块来的更直接一点。

总结：尽早的分片才能有效的避免问题。

不可以更改文件中的shard key

对于分片设置，shard key是MongoDB用来识别分块对应文件的凭证。当你插入一个文件后，你就不可以对文件的shard key进行更改。而这里的解决方案是把文档删除然后重新建立，这样就允许把它指定到对应的分块了。

总结：shard key不可以修改，必要的时候可以删除文件重新建立。

不可以对256G以上的Collection进行分片

重新回到分片太迟的问题上来 —— MongoDB不允许对增长到256G以上的Collection进行分片，之前版本的设置还没有256G。这个限定在以后肯定会被移除，而这里也没有更好的解决方案。只能进行重编译或者把大小控制在256G以下。

总结：在Collection达到256G以前进行分片。

唯一性索引与共享

索引的唯一性约束只能通过shard key来保证。

更多详情

选择了错误的shard key

MongDB需要你选择一个shard key来将数据分片。如果选择了错误的shard key,更改起来将是件很麻烦的事情。

点击查看如何更改

总结：选择shard key之前先阅读这个文档。

与MongoDB通信的未经加密

与MongoDB的连接默认情况下都是非加密的，这就意味你的数据可能被第三方记录和使用。如果你的MongoDB是在自己的非广域网下使用，那么这种情况是不可能发生的。

然而如果你是通过公网访问MongoDB的话，那么你肯定会希望你的通信是经过加密的。公版的MongoDB是不支持SSL的。庆幸的是可以非常简单的定制自己的版本。10gen的用户则拥有特别定制的加密版本。幸运的是大部分的官方驱动都支持SSL，但是小麻烦同样是不可避免的。点击查看文档。

总结：当用公网连接时，要注意和MongoDB的通信是未加密的。

事务

不像MySQL这些支持多行数据原子操作的传统数据库，MongoDB只支持单文件的原子性修改。解决这个问题的方法之一是在应用程序中使用异步提交的方式；另一个是：建立一个以上的数据存储。虽然第一种方法并不适用于所有情况，但是很显然比第二个来的要好。

总结：不支持对多文件事务。

日志预分配慢

MongDB可能会告诉你已经准备就绪，但事实上它还在对日志进行分配。如果你选择了让机器自行分配，而恰巧你的文件系统和磁盘速度又很慢，那么烦恼的事情发生了。通常情况下这不会成为问题，但是一旦出现了可以使用undocumented flag –nopreallocj来关闭预分配。

总结：如果机器文件系统和磁盘过慢的话，那么日志的预分配也可能很慢。

NUMA + Linux +MongoDB

Linux、NUMA与MongoDB遇到一起的时候运行总是不会很好。如果你在NUMA硬件上运行MongoDB的话，这里建议是直接关掉。因为各种奇怪的问题随之而来，比如：速度会阶段性或者在CPU占用率很高的时候大幅下降。

总结：禁NUMA。

Linux里面的进程限制

如果你在MongoDB未满载的时候出过SEGMENTATION FAULT错误，你可能会发现这是因为使用了过低或者默认的打开文件或用户进程限制。10gen建议把限制设置在4K+，然而设置的大小该取决具体情况。阅读ulimit了解更多。

总结：长久的为MongoDB在Linux加上软或硬的打开文件或用户进程限制。

欢迎光临电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/)