Lucene - 很少或很多索引答案

【问题标题】：Lucene - few or a lot of indexesLucene - 很少或很多索引
【发布时间】：2012-01-26 10:10:18
【问题描述】：

是不是更好用

...如果你想：

我使用的是 elasticsearch，因此我使用的是 Lucene。

【问题讨论】：

用户搜索的是同一套文档还是不同的文档集？如果不同的集合，文档的性质是什么？
在我的示例中，每个用户都应该只看到他/她的文档。所以只使用一个索引进行搜索。
所以 - 单独的索引具有以下优点：1. 易于擦除用户数据，2. 很少担心查看不属于他们的文档 - 简化您的编码，3. 小（呃），每个用户的搜索速度更快。缺点可能是打开索引的初始启动和要处理的更多索引文件，这在我的书中并不是真正的大缺点。
另外两个需要注意的问题。采用 index-per-user 路线，您会增加磁盘使用量，因为每个用户都会复制一些数据。采用单一索引路径，用户的搜索评分可能会因属于不同用户的文档内容而产生偏差。例如，如果用户 A 经常在他的文档中使用一个稀有词，但用户 B 在他们的文档中只使用过一次，那么如果索引只包含他们的文档，那么用户 B 的得分就不会那么高。
关于 Solr stackoverflow.com/questions/8592153/…987654321@的类似问题

【解决方案1】：

在 Elastic Search 中，我认为根据您的信息，我会使用 1 个索引。我的理解是用户只是在那里搜索自己的文档，并且这些文档似乎比较相似。

性能 - 搜索时，您可以使用Filtered Query 过滤到仅匹配用户的文档。用户 ID 过滤器可以缓存，而且速度很快。

可扩展 - 在 Elasticsearch 中，您可以在索引级别控制分片和复制。 Elasticsearch 可以处理大量索引，我只是认为配置适当的分片和复制可能对整个索引很有价值。

在单个索引中，您仍然可以轻松擦除数据（请参阅delete by query），并且除非您将查询写错，否则应该很少担心看到其他数据。过滤后的查询将结果过滤到仅与用户 ID 关联的结果非常简单。复杂性类似于为每个用户搜索不同的索引。

您的确切需求可能更适合不同的方法。根据我目前的情况，我会选择一个索引。

【讨论】：