我在MongoDB中插入了一些大型文档（〜100个），每个文档约10个字段。但是其中许多（也许全部，但通常为80％左右）已经存在于数据库中。这些文档代表了接下来几个月中即将发生的事件，我每两天更新一次数据库。因此，大多数事件已经在那里。
任何人都知道（或想猜测）是否会更有效：
db.collection.insert(myArray, {continueOnError: true}, callback)
单独插入，首先检查_ID是否存在？
首先进行大移除（例如db.collection.delete({_id: $in : [array of all the IDs in my new documents] })，然后进行大容量插入？
我可能会做＃1，因为那是最简单的，我不认为100个文档那么大，所以没关系，但是如果有10,000个文档呢？如果重要的话，我正在使用node.js驱动程序在JavaScript中进行此操作。我的背景是在Java中，异常耗时，这是我要询问的主要原因-“ continueOnError”选项会很耗时吗？？？
添加：我认为“ upsert”没有意义。那是为了更新单个文档。就我而言，代表即将发生的事件的单个文档没有更改。（嗯，也许是，这是另一个问题）
发生的情况是将添加一些新文档。
我的背景是在Java中，异常耗时，这是我要询问的主要原因-“ continueOnError”选项会很耗时吗？？？
批量插入的ContinueOnError标志仅影响批处理的行为：不会处理遇到的第一个错误，而是将处理整个批处理。
在MongoDB 2.4中，批处理只会出现一个错误，它将是遇到的最后一个错误。这意味着，如果您确实关心捕获错误，则最好进行单个插入。
批量插入与单个插入相比，主要节省的时间是减少网络往返。驱动程序无需将插入的每个文档发送到MongoDB服务器的消息，而是可以将批量插入细分为最多服务器MaxMessageSizeBytes可接受的数量mongod（当前为48Mb）。
考虑到您只需要插入100份（甚至1000份）文档（其中80％已经存在）的用例，使用批量插入可能不会有很大的好处（特别是如果此过程仅每隔几天执行一次）。您的小插页将成批合并，但是实际上不需要将80％的文档发送到服务器。
我仍然倾向于使用批量插入而ContinueOnError不是使用删除和重新插入的方法，但是考虑到要处理的文档数量和实际需要插入的百分比，批量插入可能是不必要的早期优化。
我建议使用不同的方法进行几次运行，以了解对您的用例产生的实际影响。
值得一提的是，MongoDB 2.5开发系列（将在2.6生产版本中达到顶峰）将显着改善批处理功能。计划的功能包括对批量更新的支持，并累积每个文档的错误，而不是每个批次的单个错误。
新的写命令将需要更改驱动程序来支持，但可能会更改上述某些假设。例如，ContinueOnError使用新的批处理API，您最终可能会获得80％的重复ID作为批处理ID的结果。
有关更多详细信息，请参阅MongoDB问题跟踪器中的父问题SERVER-9038。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句