Solr 4.5：什么时候Solr方面查询比简单查询更好？

我正在使用ApacheSolr，希望获得有关一些查询选项的更详细信息。我发现了facet查询，并想知道它们究竟什么时候带来了本质优势；特别是在以下示例中：

Solr服务器上保存有大量书籍。尽管一本书应该具有一些共同的属性，但它们有一个ISBN。有关书籍的数据由第三方提供，因此检查系统中是否存在双重ISBN非常重要。为了检查一本书的ISBN是否是重复的，它必须经过一个路由路径，不幸的是，每本书都是单独处理的，没有任何关于前后处理的信息

问题是：
a） 您是否应该简单地使用当前图书ISBN查询Solr并检查总结果，或者
b） 您是否应该发送一个带有

f.isbn.facet.mincount=2的facet查询，并检查结果是否包含当前图书isbn

在这两种情况下，缓存结果都是不可能的。因此，查询的数量始终等于处理的图书数量。我只是不知道Solr在内部是如何工作的，因此在没有进一步信息的情况下无法做出此决定，特别是因为上述任何一种可能性都不会减少查询的数量。
如果要执行查询，请执行查询。Lucene在执行查询方面进行了高度优化，因此您应该这样做。facet查询用于从任意查询创建facet（计数），因此在内部它也做同样的事情。如果生成一个方面，然后迭代该方面，Lucene需要查看的文档要比只查询一个值多得多

获得性能提升的最佳策略是成批执行这些操作-在同一批中检查500本图书（即
isbn:（123或321或567或765）
），然后在代码中处理这些操作。如果这些更新可以从多个系统并行到达，而不经过单个源，那么您必须决定在流中出现任何重复之前可以花费多少时间（这种竞争条件也可能发生在一本书上，因为两个流可以查询一个isbn，并在将其与两个流分别相加之前得到一个否定的结果）