标签：source 推荐 也有 elastic res apach 缓存 alt 水平
转载：http://www.infoq.com/cn/articles/anatomy-of-an-elasticsearch-cluster-part03
虽然Elasticsearch中的变更不能立即可见，它还是提供了一个近实时的搜索引擎。如前一篇中所述，提交Lucene的变更到磁盘是一个代价昂贵的操作。为了避免在文档对查询依然有效的时候，提交变更到磁盘，Elasticsearch在内存缓冲和磁盘之间提供了一个文件系统缓存。内存缓存(默认情况下)每1秒刷新一次，在文件系统缓存中使用倒排索引创建一个新的段。这个段是开放的并对搜索有效。
文件系统缓存可以拥有文件句柄，文件可以是开放的、可读的或者是关闭的，但是它存在于内存之中。因为刷新间隔默认是1秒，变更不能立即可见，所以说是近实时的。因为translog是尚未落盘的变更持久化记录，它能有助于CRUD操作方面的近实时性。对于每次请求来说，在查找相关段之前，任何最近的变更都能从translog搜索到，因此客户端可以访问到所有的近实时变更。
你可以在创建/更新/删除操作后显式地刷新索引，使变更立即可见，但我并不推荐你这样做，因为这样会创建出来非常多的小segment而影响搜索性能。对于每次搜索请求来说，给定Elasticsearch索引分片中的全部Lucene段都会被搜索到，但是，对于Elasticsearch来说，获取全部匹配的文档或者很深结果页的文档是有害的。让我们来一起看看为什么是这样。
当我们的一次搜索请求在Elasticsearch中匹配了很多的文档，默认情况下，返回的第一页只包含前10条结果。search API提供了from和size参数，用于指定对于匹配搜索的全部文档，要返回多深的结果。举例来说，如果我们想看到匹配搜索的文档中，排名为50到60之间的文档，可以设置from=50，size=10。当每个分片接收到这个搜索请求后，各自会创建一个容量为from+size的优先队列来存储该分片上的搜索结果，然后将结果返回给协调节点。
如果我们想看到排名为50,000到50,010的结果，那么每个分片要创建一个容量为50,010的优先队列来存储结果，而协调节点要在内存中对数量为shards * 50,010的结果进行排序。这个级别的分页有可能得到结果，也有可以无法实现，这取决于我们的硬件资源，但是这足以说明，我们得非常小心地使用深分页，因为这非常容易使我们的集群崩溃。
一种获取全部匹配结果文档的可行性方案是使用scroll API，它的角色更像关系数据库中的游标。使用scroll API无法进行排序，每个分片只要有匹配搜索的文档，就会持续发送结果给协调节点。
获取大量文档的时候，对结果进行得分排序会非常昂贵。并且由于Elasticsearch是分布式系统，为每个文档计算搜索相关性得分是非常昂贵的。现在，让我们一起看看计算搜索相关性的诸多权衡中的一种。
Elasticsearch使用tf-idf来计算搜索相关性。由于其分布式的性质，计算全局的idf(inverse document frequency，逆文档频率)非常昂贵。反之可以这样，每个分片计算本地的idf并将相关性得分分配给结果文档，返回的结果只关乎该分片上的文档。同样地，所有分片使用本地idf计算的相关性得分，返回结果文档，协调节点对所有结果排序并返回前几条。这样做在大多数情况下是没有问题的，除非索引的关键字词项有倾斜或者单个分片上没有代表全局的足够数据。
比如说，如果我们搜索“insight”这个词，但包含"insight"这个词项的大多数文档都存放在一个分片上，这样以来匹配查询的文档将不能公平地在每个分片上进行排序，因为每个分片上的本地idf的值非常不同，得到的搜索结果可能不会非常相关。同样地，如果没有足够的数据，那么对于某些搜索而言，本地idf的值可能大有不同，结果也会不如预期相关。在有足够数据的真实场景中，本地idf值一般会趋于均等，搜索结果是相关的，因为文档得到了公平的得分。
这里有2种应对本地idf得分的办法，但都不建议真正在生产环境中使用。
在本系列的过去几篇中，我们回顾了一些Elasticsearch的基本原则，对于我们理解并上手Elasticsearch，这些内容非常重要。在接下来的一篇中，我将使用Apache Spark来研究Elasticsearch中的索引数据。
剖析Elasticsearch集群系列之三：近实时搜索、深层分页问题和搜索相关性权衡之道
标签：source 推荐 也有 elastic res apach 缓存 alt 水平
原文地址：http://www.cnblogs.com/haoxinyue/p/6506892.html
