MongoDB从版本2.6开始引入Bulk()，我检查了API，这对我来说似乎很棒。
在此API之前，如果我需要进行批量插入，我必须将文档存储在List中，它们使用insert()来插入整个List。在多线程环境中，还应考虑并发性。
Bulk.insert()或Bulk.find().update()，是吗？db.collection.initializeUnorderedBulkOp()类似，因此如果未发布批量实例，它将保持与MongoDB服务器的连接，是吗？答案 0 :(得分：3)
从＆＃34;的基本概念来看，你需要存储自己的列表吗？＆＃34;然后不是真的，但我想这一切都取决于你在做什么。
有关Bulk Operations API下最佳观点的内容的基本概念，请参阅每个type of operation的各个命令表单。因此，相关的手册部分为here。
因此，您可以将"Bulk"接口视为您添加到其中的所有操作的列表或集合。并且您可以根据自己的意愿添加（在某些内存和实际约束中），并考虑＆＃34;排除＆＃34;这个＆＃34;队列的方法＆＃34;是.execute()方法。
正如那里的文档中所指出的那样，无论你有多少次操作，排队＆＃34;这实际上只会以最多1000次操作的形式实际发送到服务器。另外要记住的是，没有任何治理可以确保这1000个操作请求实际上符合16MB BSON限制。所以这仍然是MongoDB的一个硬性限制，你只能有效地形成一个＆＃34;请求＆＃34;在发送到服务器时总数小于数据限制的时间。
所以一般来说，制作自己的＆＃34;执行/排水＆＃34;通常更实际。每1000个或更少的条目请求一次到服务器。里程可能因此而有所不同，但这里需要考虑一些因素。
关于＆＃34; Ordered＆＃34;或者＆＃34; UnOrdered＆＃34;操作请求，在前一种情况下，所有排队操作将在发送的批处理中生成错误时中止。 所有操作的含义当遇到错误后发生。
在后一种情况下，＆＃34; UnOrdered＆＃34;操作，没有报告致命错误，而是在返回的WriteResult中得到一个＆＃34;列表＆＃34;除了＆＃34; UnOrdered＆＃34;以及遇到的任何错误意味着操作不一定＆＃34;应用＆＃34;以任何特定的顺序，这意味着你不能排队＆＃34;依赖＆＃34;队列＆＃34;中的其他东西的操作在应用该操作之前进行处理。
因此，人们担心您将获得多大的WriteResult，以及您在应用程序中如何处理该响应。如前所述，里程数可能会有所不同，这可能是对较小且易于管理的响应的非常大的响应。
就目前而言，并发性问题确实存在一件事需要考虑。即使您在一次通话中向服务器发送许多指令而不是等待单独的传输和确认，它仍然只是一次只处理一条指令。这些是初始化方法暗示的有序，或者＆＃34;无序＆＃34;在哪里选择，当然操作可以在＆＃34; parallel＆＃34;因为它在服务器上，直到批次耗尽。
但是没有＆＃34;锁定＆＃34;直到＆＃34;批次＆＃34;完成，所以它不能替代＆＃34;交易＆＃34;，所以不要把这个错误作为设计点。相同的MongoDB规则适用，但这里的好处是＃34;一次写入服务器＆＃34;并且＆＃34;一个回复＆＃34;而不是每个操作的回复。
最后，关于是否有一些＆＃34;服务器连接＆＃34;通过API在这里举行，然后答案是没有。正如查看命令内部的初始点所指出的那样，＃＆＃34;队列＆＃34;建筑仅仅是客户方＃34;在调用.execute()方法之前直到，才会以任何方式与服务器进行通信。这是＆＃34;设计＆＃34;实际上只有一半，因为我们主要不希望每次添加操作时都向服务器发送数据。它是一次完成的。
所以＆＃34;批量运营＆＃34;是一个＆＃34;客户端队列＆＃34;。一切都存储在客户端，直到.execute()＆＃34;排水＆＃34;队列并一次性将操作发送到服务器。然后，从服务器给出一个响应，其中包含您可以根据需要处理的所发送操作的所有结果。
此外，一旦.execute()被调用，不再操作可以排队＆＃34;对于批量对象，也不能再次调用.execute()。根据实施情况，您可以进一步检查＆＃34; Bulk＆＃34;对象和结果。但一般情况下，您需要发送更多＆＃34; bulk＆＃34;操作，重新初始化并重新开始，就像对大多数队列系统一样。
总结：
.execute() 所以这是一个非常好的工具。您可以从遗留命令实现中获得更好的写入操作。但是，不要指望这提供了MongoDB基本上做的功能。