每个客户1个数据库(商业客户)
> 5000个客户
>客户有2到2000个用户(平均约100个用户/客户端)
>每个数据库100k到1000万条记录
>用户需要经常搜索这些记录(这是导航数据的最佳方式)
可能相关的信息：
>每周有几个新客户(工作时间的任何时间)
>多个Web服务器和数据库服务器(用户可以通过任何Web服务器登录)
>让我们对语言或sql品牌保持不可知,因为Lucene(和Solr)有广泛的支持
例如：
Joel Spolsky在Podcast #11年表示他的托管网络应用产品FogBugz On-Demand使用Lucene.他有成千上万的按需客户.每个客户都有自己的数据库.
他们使用index per client and store it in the client’s database.我不确定细节.而且我不确定这对Lucene来说是否是一个严肃的模式.
问题：
您将如何设置Lucene搜索,以便每个客户端只能在其数据库中进行搜索？
你会如何设置索引？
你在哪里存储索引？
您是否需要为所有搜索查询添加过滤器？
如果客户取消了,您将如何删除其(部分)索引？ (这可能是微不足道的 – 还不确定)
可能的解决方案：
为每个客户端(数据库)创建索引
> Pro：搜索速度更快(比一个索引所有方法).指数与客户数据的大小有关.
>骗局：我不确定这会带来什么,也不知道这是否超出了Lucene的范围.
拥有一个带有database_name字段的巨大索引.始终包含database_name作为过滤器.
>亲：不确定.也许有利于技术支持或计费部门搜索所有数据库的信息.
> Con：搜索速度较慢(比每个客户端的索引方法).删除查询过滤器时存在缺陷安全性.
最后一件事：
我也接受使用Solr(Lucene的扩展名)的答案.也许它更适合这个问题.不确定.
以下是FogBugz On Demand搜索架构如何设置的大致概述[1]：
>出于与数据可移植性,安全性等相关的原因,我们将所有的On Demand数据库和索引分开.
>虽然我们确实使用Lucene(实际上是Lucene.NET),但我们已经相当大地修改了它的后端,以便它可以将其索引完全存储在数据库中.此外,在每个webhost上维护本地缓存,以便尽可能避免不必要的数据库命中.
>我们的过滤器几乎完全是数据库端(因为它们被搜索之外的FogBugz使用),因此我们的搜索解析器将查询分为全文和非全文组件,执行查找,并结合结果.这有点不幸,因为它阻止了Lucene能够进行的许多有用的优化.
我们所做的一切都有好处.管理帐户非常简单,因为客户数据及其索引存储在同一个地方.然而,也存在一些负面因素,例如一组非常讨厌的边缘案例搜索,其表现不如我们的最低标准.回顾一下,我们的搜索很酷,并且做得很好.但是,如果我再次这样做,我会劝阻这种做法.
简单地说,除非您的搜索域非常特殊,或者您愿意将开发人员专门用于快速搜索,否则您可能会被ElasticSearch,Solr或Xapian等优秀产品所取代.
如果我今天这样做,除非我的搜索域非常具体,否则我可能会使用ElasticSearch,Solr或Xapian作为我的数据库支持的全文搜索解决方案.至于哪个,这取决于你的辅助需求(平台,查询类型,可扩展性,一组怪癖对另一组的容忍度等)
关于一个大索引与多个(！)分散索引的主题：两者都可以工作.我认为这个决定真的取决于你要构建什么样的架构,以及你需要什么样的性能.如果您认为2秒的搜索响应是合理的,那么您可以非常灵活,但是一旦您开始说超过200毫秒的任何内容都是不可接受的,您的选项就会很快消失.虽然为所有客户维护单个大型搜索索引比处理大量小索引要高效得多,但它并不一定快(正如您所指出的那样).我个人认为,在安全的环境中,保持客户数据分离的好处不容小觑.当你的索引被破坏时,它不会使所有搜索停止;愚蠢的小虫子不会暴露敏感数据;用户帐户保持模块化 – 提取一组帐户并将它们放到新服务器上更容易;等等
我不确定这是否回答了你的问题,但我希望我至少满足你的好奇心:-)
[1]：2013年,FogBugz开始使用ElasticSearch为其搜索和过滤功能提供支持.我们喜欢它.