Solr 云性能答案

【问题标题】：Solr Cloud performanceSolr 云性能
【发布时间】：2015-12-21 07:24:00
【问题描述】：

我正在尝试为我的一个项目评估 solr，我需要检查我的应用程序的 tps（每秒事务数）方面的可伸缩性。我已将 1 个 AWS 服务器上的 solr 配置为独立应用程序，它为我的查询提供了 ~8000 的搜索查询 tps。为了测试可扩展性，我在两台 AWS 服务器上对相同的数据进行了分片，每台服务器有 250 万条记录。当我尝试使用与之前相同的查询查询集群时，它给了我约 2500 的 tps。我的理解是集群中的 tps 应该增加，因为它们是两台不同的机器，它们将执行单独的 I/O 操作。我正在使用 solr 提供的查询 REST 端点。我没有配置任何单独的负载均衡器，因为 solr 文档说默认情况下 solr cloud 将以循环方式执行负载均衡。感谢任何帮助验证我的理解。

【问题讨论】：

如何查询集群？当您从一个节点转到两个节点时，您的查询必须从您正在查询的节点分发，从而产生更多的网络吞吐量。有趣的问题通常是当您引入节点 3、4、5 等时会发生什么，因为从 1 到 2 会引入处理分布式查询的所有复杂性。
我正在通过 solr 提供的 /select REST 端点查询集群。您认为网络延迟可能会在这种程度上降低性能吗？
但是您使用的是集群感知客户端吗？否则 Solr 将从您正在查询的服务器执行路由以查找包含文档的节点，因此它将在 Solr 端具有（额外的）网络开销。虽然以前可以通过请求 - 服务器 - 响应来处理请求，但现在它是请求 - 服务器 - 请求 - 服务器 - 响应 - 服务器 - 响应，并在适当的地方合并结果。
我可以使用集群感知客户端，这给了我很好的 tps。那么使用 solr 客户端是否需要知道分片中的数据，以便它可以直接查询特定分片？如果我总是必须查询集群以防我的客户端不知道集群，我该如何扩展？
我添加了一个解释作为实际答案，因为它需要更多空间:-)

标签： performance solr solrcloud

【解决方案1】：

与仅从您正在查询的服务器本地回答查询相比，您所看到的是 Solr 必须在您的集群中路由（并可能合并）请求的开销。

查询单个 Solr 服务器时，该服务器的所有数据都在本地磁盘上可用，因此您的查询可以在服务器内处理，而无需向任何其他服务器询问数据。在服务器上查询collection1会得到一个接近于：

client -> request -> server (disk) -> response -> client

当您将另一台服务器引入集群，但仍继续查询第一台服务器时，该服务器可能还必须向另一台服务器询问数据 - 除非您正在与之交谈的服务器（第一台）拥有所有您正在查询的集合中的文档。

假设collection2 的所有文档都位于第二台服务器上，但您仍在与第一台服务器通信：

client -> request  -> server1
          (doesn't have the documents, so it'll ask the node that has)
                      server1 -> request  -> server2
                      server1 <- response <- server2
client <- response <- server1

如您所见，请求现在依赖于 server1 和 server2 之间的全新请求，并且您的吞吐量随着检索复杂性的增加而下降。 API 还是一样的，但是 Solr 内部发生的事情在您的请求后面引入了另一层请求。

那么，为什么使用集群感知客户端（例如带有CloudSolrClient 的 SolrJ）会有所帮助？它首先从 ZooKeeper 检索集群配置，然后直接查询第二台服务器 - 因为它可以看到 collection2 位于 server2 上。

client -> request -> zookeeper -> response -> client   
client -> request -> server2 -> response -> client

当您一个接一个地进行许多查询时（就像您在应用程序中进行基准测试、索引或查询时所做的那样），只有第二行重复，因此下一个查询可以在不查询的情况下解决ZooKeeper 优先，除非发生错误：

client -> request -> server2 -> response -> client

这就是您在使用云感知客户端时再次看到高吞吐量的原因。

但还有另一种情况，即当集合不存在于仅一台服务器上时会发生这种情况，并且会再次影响您的吞吐量。 collection3 存在于 server2、server3 和 server4 上，并且在服务器之间分片（意味着每个服务器只有索引的一部分，例如每个服务器上 33.3..% 的文档）

client -> server1
          server1 -> server2    | parallel
                  <-            |
          server1 -> server3    | 
                  <-            |
          server1 -> server4    |
                  <-            |
              (merge responses from server2, server3 and server4
               and return the new, sorted response, cutting it at
               the number of rows to return)
client <- server1

云感知客户端可以跳过查询 server1 并直接询问 server2，保存一个请求（或者如果它真的想要，并行查询节点并合并响应，但我不认为目前有任何客户这样做）。

最后一个问题是，如果客户需要具备云感知能力，您如何进行扩展——其实不需要。它将节省往返，但您会看到数字发生了很大变化，因为在本地询问磁盘和必须通过网络查询之间存在巨大变化。如果您添加另一台服务器并仍然查询第一个 Solr 节点，吞吐量将保持不变 - 它不会进一步下降。获取您的收藏结果时，它只是查询server3 而不是server2。

希望能解释您所看到的数字！

【讨论】：