mongodb批量insert_oracle 批量insert_mybatis 批量insert

我收集了达到7,000万份文档.每当我批量添加新文档时(比如说2K),插入操作的速度都十分慢.我担心这是因为,mongo引擎正在将所有新文档的_id与所有7000万个文档的_id进行非常,以找出任何_id重复项.由于基于_id的键值位于磁盘上,因此会使代码运行缓慢.

无论如何有减少这些状况.我只期望mongo提取新文档并将其按原样插入mongodb批量insert,而不进行此检查.可能吗

最佳答案

诊断“慢”性能

您的难题包括有关MongoDB如何工作的许多主要假定.我将在以下解决这种弊端,但我建议您尝试按照指标(即serverStatus、mongostat、mongotop),系统资源监控并且MongoDB中有关慢速查询的信息等事实来认识任何性能问题.需要随着时间的推移来监控指标,以便您可以确认部署的“正常”情况,因此,我强烈建议使用MongoDB特定的监控软件,例如MMS Monitoring.

一些有趣的演示为性能疑难解答跟调试提供了相当相关的背景资料：

威廉·佐拉(William Zola)：The (Only) Three Reasons for Slow MongoDB Performance

> Aska Kamsky：Diagnostics and Debugging with MongoDB

提高刀片效率

除了知道实际性能挑战所在并微调部署之外,您还可以通过下面形式增加插入效率：

>删除此集合上任何已使用或冗余的二级索引

>使用Bulk API批量插入文档

评估假设

Whenever I add new documents in batches (lets say 2K), the insert operation is really slow. I suspect that is because, the mongo engine is comparing the _id’s of all the new documents with all the 70 million to find out any _id duplicate entries. Since the _id based index is disk-resident,it’ll make the code a lot slow.

如果一个集合有7000万个条目mongodb批量insert,这并不意味着索引查找涉及7000万个比较.索引值存储在B-trees中,这允许进行少量的有效比较.确切的数量将取决于树的深度,索引的建立模式或者要查找的值..但非常的数量约为10s(而不是数百万).

如果您真的对内部结构感到好奇,可以进行一些实验性存储&您可以在开发环境中引入的索引统计：Storage-viz: Storage Visualizers and Commands for MongoDB.

Since the _id based index is disk-resident, it’ll make the code a lot slow.

MongoDB将您的(最近访问的数据和索引条目的一部分)加载至可用存储中.

如果您就能以至少升序创建ID(例如,生成的ObjectId),则所有升级都将在B树的右侧进行,并且您的工作集会小得多(FAQ：).

Yes, I can let mongo use the _id for itself, but I don’t want to waste a perfectly good index for it. Moreover, even if I let mongo generate _id for itself won’t it need to compare still for duplicate key errors?

MongoDB中的所有文档都需要使用唯一的_id.默认ObjectId是基于要保证唯一性的推导生成的(即返回重复键异常的机会极低,因此您的应用程序将不会获得重复键异常,而需要使用新的_id重试).

如果您对文档中的唯一_id有更好的选用,那么可以随时使用此字段(或字段集合),而不必依赖于生成的_id.请注意,_id是不可变的,因此您不应使用之后也许要更改的任何字段.

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/ruanjian/article-140939-1.html