Lucene索引:由帐户共享还是孤立？

Question

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

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

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

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

谢谢。

编辑

500,0000

• Number accounts

• Account :4000个

• 可索引数据从未在accounts

• Account用户之间共享，可能每天更新索引数据几次(多数情况下不超过100个)，在初始设置过程

• 之后，索引数据量趋于稳定，在初始设置过程

• 之后，需要存储每个文档

F 215的10-20个字段

Answer 1

除了常见的问题(例如索引更新等)之外，我还会考虑以下几点：

1. -- lucene返回排序结果的方式--取决于一些“语料库范围”的统计数据，例如，一个术语在该字段中出现的文档总数。因此，如果客户a的指数统计数据不适合客户b，那么这将损害两个客户的相关性，而且是一个安全风险。如果奥斯卡够聪明的话，他真的可以开始倒置鲍勃的文档，因为倒排索引的本质是：http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.159.9682，你也许可以用这样的排序算法来解决这个问题: lucene中的https://issues.apache.org/jira/browse/LUCENE-2864
2. ，其他一些东西都适用于“整体字段”或“整体索引”，而且您应该知道，如果将索引组合在一起，就不可能在每个客户的基础上进行真正的更改:比如omitTF (如果您将其设置在一个字段的单个文档上，该字段省略了该字段)、相似性(在lucene的任何发布版本中)，您只能全面设置相似度，这样客户就无法调优排名模型)，拼写检查(您必须破解一些东西，其中每个客户都有自己的“过滤”拼写索引)，
3. ，另一方面，如果您有很多术语，则需要相当多的内存，通过为每个客户提供自己的索引，您将需要更多的内存来保存所有索引的术语索引。但是，您可以通过调整诸如termIndexInterval/Divisor.

之类的东西来稍微降低这一点。

Answer 2

如果是我，如果没有监管理由你不能，我会把它们全部倒入一个单一的指数。这只是我说的“不要优化你不需要的东西”。

首先要考虑的是简单的法律问题:即使数据是通过逻辑方式分离的，您甚至允许联合托管和混合数据吗？这取决于你的律师、客户和服务协议。这不是一个技术上的问题。

假设你可以，那么下一个问题是其他用户会对彼此产生什么样的影响。如果用户A正在使用系统，而用户B正在导入他们的100 K文档，这会影响用户A吗？它是因为Lucene的工作方式影响了用户A，还是仅仅因为导入和索引文档时出现的总体系统负载。

试试看。

关键是确保客户端系统不直接访问Lucene，而是通过某种外观访问Lucene。这个外观是执行客户端隔离的完美场所，如果稍后您决定需要分割索引，那么它也是重定向通信量的好地方。

也许您需要删除一个单一的重用户。或者，您可以将更高级别的响应时间出售给那些在SLA中获得更多资源的人，等等。

但现在决定，更好的道路是什么？呃，看上去还早。

对于Lucene来说，500 K文档不是很多数据。如果您发现在单个实例中托管所有这些都是不可行的，那么只需确保您在以后的实现中具有添加功能的灵活性。而我所说的“添加功能”，我的意思就是，添加它。不要实际实现，比如说，基于客户端的切分。但是应该有一个很好的点，这样可以实现它，而不需要以后再重做一堆管道。

Answer 3

我在这里和那里做了一些“安全修剪”索引--如果允许的话，绝对是可能的。尽管如此，我对于SAAS类型的多个客户端的总体倾向是尽可能地将客户分开，原因如下：

( a)确保编码错误不会导致数据泄漏、愤怒的客户、诉讼等。

( b)使每个客户定制更容易-您的整个代码库不必处理特定于客户的fubar请求。

( c)从一开始就强制您进入水平可伸缩的体系结构--如果添加实例很容易，那么扩展是很容易的，对吗？

哦，而且肯定采纳了威尔·哈通的建议--正面搜索，那些东西真的不应该从它的层里爬出来。