ElasticSearch部分搜索，导入数据场景下的优化

mapping 优化：
{
	"my_type": {
		//关闭 "所有字段"这个字段的 索引
		"_all": {
			"enabled": false
		},
		"properties": {
			"tag": {
				"type": "text",
				//索引该字段，以便可搜索，但完全按照指定的值索引值。不指定分词器。
				"index": "not_analyzed",
				//该index_options参数控制将哪些信息添加到倒排索引中，用于搜索和突出显示目的
				"index_options": "docs",
				//规范存储各种规范化因素（用于表示相对字段长度和索引时间提升设置的数字），以便在查询时使用它们来计算文档相对于查询的分数。
				"norms": {
					"enabled": false
				}
			}
		}
	}
}

=====================索引之前===========================
如果你只是用bulk导入数据而不关注查询性能，可以关闭合并的阈值

PUT /_cluster/settings
{
    "transient" : {
        "indices.store.throttle.type" : "none" 
    }
}

批量索引前关闭刷新，关闭副本，索引完成再次打开
curl -XPUT 'localhost:9200/test/_settings' -d '{
    "index" : {
        "refresh_interval" : "-1"
    }
}'

curl -XPUT 'localhost:9200/my_index/_settings' -d ' {
    "index" : {
        "number_of_replicas" : 0
    }
}'


=====================索引完成===========================
PUT /_cluster/settings
{
    "transient" : {
        "indices.store.throttle.type" : "merge" 
    }
}


curl -XPUT 'localhost:9200/my_index/_settings' -d '{
    "index" : {
        "refresh_interval" : "1s"
    } 
}'

curl -XPOST 'localhost:9200/my_index/_forcemerge?max_num_segments=5'




================================================================================
如果是机械硬盘，你需要增加下面的配置到elasticsearch.yml中

index.merge.scheduler.max_thread_count: 1

机械硬盘的并发IO性能较差，我们需要减少每个索引并发访问磁盘的线程数，这个设置会有max_thread_count＋2个线程并发访问磁盘 
如果是SSD可以忽略这个参数，默认线程数是Math.min(3, Runtime.getRuntime().availableProcessors() / 2)，对于SSD来说没有问题。

可以增大index.translog.flush_threshold_size参数，默认是200M，可以增大到如1GB。增大这个参数可以允许translog在flush前存放更
大的段(segment);更大的段的创建会减少flush的频率，并且更大的段合并越少，会减少磁盘IO，索引性能更高。

================================================================================
Elastic 官方文档建议：一个 Node 最好不要多于三个 shards。
================================================================================
减少data node上的segment memory占用，总结起来有三种方法:
1.  删除不用的索引
2.  关闭索引 （文件仍然存在于磁盘，只是释放掉内存）。需要的时候可以重新打开。
3.  定期对不再更新的索引做optimize (ES2.0以后更改为force merge api)。这Optimze的实质是对segment file强制做合并，可以节省大量的segment memory。
================================================================================
Cluster State Buffer
ES被设计成每个node都可以响应用户的api请求，因此每个node的内存里都包含有一份集群状态的拷贝。
这个cluster state包含诸如集群有多少个node，多少个index，每个index的mapping是什么？有少shard，
每个shard的分配情况等等 (ES有各类stats api获取这类数据)。 在一个规模很大的集群，这个状态信息可能会非常大的，
耗用的内存空间就不可忽视了。并且在ES2.0之前的版本，state的更新是由master node做完以后全量散播到其他结点的。 
频繁的状态更新都有可能给heap带来压力。 在超大规模集群的情况下，
可以考虑分集群并通过tribe node连接做到对用户api的透明，这样可以保证每个集群里的state信息不会膨胀得过大。

================================================================================