Lucene 索引：由帐户共享还是隔离？答案

【问题标题】：Lucene indexing: shared or isolated by account?Lucene 索引：由帐户共享还是隔离？
【发布时间】：2011-04-25 21:21:51
【问题描述】：

我正在评估 Lucene 以在 SaaS 应用程序中实现全局搜索功能。

我们不希望用户看到其他帐户的内容，因此搜索将始终受到帐户的限制。

最好是有一个带有帐户 ID 字段的单个索引还是每个帐户一个索引？每种方法的优缺点是什么？

我担心全局索引可能会由于频繁更新而影响性能。

谢谢。

编辑

【问题讨论】：

您的问题过于宽泛/复杂；答案很大程度上取决于您的应用程序及其架构的其他方面。查询索引的运行环境是什么？可索引数据是否经常在多个帐户之间共享？数据是否经常更新？多常？典型账户的索引数据增长率是多少？以此类推。

【解决方案1】：

除了常见的问题（例如索引更新等）之外，我还会考虑以下一些事情：

lucene 返回排名结果的方式取决于一些“语料库范围”的统计信息，例如，某个词出现在该字段中的文档总数。因此，如果客户 a 的索引统计数据不适合客户 b，除了会带来安全风险之外，它还会损害两个客户的相关性……如果 oscar 足够聪明，他真的可以开始反转 bob 的文档，因为倒排索引：http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.159.9682 您可能可以使用以下排名算法解决此问题：https://issues.apache.org/jira/browse/LUCENE-2864
lucene 中的其他一些内容适用于“作为一个整体”或“作为一个整体的索引”，您应该知道，如果您将索引组合在一起，它们不能真正针对每个客户进行更改：例如omitTF（如果您将其设置在单个文档中的某个字段，则该字段将全部省略），相似性（在任何已发布的 lucene 版本中，您只能全面设置相似性，因此客户将无法调整排名模型），拼写检查（你必须修改一些东西，每个客户都有自己的“过滤”拼写检查索引），...
另一方面，如果您有许多术语，则需要相当多的 RAM，并且通过为每个客户提供自己的索引，您将需要更多的内存来在 RAM 中保存所有索引的术语索引。但是，您可以通过调整诸如 termIndexInterval/Divisor 之类的东西来稍微降低它。

【讨论】：

【解决方案2】：

如果是我，如果没有监管原因您不能这样做，我会将它们全部转储到一个索引中。这简直就是我的“不要优化你不需要的东西”的帽子。

第一个问题是合法的：您是否允许共同托管和混合数据，即使它是通过逻辑方式分开的。这取决于您的律师、客户和服务协议。这不是技术问题。

假设您可以，那么下一个问题是其他用户之间会产生什么影响。如果用户 A 正在使用系统，而用户 B 正在导入他们的 100K 文档，那会影响用户 A 吗？是因为 Lucene 的工作方式而影响用户 A，还是仅仅因为导入和索引文档时发生的整体系统负载。

试试看吧。

关键是要确保您的客户端系统不直接访问 Lucene，而是通过某种外观。这个门面是强制执行客户端隔离的理想场所，也是重定向流量的好地方，如果以后您决定需要对索引进行分片。

也许您需要淘汰一个重度用户。或者，您将更高级别的响应时间出售给在他们的 SLA 中保证有更多资源的人，等等。

但是，现在决定更好的路径是什么？呃，好像早了。

500K 文档对于 Lucene 来说并不是很多数据。如果您发现在单个实例中托管所有功能不可行，请确保您在实施中具有灵活性，以便稍后添加功能。我所说的“添加能力”就是这个意思，添加它。不要实际实施，例如，基于客户端的分片。而是有一个很好的点，它可以在以后不重做一堆管道的情况下实施。

【讨论】：

【解决方案3】：

我在这里和那里做了一些“安全修剪”索引——如果允许的话，绝对有可能。也就是说，我对具有多个客户端的 SAAS 类型的东西的一般倾向是尽可能地将客户端分开，原因如下：

a) 确保编码错误不会导致数据泄露、客户愤怒、诉讼和其他麻烦。
b) 使每个客户端的定制变得更加容易——您的整个代码库不需要处理特定于客户端的 fubar 请求
c) 从一开始就强制您进入水平可扩展架构——如果添加实例很容易，那么扩展也很容易，对吧？

哦，一定要听听 Will Hartung 的建议——外观搜索，那东西真的不应该从它的层中爬出来。

【讨论】：