为什么应该（或不应该）搜索查询只返回文档 ID？

Question

因此，对于一个新项目，我正在为电子商务网站构建一个系统。我们的想法是从供应商那里进口产品，而不是将它们直接插入我们的目录，我们会将所有信息存储在一个暂存区。每个供应商都有自己的阶段（即数据库中的表），然后我会将多个暂存区域扁平化为单个实体（当前为单个表，但稍后可能会进入 Sphinx 或 Solr）。然后，我们的经销商将能够搜索暂存产品的相关字段（名称和描述）并显示匹配的产品列表，然后选择将这些产品推送到实时目录中。搜索将查询单个表（展平的暂存区）。

我的设计要求仅将可搜索和可过滤的字段存储在单个扁平表中 - 例如name、description、supplier_id、supplier_prod_id 等。搜索查询将仅返回匹配项目的 ID 和用于识别产品来自哪个暂存区域的类 (supplier_id)。

另一位高级工程师认为扁平化搜索表应该包括其他元字段（不会被搜索），但可以在将产品从舞台“推送”到实时目录时使用。他还认为查询应该返回所有这些其他信息。

我对在展平表中仅具有可搜索字段并让搜索仅返回可用于获取有关产品的所有其他必要元数据的类/id 对的感觉非常强烈（简单的 select * from class_table where id in ( 1,2,3))。

我的部分理由是，这将使以后更容易将扁平表从数据库切换到像 sphinx 或 solr 这样的搜索服务器，并且不必仅仅因为搜索的实现而更改其余代码改变了。

我在正确的道路上吗？我如何才能说服其他工程师为什么只保留可搜索字段并只返回 ID 很重要？或者更具体地说，为什么搜索应用程序应该只返回对象的 ID？

Answer 1

我认为你走在正确的道路上。如果这些其他字段没有提供任何值来唯一标识暂存项目或允许用户过滤暂存项目，那么数据基本上是无用的直到项目被推送到实时环境。如果其他工程师认为额外的元数据将帮助用户做出更明智的决定，那么您不妨让这些额外的字段可搜索（从而满足您对表格的陈述目的。）

我能想到预取其他不可搜索数据的唯一原因是为了提高推送到实时环境的性能。

Answer 2

在 sphinx 的情况下，无论如何它只会返回文档 ID 和命名属性（属性大部分是数字数据）。我会说您的想法是正确的，因为如果您需要，其他元数据只是一个简单的JOIN 远离扁平表。

Answer 3

您应该将每个工具用于其最擅长的方面。全文搜索引擎，如 Solr 或 Sphinx，擅长搜索文本字段并快速对命中进行排名。它在以类似选择的方式检索存储的数据方面没有特别的优势。数据库为此进行了优化。所以，是的，你走在正确的道路上。请参阅Search Engine versus DBMS，了解决定在搜索引擎中存储什么内容所涉及的其他问题。

Answer 4

您可以将 Solr 视为一个强大的索引，因此当索引返回 ID 时，solr 也这样做是合乎逻辑的。

您可以使用 solr 查询参数 fl 来请求仅标识符的结果，例如 fl=id。

但是，还有一个功能需要 solr 来给您返回一些数据：在匹配的文档中突出显示搜索词。如果您不需要它，那么只使用 solr 来检索标识符就可以了（我假设您只需要文档列表，不需要其他功能，例如构面、相关文档或拼写检查）。

也就是说，在搜索功能中如何构建对象应该很重要，无论是从数据库中使用唯一的 solr 检索 ID，还是从 solr 返回的字段（假设它们已存储），甚至两者兼而有之。想想 solr 来获取“突出显示”的内容字段和其他内容的数据库。同样，如果您不需要突出显示，这不是问题。

Answer 5

我将 Solr 用于数千个文档，但仅返回 ID，原因如下：

对于 Solr： - 如果附加了一些同步错误，这没什么大不了的（特别是在你的情况下，显示不同的价格可能是一个大问题......就像项目不会在正确的位置，但数据是正确的） - 您将节省大量时间，因为当您不要求 Solr 返回文档的“描述”时（我的意思是多行文本）

对于您的数据库： - 你可以缓存你的结果，所以使用 ID 会更快（你不需要每次都来自 Solr 的所有数据！！！） - 你以同样的方式构建你的结果（当你想从 Solr 构建 html 时，你不需要特定的方法，而从你的 DB 中构建其他方法）

我觉得还有很多……