SOLR 中的“文档”和“核心”是什么意思？我该如何使用它们？

Question

基于关系数据库的类比，我想知道 Solr 是如何适应的。 根据我到目前为止的想法，Solr 中的“文档”类似于 sql 中的“行”（如果我的 sql 表有 100 行，我需要在 solr 中插入 100 个文档）并且“核心”类似于“表”（或数据库？！？）。

问题是： 如果我有 2 组不相关的信息，假设一个包含汽车信息（id、名称、系列、颜色、描述）的表和一个包含用户信息（id、名称、地址、年龄、性别）的表，我在哪里插入这些Solr 中的东西？ 我制作了 2 个核心（core_car、core_user）并用对应表中的文档填充每个核心？ 或者我制作 1 个核心 (core_general) 并在其中插入两个表中的所有文档（以某种我不知道如何分隔的方式）。

在第一个有 2 个内核的情况下，我感觉我正在创建 2 个数据库，每个数据库都有 1 个表（矫枉过正）。 在第二个中，我感觉我正在创建一个表，其中所有不相关的字段都混合在一起（如果有某种形式的分离就不会出现这种情况——我目前还不知道）。

请确认与否我的假设。 提前谢谢你。

Answer 1

您在发布问题之前进行了探索。这是我的意见。

Solr 文档：可能更适合理解这个概念的方式是从结果的角度思考。每个 Solr 文档只是执行搜索查询后结果集中的一个结果条目。

如果您要为 Wikipedia 编制索引，则每篇文章都是 Solr 文档。当您搜索“排序算法”时，您希望看到的结果是“冒泡排序”、“归并排序”等。它们中的每一个都是一篇文章、一个 Solr 文档和结果集中的一个结果。

如果您希望将此与 rdbms 概念联系起来，我想说每个搜索结果（即 Solr 文档）都可以是 sql 查询结果集中的一行。该行可以是单个表中的一行，也可以是 JOINed 表中的一行。

Solr Core 只不过是 ONE lucene Index 的封装。每个 Solr 网络应用程序都可以运行多个 Solr 核心。

加快理解速度的最佳方法是避免将 Solr 中的概念与 RDBMS 相关联。

探索What Solr offers that RDMBS doesn't（高效）

这是另一个可能对您有所帮助的链接：Solr Terminology

您的用例

Solr/Lucene 的美妙之处在于灵活的架构，或者我会说没有架构。每个文档可以具有与索引的前一个文档完全不同的字段和属性。

在同一个 lucene 索引（在您的情况下为 Solr Core）中拥有不同类型的文档（汽车、人等）是完全可以的，只要它们完全可扩展。

例如，如果您有 500M 的汽车条目和 30 亿人的条目，那么将它们分开索引是有意义的。如果您有 100 万个人和 50 万辆汽车，您可以将它们全部填充到同一个索引中，并使用包含实体类型的标识符字段。

您的问题非常主观。不是每个人都会同意我说的。决定一个核心还是多个核心取决于更多的因素。

例如，

1. 这两个实体（人和汽车）是否相互补充以充当逻辑块以支持产品功能？
2. 在任何情况下，您都必须获得两种类型的查询结果。
3. 更新每种实体类型的频率。 （Solr 中没有更新选项。只有删除和重新添加。）
4. 它们是否属于不同的产品功能？
5. 它们是否属于不同的团队，等等。