如何为 B2B 网络应用程序设置 Lucene/Solr？

Question

鉴于：

• 每个客户（企业客户）1 个数据库
• 5000 个客户
• 客户有 2 到 2000 个用户（平均约为 100 个用户/客户）
• 每个数据库 100k 到 1000 万条记录
• 用户需要经常搜索这些记录（这是导航数据的最佳方式）

可能的相关信息：

• 每周有几个新客户（工作时间内的任何时间）
• 多个网络服务器和数据库服务器（用户可以通过任何网络服务器登录）
• 让我们对语言或 sql 品牌保持不可知论，因为 Lucene（和 Solr）拥有广泛的支持

例如：

Joel Spolsky 在Podcast #11 中表示，他的托管网络应用产品 FogBugz On-Demand 使用了 Lucene。他有成千上万的按需客户。每个客户都有自己的数据库。

他们使用index per client and store it in the client's database。我不确定细节。而且我不确定这是否是对 Lucene 的严重修改。

问题：

您将如何设置 Lucene 搜索，以便每个客户端只能在其数据库中搜索？

您将如何设置索引？
您将索引存储在哪里？
您是否需要为所有搜索查询添加过滤器？
如果客户取消，您将如何删除他们的（部分）索引？ （这可能是微不足道的——还不确定）

可能的解决方案：

为每个客户端（数据库）建立索引

• 专业版：搜索速度更快（比单一索引方法）。索引与客户数据的大小有关。
• 缺点：我不确定这意味着什么，也不知道这是否超出了 Lucene 的范围。

拥有一个带有 database_name 字段的单个巨大索引。始终包含 database_name 作为过滤器。

• 专业人士：不确定。也许对技术支持或计费部门搜索所有数据库信息有好处。
• Con：搜索速度较慢（比每个客户端的索引方法）。如果删除查询过滤器，则会出现安全漏洞。

最后一件事：
我也会接受使用Solr（Lucene 的扩展）的答案。也许它更适合这个问题。不确定。

Answer 1

我仍然不清楚用户正在从 5K 数据库中搜索什么，为什么需要 Lucene，以及每个数据库中的数据大小。但无论如何我都会受到打击：

1. 您应该查看 Multicore Solr（每个核心 = 1 个索引），并且您有一个唯一的 URL 可供查询。身份验证仍将是一个问题，解决此问题的一种（骇人听闻的）方法是让 URL 难以猜测。

2. 您的网络服务器可以根据他们有权访问的内容查询 Solr 实例/核心。

我建议远离过滤方法，并创建一个结合所有数据库的巨大索引。

HTH

Answer 2

Shalin Shekhar Mangar 通过Solr-user mailing list 和私人电子邮件回复了我。 Shalin 是 Solr 的贡献者，也是即将出版的一本书 Solr in Action 的作者。

他在邮件列表中的回复：

您将如何设置索引？

我会考虑为每个客户端设置多个内核。您可能需要设置 奴隶以及取决于搜索流量。

您将索引存储在哪里？

在一个机器上设置 5K 内核将不起作用。所以你需要分区 客户端分成多个盒子，每个盒子都有一个核心子集。

您是否需要为所有搜索查询添加过滤器？

不，但您需要将查询发送到正确的主机（可能是 映射数据库会有所帮助）

如果客户取消，您将如何删除他们的（部分）索引？ （这可能是微不足道的——还不确定）

为每个客户端使用不同的内核，这很容易。

他的电子邮件回复：

我过去曾研究过类似的用例，我们使用了多核方法，并在 Solr 方面进行了一些重大优化。请参阅http://wiki.apache.org/solr/LotsOfCores - 我还无法将这些更改推送到 Solr。

Answer 3

你从 FogBugz StackExchange 召唤了我。我的名字是裘德，我是 FogBugz 的当前搜索架构师。

以下是如何设置 FogBugz On Demand 搜索架构的粗略概述[1]：

• 出于与数据可移植性、安全性等相关的原因，我们将所有按需数据库和索引分开。
• 虽然我们确实使用了 Lucene（实际上是 Lucene.NET），但我们对其后端进行了相当大的修改，以便它可以将其索引完全存储在数据库中。此外，每个虚拟主机上都会维护一个本地缓存，以便尽可能避免不必要的数据库命中。
• 我们的过滤器几乎完全是数据库端的（因为它们被 FogBugz 搜索之外的各个方面使用），因此我们的搜索解析器将查询分为全文和非全文组件，执行查找，并组合结果。这有点令人遗憾，因为它使 Lucene 能够进行的许多有用的优化无效。

我们所做的有一些好处。管理帐户非常简单，因为客户数据及其索引存储在同一个地方。不过，也有一些负面因素，例如一组非常讨厌的边缘案例搜索，它们的性能低于我们的最低标准。回想起来，我们的搜索很酷，并且在当时做得很好。但是，如果我再次这样做，我会不鼓励这种方法。

简单地说，除非您的搜索域非常特殊，或者您愿意让开发人员致力于极速搜索，否则您可能会被 ElasticSearch、Solr 或 Xapian 等优秀产品所超越。

如果我今天这样做，除非我的搜索域非常具体，否则我可能会使用 ElasticSearch、Solr 或 Xapian 作为我的数据库支持的全文搜索解决方案。至于哪个，这取决于您的辅助需求（平台、查询类型、可扩展性、对一组怪癖的容忍度等）

关于一个大型索引与许多（！）分散索引的主题：两者都可以工作。我认为这个决定真的取决于你想要构建什么样的架构，以及你需要什么样的性能。如果您认为 2 秒的搜索响应是合理的，您可以非常灵活，但是一旦您开始说超过 200 毫秒的任何内容都是不可接受的，您的选择就会很快消失。虽然为所有客户维护一个大型搜索索引可能比处理大量小型索引要高效得多，但它不一定更快（正如您所指出的那样）。我个人认为，在一个安全的环境中，保持客户数据分离的好处不容小觑。当您的索引损坏时，它不会停止所有搜索；愚蠢的小错误不会暴露敏感数据；用户帐户保持模块化 - 提取一组帐户并将它们放到新服务器上更容易；等等

我不确定这是否回答了你的问题，但我希望我至少能满足你的好奇心 :-)

[1]：2013 年，FogBugz 开始使用 ElasticSearch 为其搜索和过滤功能提供支持。我们喜欢它。