Elastic日报第3期

[TOC]

地址：https://elasticsearch.cn/article/203

Elasticsearch 6.0 将严格校验 Content-Type

地址：https://www.elastic.co/blog/strict-content-type-checking-for-elasticsearch-rest-requests

大家知道 Elasticsearch 是 HTTP+Restfu 风格的，在 5.x 及以前的版本，Content-Type 一直是松散不校验的，从而存在跨站脚本攻击的可能，所以从 6.0 开始，所有带请求体的 HTTP 请求都需要带上正确的 Content-type 才能正常执行。

Elasticsearch: How to avoid index throttling, deep dive in segments merging

地址：https://www.outcoldman.com/en/archive/2017/07/13/elasticsearch-explaining-merge-settings/

max_merged_segment的默认大小为5GB，这意味着，更多的分片可以容纳更多的数据，max_merged_segment默认5gb的默认值会使多个段合并成一个索引，这会使搜索速度变慢。

实现步骤

1. 获取一系列按照大小倒序排列好的段(segments)；

Collections.sort(infosSorted, new SegmentByteSizeDescending(writer));

2. 计算索引总大小totIndexBytes以及最小的段的大小minSegmentBytes；

long totIndexBytes = 0;
long minSegmentBytes = Long.MAX_VALUE;
for(SegmentCommitInfo info : infosSorted) {
  final long segBytes = size(info, writer);
  // ... skipped ... //

  minSegmentBytes = Math.min(segBytes, minSegmentBytes);
  // Accum total byte size
  totIndexBytes += segBytes;
}

3. 排除大小大于max_merged_segment/2.0的段；

int tooBigCount = 0;
while (tooBigCount < infosSorted.size()) {
  long segBytes = size(infosSorted.get(tooBigCount), writer);
  if (segBytes < maxMergedSegmentBytes/2.0) {
    break;
  }
  totIndexBytes -= segBytes;
  tooBigCount++;
}

4. 如果最小的段的大小小于2m(floor_segment)，则将其大小设置为2m；
5. 计算allowedSegCount；

minSegmentBytes = floorSize(minSegmentBytes);

long levelSize = minSegmentBytes;
long bytesLeft = totIndexBytes;
double allowedSegCount = 0;
while(true) {
  final double segCountLevel = bytesLeft / (double) levelSize;
  if (segCountLevel < segsPerTier) {
    allowedSegCount += Math.ceil(segCountLevel);
    break;
  }
  allowedSegCount += segsPerTier;
  bytesLeft -= segsPerTier * levelSize;
  levelSize *= maxMergeAtOnce;
}
int allowedSegCountInt = (int) allowedSegCount;

合并策略

1. 从已排好序的段开始，跳过段大小大于max_merged_segment/2的段，按照大小从大到小进行合并；
2. 合并时，最多合并的段的个数不超过max_merge_at_once，默认为10；
3. 合并时，合并的结果的大小不超过max_merged_segment，默认为5g；
4. 如果剩下的段的个数依旧大于allowedSegCountInt，则继续从大到小进行合并。
   
   

   段合并示例图

其他要点

1. 改变floor_segment或者调用refresh会造成minSegmentBytes的值非常大，以至于allowedSegCountInt的值则变得很小，使得段合并操作比较频繁；
2. 改变segments_per_tier的值可以调整段合并的频率；
3. max_merge_at_once与segments_per_tier大小均为10。
4. 段合并会自动跳过max_merged_segment/2的段，即便该段中文档删除比已经超过了expunge_deletes_allowed(默认为10%)。如果你有很多这样的段，且这些段的空间不能被回收，你可以使用强制合并或者更改配置。
5. 对于小于max_merged_segment/2的段，如果文档删除比例大于expunge_deletes_allowed，那么这些文档可以被删除，如果没有其他合并的段被发现；
6. 如果一个段的大小恰好为max_merged_segment/2.0 - 1byte，那这个段则不会被合并；
7. 常规重建索引对提高搜索速度有一定帮助；
8. max_merge_count = index.merge.scheduler.max_thread_count(**Math.min(4, numberOfProcessors / 2)**) + 5；
9. 推荐将max_merge_count设置为一个较大的值，可以避免

curl -XPUT http://localhost:9200/*/_settings -d'{
  "index.merge.scheduler.max_merge_count": 100
}'

其他摘录

来源：http://blog.csdn.net/jingkyks/article/details/41810609

1. ES在发现merge操作落后与index的摄入量的时候，日志中会出现以"now throttling indexing"开头的INFO日志;
2. ES的默认设置对此是有考虑的：不想让search的性能受到merge的影响，但是在一些情况下（比如ssd，或者index-heavy），限制设置的上限确实有些低。默认是20mb/s，对于splnning disk而言，这个默认值非常合理。如果是ssd disk，可以考虑增加到100-200mb/s，对应设置项为indices.store.throttle.max_bytes_per_sec:"100mb"，逐个测试哪一个具体的数值更合适一些。
3. 如果是在做buck操作而无需考虑search性能的情况狂下，你当然想要让index的性能达到disk的极限了，因此设置indices.store.throttle.type:"none"，完全禁止merge。当index结束后，重新开启即可。
4. 如果是在使用spinning disk而非ssd，在elasticsearch.yml中增加以下设置：index.merge.scheduler.max_thread_count：1。Spinning disk在处理并发io的时候较慢，因此需要减少访问disk的并发线程数。上述设置将会允许3个thread。如果是ssd的话，可以忽略，默认的设置工作的就很好，Math.min(3,Runtime.getRuntime().availableProcessors()/2)。
5. 调整index.translog.flush_threshold_size，默认200mb，比如增加到1gb。这样会使得大的segment在flush之前先在内存中聚合。通过生成更大的segment，减少flush的频率，同时较少了merge的频率。以上所有的措施都在致力于较少disk io，以提升index性能。

Making your search not suck with Elasticsearch

适合初学者看的入门文章

• Part 1: What is an index?
• Part 2: Elasticsearch is not magic
• Part 3: Analysis Paralysis
• Part 4: Overanalyzing it
• Part 5: Are we still doing phrasing?
• Part 6: Totally irrelevant
• Part 7: Machines that learn