Solr 的 /sql 请求处理程序如何在集合不保存任何数据的情况下工作？
How does Solr's /sql request handler work without the collection holding any data?
我正在查看 parallel SQL interface. In the best practices 部分的 Solr 文档，我看到以下内容：
It makes sense to create a separate SolrCloud collection just for the
/sql handler. This collection can be created using SolrCloud’s
standard collection API. Since this collection only exists to handle
/sql requests and provide a pool of worker nodes, this collection does
not need to hold any data.
我不明白有一个单独的集合有什么用，而且在没有数据的情况下也会有帮助。我会想象拥有数据所在的集合并在该集合中配置 /sql 处理程序是可行的方法，因为 Solr 框本身就是工作节点池。有一个新的集合只是为了处理 /sql 请求在这里究竟有什么帮助？在没有数据的情况下它如何运作？有人可以解释一下吗？
它允许您增加可用的工作人员数量，而不必将数据复制到更多节点，而不会在 SQL 界面中获得任何关于性能的信息。这允许您引入纯工作节点，并扩展您对 SQL 处理的要求，而无需为所有涉及的集合扩展数据。
SQL 接口在 所有集合 中通用，因为集合在 SQL 查询中由 table 名称表示。然后，工作人员在后台联系收集的每个分片的其中一个副本，合并结果并将其返回。由于这独立于集合本身，因此无需使用附加到特定集合的工作人员。
手册中显示的数据 Table 插图（比您引用的引文更靠下）显示了其工作原理：
我正在查看 parallel SQL interface. In the best practices 部分的 Solr 文档，我看到以下内容：
It makes sense to create a separate SolrCloud collection just for the /sql handler. This collection can be created using SolrCloud’s standard collection API. Since this collection only exists to handle /sql requests and provide a pool of worker nodes, this collection does not need to hold any data.
我不明白有一个单独的集合有什么用，而且在没有数据的情况下也会有帮助。我会想象拥有数据所在的集合并在该集合中配置 /sql 处理程序是可行的方法，因为 Solr 框本身就是工作节点池。有一个新的集合只是为了处理 /sql 请求在这里究竟有什么帮助？在没有数据的情况下它如何运作？有人可以解释一下吗？
它允许您增加可用的工作人员数量，而不必将数据复制到更多节点，而不会在 SQL 界面中获得任何关于性能的信息。这允许您引入纯工作节点，并扩展您对 SQL 处理的要求，而无需为所有涉及的集合扩展数据。
SQL 接口在 所有集合 中通用，因为集合在 SQL 查询中由 table 名称表示。然后，工作人员在后台联系收集的每个分片的其中一个副本，合并结果并将其返回。由于这独立于集合本身，因此无需使用附加到特定集合的工作人员。
手册中显示的数据 Table 插图（比您引用的引文更靠下）显示了其工作原理：