给定:

  • 每个客户(业务客户)1个数据库
  • 5000个客户
  • 客户有2至2000个用户(AVG为〜100用户/客户端)
  • 每个数据库100k至1000万记录
  • 用户需要经常搜索这些记录(这是导航其数据的最佳方法)

可能相关信息:

  • 每周(工作时间的任何时间)每周几个新客户
  • 多个Web服务器和数据库服务器(用户可以通过任何Web服务器登录)
  • 让我们保持语言或SQL品牌的不可知论,因为Lucene(和Solr)有很多支持

例如:

乔尔·斯波尔斯基(Joel Spolsky)说 播客#11 他托管的Web应用程序产品Fogbugz On-Demand使用Lucene。他有成千上万的按需客户。每个客户都有自己的数据库。

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

问题:

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

您将如何设置索引?
您在哪里存储索引?
您需要在所有搜索查询中添加过滤器吗?
如果客户取消,您将如何删除其(一部分)索引? (这可能是微不足道的 - 还不可能肯定)

可能的解决方案:

为每个客户端(数据库)制作索引

  • PRO:搜索速度更快(比一分数的方法更快)。索引相对于客户数据的大小。
  • CON:我不确定这有什么需要,也不知道这是否超出了Lucene的范围。

具有带有数据库的单个巨大索引。始终将Database_name作为过滤器包含。

  • Pro:不确定。也许有益于技术支持或计费部门搜索所有数据库以获取信息。
  • con:搜索速度较慢(比每个客户级索引方法)。如果查询过滤器删除,则有缺陷的安全性。

最后一件事:
我也会接受一个使用的答案 索尔 (Lucene的扩展)。也许它更适合这个问题。没有把握。

有帮助吗?

解决方案

您从Fogbugz Stackexchange召唤我。我叫裘德(Jude),我是Fogbugz的当前搜索架构师。

这是Fogbugz按需搜索架构如何设置[1]的粗略概述:

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

我们所做的事情有一些好处。管理帐户非常简单,因为客户数据及其索引存储在同一位置。但是,也有一些负面因素,例如一组真正令人讨厌的案例搜索,这些案例表现不佳。回顾性地,我们的搜索很酷,并且在时间做得很好。但是,如果我要再做一次,我会 劝阻这种方法.

简而言之,除非您的搜索域非常特别,否则您愿意将开发人员奉献给快速的搜索,否则您可能会胜过Elasticsearch,Solr或Xapian等优秀产品。

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

关于一个大索引与许多(!)散射索引的主题:两者都可以工作。我认为这个决定确实在于您希望建立哪种架构以及您需要什么样的性能。如果您确定2秒的搜索响应是合理的,那么您可能会非常灵活,但是一旦您开始说任何超过200ms的东西是不可接受的,您的选择就会开始很快消失。在为所有客户保留一个大型搜索指数的同时,可能会更多 高效的 除了处理许多小索引,它不一定更快(如您指出的那样)。我个人认为,在安全的环境中,保持客户数据分离的好处不会被低估。当您的索引损坏时,它不会使所有搜索停止;愚蠢的小错误不会暴露敏感数据;用户帐户保持模块化 - 更容易提取一组帐户并将其插入新服务器;等等

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

1]:2013年,Fogbugz开始使用Elasticsearch为其搜索和过滤功能提供动力。我们喜欢它。

其他提示

Shalin Shekhar Mangarsolr-user邮寄列表 并通过私人电子邮件。 Shalin是Solr的撰稿人,也是即将出版的书的作者 Solr在行动中.

他在邮件列表上的答复:

您将如何设置索引?

我会考虑为每个客户设置多个内核。您可能需要根据搜索流量来设置奴隶。

您在哪里存储索引?

在一个盒子上设置5K内核将不起作用。因此,您将需要将客户端分为多个具有一部分核心的框。

您需要在所有搜索查询中添加过滤器吗?

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

如果客户取消,您将如何删除其(一部分)索引? (这可能是微不足道的 - 还不可能肯定)

对于每个客户的不同核心,这将非常简单。

他通过电子邮件回复:

过去,我从事类似的用例工作,我们使用了多核方法,并在Solr侧进行了一些重型优化。看 http://wiki.apache.org/solr/lotsofcores - 我还无法将这些更改推入SOLR。

我仍然不清楚5K数据库用户正在搜索的确切内容,为什么需要Lucene以及每个数据库中的数据大小。但是无论如何我都会打扰:

  1. 您应该查看Multicore Solr(每个核心= 1索引),并且要查询独特的URL。身份验证仍然是一个问题,而一种(hackish)的方法是使URL难以猜测。

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

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

Hth

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top