5

鉴于：

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

可能相关信息：

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

例如：

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

他们为每个客户端使用一个索引并将其存储在客户端的数据库中。我不确定细节。而且我不确定这是否是对 Lucene 的严重修改。

问题：

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

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

可能的解决方案：

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

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

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

  • 临：不确定。也许对技术支持或计费部门搜索所有数据库信息有好处。
  • 缺点：搜索速度较慢（比 index-per-client 方法）。如果查询过滤器被删除，安全性有缺陷。

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

4

3 回答 3

6

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

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

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

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

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

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

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

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

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

于 2010-05-25T02:32:16.413 回答
4

Shalin Shekhar Mangar在Solr 用户邮件列表和私人电子邮件中回复了我。Shalin 是 Solr 的贡献者，也是即将出版的Solr in Action一书的作者。

他在邮件列表中的回复：

您将如何设置索引？

我会考虑为每个客户端设置多个核心。根据搜索流量，您可能还需要设置从站。

您将索引存储在哪里？

在一个盒子上设置 5K 内核是行不通的。因此，您需要将客户端划分为多个盒子，每个盒子都有一个核心子集。

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

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

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

每个客户端都有不同的内核，这很容易。

他通过电子邮件回复：

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

于 2010-04-25T18:35:53.997 回答
3

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

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

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

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

高温高压

于 2010-04-25T04:27:10.150 回答