[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的默认值会使多个段合并成一个索引，这会使搜索速度变慢。
实现步骤
- 获取一系列按照大小倒序排列好的段(
segments)；
Collections.sort(infosSorted, new SegmentByteSizeDescending(writer));
- 计算索引总大小
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;
}
- 排除大小大于
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++;
}
- 如果最小的段的大小小于2m(
floor_segment)，则将其大小设置为2m； - 计算
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;
合并策略
- 从已排好序的段开始，跳过段大小大于
max_merged_segment/2的段，按照大小从大到小进行合并； - 合并时，最多合并的段的个数不超过
max_merge_at_once，默认为10； - 合并时，合并的结果的大小不超过
max_merged_segment，默认为5g； - 如果剩下的段的个数依旧大于
allowedSegCountInt，则继续从大到小进行合并。
段合并示例图
其他要点
- 改变
floor_segment或者调用refresh会造成minSegmentBytes的值非常大，以至于allowedSegCountInt的值则变得很小，使得段合并操作比较频繁； - 改变
segments_per_tier的值可以调整段合并的频率； -
max_merge_at_once与segments_per_tier大小均为10。 - 段合并会自动跳过
max_merged_segment/2的段，即便该段中文档删除比已经超过了expunge_deletes_allowed(默认为10%)。如果你有很多这样的段，且这些段的空间不能被回收，你可以使用强制合并或者更改配置。 - 对于小于
max_merged_segment/2的段，如果文档删除比例大于expunge_deletes_allowed，那么这些文档可以被删除，如果没有其他合并的段被发现； - 如果一个段的大小恰好为
max_merged_segment/2.0 - 1byte，那这个段则不会被合并； - 常规重建索引对提高搜索速度有一定帮助；
-
max_merge_count = index.merge.scheduler.max_thread_count(**Math.min(4, numberOfProcessors / 2)**) + 5； - 推荐将
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
- ES在发现merge操作落后与index的摄入量的时候，日志中会出现以"now throttling indexing"开头的INFO日志;
- ES的默认设置对此是有考虑的：不想让search的性能受到merge的影响，但是在一些情况下（比如ssd，或者index-heavy），限制设置的上限确实有些低。默认是20mb/s，对于splnning disk而言，这个默认值非常合理。如果是ssd disk，可以考虑增加到100-200mb/s，对应设置项为
indices.store.throttle.max_bytes_per_sec:"100mb"，逐个测试哪一个具体的数值更合适一些。- 如果是在做buck操作而无需考虑search性能的情况狂下，你当然想要让index的性能达到disk的极限了，因此设置
indices.store.throttle.type:"none"，完全禁止merge。当index结束后，重新开启即可。- 如果是在使用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)。- 调整
index.translog.flush_threshold_size，默认200mb，比如增加到1gb。这样会使得大的segment在flush之前先在内存中聚合。通过生成更大的segment，减少flush的频率，同时较少了merge的频率。以上所有的措施都在致力于较少disk io，以提升index性能。
Making your search not suck with Elasticsearch
适合初学者看的入门文章
