Elasticsearch实现原理分析-3

介绍

在之前的一篇文章中，我们讨论了Elasticsearch如何处理分布式系统的一些基本问题。在这篇文章中，我们将会审查Elasticsearch的各个方面，例如接近实时的搜索和权衡，它考虑计算Insight Data Engineering Fellows在构建数据平台时利用的搜索相关性。
—–近实时搜索
—–为什么深度分页在分布式搜索可能是危险的？
—–计算搜索相关性的权衡

近实时的搜索

虽然在Elasticsearch中的更改不是立即可见，但它确实提供了一个接近实时的搜索引擎。如前一篇文章所述，将Lucene更改持久化到磁盘是一项非常耗性能的操作。为了避免在文档搜索可用时提交Lucene修改到磁盘，这里有一个位于内存缓冲区和磁盘之间的文件系统缓存。每秒刷新内存缓冲区（默认情况下），并在文件系统缓存中创建一个具有倒排索引的新段。此片段已打开并可用于搜索。
文件系统的缓存中，可能有文件句柄、被打开的文件，该文件可以被打开、读取和关闭，但它保存在内存中。然而，默认情况下刷新间隔为1秒，所以更改不能立即可见，因此它只是近实时的。这也有助于CRUD操作的近实时操作。
文件系统缓存可以具有文件句柄和文件可以被打开，读取和关闭，但是它存在于内存中。
由于默认情况下，刷新间隔为1秒，所以更改不可见，因此接近实时。由于translog会把没有写入磁盘的更改进行持久化。对于每个请求，在检查相关分段(relevant segments)之前，会对translog进行最近的更改进行搜索，因此客户端可以接近实时访问所有更改。
您可以在每次创建/更新/删除操作之后显式刷新索引(refresh the index)，以使更改立即生效，但不推荐这样做，因为该过程会创建很多小的分段(small segments)，从而影响搜索性能。
对于一个搜索请求，会搜索一个索引中给定分片的所有Lucene分段(Lucene segments)。然而，在结果页中获取所有匹配的文档或文档深度，对于你的Elasticsearch集群是危险的。
我们来看看为什么会这样：

为什么深度分页(deep pagination)在分布式搜索可能是危险的？

当你向Elasticsearch发送一个搜索请求，若有大量文档被匹配，默认情况下，只是返回top 10的结果。搜索API有from和size参数，用来确定搜索匹配到的所有结果文档的深度。
例如，如果要查看与搜索匹配的50到60行的文档，则设置from= 50和size = 10。
当每个分片接收到搜索请求时，它将创建一个from+size大小的优先队列，以满足搜索结果本身，然后将结果返回给协调节点。

若你想查看从50,000到50,010的搜索结果，那么每个分片将创建一个具有50,010个结果的优先队列，并且协调节点(coordinating node)必须对shards* 50,010个数目的结果在内存中进行排序。
分片的数目进行排序 shards* 50,010个结果存储在内存中。这种级别的分页是否能够完成，取决于你拥有的硬件资源。但是您需要非常小心深层分页，因为它可以轻易让你的集群崩溃。
可以通过 scroll API来获取所有的文档，该API的行为很像关系数据库中的游标。通过禁用排序的 scroll API，并且每个分片只要具有与搜索匹配的文档，就会继续发送结果。
若要获取大量的搜索到的文档，排序得分结果是非常耗性能的。Elasticsearch是分布式系统，计算搜索相关性分数代价是很高的。下面我们看一下计算搜索相关性的一些权衡：

计算搜索相关性的权衡
Elasticsearch使用tf-idf来计算搜索相关性(search relevance)，由于它的分布式特性，计算搜索全局的idf(inverse document frequency)的代价是很高的。替代的方式是，让每个分片计算本地分片的idf来分配一个相关性分数给结果文档，仅返回该分片上的文档。同样，所有的分片返回结果文档，这些文档带有由本地idf计算的相关性分数，协调节点把所有的结果排序，并返回top n的结果。
这在大多数情况下是正常的，除非您的索引在关键字方面有偏差，或者单个分片上没有足够的数据来表示全局分布。
例如，如果您正在搜索“insight”一词，并且包含术语“insight”的大多数文档都位于一个分片上，则与查询匹配的文档将不会在每个分片上公平排列为本地idf 的值会有很大的不同，搜索结果可能不太相关。

类似地，如果没有足够的数据，那么局部idf值可能会对某些搜索有很大的不同，并且结果可能不如预期那么相关。在具有足够数据的实际场景中，本地idf值趋向于均匀，并且搜索结果是相关的，因为文档得分相当。
有几种方法来获取本地的idf分数，但是并不推荐用于生产系统。

参考
Anatomy of an Elasticsearch Cluster: Part III
https://blog.insightdatascience.com/anatomy-of-an-elasticsearch-cluster-part-iii-8bb6ac84488d