了解Elasticsearch中的细分

Abh*_*ogi 41 lucene elasticsearch

我假设Elasticsearch中的每个分片都是索引.但我在某处读到每个段都是Lucene索引.

什么是细分市场?它如何影响搜索性能?我的索引每天大小达到450GB(我每天都会创建一个新的),默认的Elasticsearch设置.

当我执行curl -XPOST "http://localhost:9200/logstash-2013.03.0$i_optimize?max_num_segments=1",我得到 num_committed_segments=11num_search_segments=11.

上述值不应该是1吗?也许这是因为index.merge.policy.segments_per_tier价值?这层是什么?

DrT*_*ech 151

"索引"这个词在Elasticsearch中被滥用了一些 - 适用于太多的东西.

解释:

指数

Elasticsearch中的"索引"有点像关系数据库中的数据库.它是存储/索引数据的地方.但实际上,这正是您的应用程序所看到的.在内部,索引是指向一个或多个分片的逻辑命名空间.

此外,"索引"表示将您的数据"放入"Elasticsearch.您的数据既可以存储(用于检索),也可以"索引"用于搜索.

倒指数

"倒排索引"是Lucene用于使数据可搜索的数据结构.它处理数据,提取唯一的术语或令牌,然后记录哪些文档包含这些令牌.有关更多信息,请参见http://en.wikipedia.org/wiki/Inverted_index.

碎片

"碎片"是Lucene的一个实例.它本身就是一个功能齐全的搜索引擎."索引"可以由单个分片组成,但通常由多个分片组成,以允许索引增长并在多个机器上分割.

"主要分片"是文档的主要主页."副本分片"是主分片的副本,它提供(1)主节点故障时的故障转移和(2)增加的读取吞吐量

分割

每个分片包含多个"分段",其中分段是反向索引.在分片中搜索将依次搜索每个片段,然后将其结果合并到该分片的最终结果中.

在索引文档时,Elasticsearch会将它们收集在内存中(并在事务日志中,为了安全起见),然后每隔一秒左右,将一个新的小段写入磁盘,并"刷新"搜索.

这使得新段中的数据对搜索可见(即它们是"可搜索的"),但该段尚未与磁盘进行fsync,因此仍然存在数据丢失的风险.

每隔一段时间,Elasticsearch将"刷新",这意味着fsync'ing段,(它们现在"已提交")并清除事务日志,不再需要它,因为我们知道新数据已写入磁盘.

分段越多,每次搜索所需的时间越长.因此,Elasticsearch将通过后台合并过程将大量相似大小的片段("层")合并为一个更大的片段.写入新的较大段后,旧段将被删除.当存在太多相同尺寸时,在较大的段上重复该过程.

细分是不可变的.更新文档时,它实际上只是将旧文档标记为已删除,并为新文档编制索引.合并过程还会删除这些旧的已删除文档.

  • 谢谢你的详细解答.那么,有多少段太多或两个小?在我的例子中,每天创建一个450Gb的索引.我应该有多少段?另外,当我在优化时将max_segments设置为1时,你可以回答关于我的片段是11 + 11的部分吗? (2认同)
  • 我的观点并不是优化没有帮助,只是让Lucene为您管理它.对于48G节点,您的ES_HEAP_SIZE应该在24G左右.之后你需要弄清楚为什么你真的遇到了堆问题.您的facet字段中的大批量索引和高基数是两个常见问题.您可能也没有正确利用过滤器.最好为堆添加监视器并将其与群集上的实际活动相关联. (2认同)
  • @piyushGoyal否 - 请阅读http://www.elastic.co/guide/en/elasticsearch/guide/current/making-text-searchable.html#_immutability上的权威指南部分 (2认同)