Given:
- 每个客户（商业客户）1 个数据库
- 5000 名客户
- 客户端拥有 2 到 2000 个用户（平均约为 100 个用户/客户端）
- 每个数据库有 10 万到 1000 万条记录
- 用户需要经常搜索这些记录（这是导航数据的最佳方式）
可能相关的信息：
- 每周几个新客户（工作时间内的任何时间）
- 多个Web服务器和数据库服务器（用户可以通过任何Web服务器登录）
- 让我们保持对语言或 sql 品牌的不可知性，因为 Lucene（和 Solr）拥有广泛的支持
例如：
乔尔·斯波尔斯基在《播客 #11 https://blog.stackoverflow.com/2008/06/podcast-11/他的托管 Web 应用程序产品 FogBugz On-Demand 使用 Lucene。他拥有数千名按需客户。每个客户都有自己的数据库。
他们使用一个每个客户端的索引并将其存储在客户端的数据库中 http://fogbugz.stackexchange.com/questions/1866/where-is-the-fogbugz-search-index-stored/1878#1878。我不确定细节。我不确定这是否是 Lucene 的一个严肃的 mod。
问题：
您将如何设置 Lucene 搜索，以便每个客户端只能在其数据库内进行搜索？
您将如何设置索引？
您将索引存储在哪里？
您需要为所有搜索查询添加过滤器吗？
如果客户取消，您将如何删除他们的（部分）索引？ （这可能是微不足道的——还不确定）
可能的解决方案：
为每个客户端（数据库）建立一个索引
- 优点：搜索速度更快（比单一索引方法）。索引与客户端数据的大小相关。
- 缺点：我不确定这意味着什么，也不知道这是否超出了 Lucene 的范围。
有一个带有database_name字段的巨大索引。始终包含database_name作为过滤器。
- 专业人士：不确定。也许有利于技术支持或计费部门搜索所有数据库以获取信息。
- 缺点：搜索速度较慢（比按客户端索引方法）。如果删除查询过滤器，则安全性存在缺陷。
最后一件事：
我也会接受使用的答案Solr http://lucene.apache.org/solr/（Lucene 的扩展）。也许它更适合这个问题。没有把握。
你从 FogBugz StackExchange 召唤了我。我叫 Jude，是 FogBugz 的现任搜索架构师。
以下是 FogBugz On Demand 搜索架构的设置方式的粗略概述[1]：
- 出于与数据可移植性、安全性等相关的原因，我们将所有按需数据库和索引分开。
- 虽然我们确实使用 Lucene（实际上是 Lucene.NET），但我们对其后端进行了相当大的修改，以便它可以将其索引完全存储在数据库中。此外，每个网络主机上都会维护一个本地缓存，以便尽可能避免不必要的数据库访问。
- 我们的过滤器几乎完全是数据库端的（因为它们由 FogBugz 搜索之外的各个方面使用），因此我们的搜索解析器将查询分为全文和非全文组件，执行查找并组合结果。这有点不幸，因为它使 Lucene 能够进行的许多有用的优化无效。
我们所做的事情有一些好处。管理帐户非常简单，因为客户数据及其索引存储在同一位置。不过，也存在一些负面影响，例如一组非常令人讨厌的边缘情况搜索，其性能低于我们的最低标准。回想起来，我们的搜索在当时很酷而且做得很好。然而，如果我再做一次，我会不鼓励这种做法.
简而言之，除非您的搜索领域非常特殊或者您愿意专门聘请开发人员进行极快的搜索，否则 ElasticSearch、Solr 或 Xapian 等优秀产品的性能可能会超过您。
如果我今天这样做，除非我的搜索域非常具体，否则我可能会使用ElasticSearch、Solr 或 Xapian对于我的数据库支持的全文搜索解决方案。至于哪一个，这取决于您的辅助需求（平台、查询类型、可扩展性、对一组怪癖相对于另一组怪癖的容忍度等）
关于一个大索引与许多（！）分散索引的主题：两者都可以工作。我认为这个决定实际上取决于您想要构建什么样的架构以及您需要什么样的性能。如果您认为 2 秒的搜索响应是合理的，那么您可以非常灵活，但是一旦您开始说超过 200 毫秒的任何内容都是不可接受的，您的选择很快就会开始消失。为所有客户维护一个大型搜索索引可能会带来更多好处高效的比处理大量小索引，它不一定更快（正如您所指出的）。我个人认为，在安全的环境中，保持客户数据分离的好处不容低估。当您的索引损坏时，它不会使所有搜索停止；而是会导致所有搜索停止。愚蠢的小错误不会暴露敏感数据；用户帐户保持模块化——更容易提取一组帐户并将它们放到新服务器上； ETC。
我不确定这是否回答了您的问题，但我希望我至少满足了您的好奇心:-)
[1]：2013 年，FogBugz 开始使用 ElasticSearch 增强其搜索和过滤功能。我们喜欢它。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
