我有相当大的数据库，有大约260万个文档，其中我有两个集合，每个集合120万，其余是小集合（＆lt; 1000个文档）。当我为小集合创建新索引时，需要花费大量时间来完成索引（因此临时索引是无用的）。似乎RavenDB索引进程读取DB中的每个文档并检查是否应将其添加到索引中。我认为仅索引索引使用的集合会更好。
另外，当使用Smuggler导出数据并且我只想导出一个小集合时，它会读取所有文档，导出可能需要花费很多时间。同时使用RavenDB Linq API和索引的自定义应用程序可以在几秒钟内导出数据。
为什么RavenDB会像这样？也许有一些配置设置可能会改变这种行为？
答案 0 :(得分：3)
RavenDB实际上并没有任何关于＆＃34;集合＆＃34;的真实概念。所有文件几乎都是一样的。它只是查看每个文档中的Raven-Entity-Name元数据，以确定如何将事物分组在一起，以便按类型查询和显示＆＃34;集合＆＃34;管理工作室的页面。
我不确定具体的理由。我认为这与文档商店使用的底层ESENT表有关。也许艾恩德可以更好地回答。您的特定用例是可以用不同方式完成的原因。
您可以尝试的一件事是使用多个数据库。您可以将大量文档放在一个数据库中，然后将其他所有文档放在另一个数据库中。当然，您可能在索引相关文档，多地图/缩小或其他不同类型的文档需要在同一数据库中的情况时遇到问题。
答案 1 :(得分：1)
似乎我的问题的答案来自RavenDB 3.0。艾恩德说：
在RavenDB 2.x中，您仍需支付索引的全价 一切，但在RavenDB 3.0中并非如此。我们所做的 是有效地优化过程，以便在这种情况下，我们将 预加载参与相关集合的所有文件， 并将它们直接发送到索引。
我们通过使用Raven / DocumentsByEntityName索引来完成此操作。哪一个 已经索引了数据库中的所有内容。这很好 小功能，因为它让我们真正利用了 我们很久以前就做过的工作。使用一个索引预先填充另一个索引 是一个巧妙的伎俩，我非常高兴。
这里有完整的博文：http://ayende.com/blog/165923/shiny-features-in-the-depth-new-index-optimization