Mac安装6.1.2版本Elasticsearch及优化配置实践

1，Mac上安装(指定java8)

brew cask install java8

vim .base_profile
文件内容：
JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1..0_162.jdk/Contents/Home
PATH=$JAVA_HOME/bin:$PATH
CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar

source .base_profile
echo .base_profile
brew install elasticsearch

安装中文分词插件（根据当前es版本）：
elasticsearch-plugin install https://github.com/medcl/elasticsearch-analysis-ik/releases/download/v6.1.2/elasticsearch-analysis-ik-6.1.2.zip

2，优化配置

#服务器优化：更改索引片断数量
ulimit -n  

#配置文集优化配置
自身配置文件：elasticsearch.yml
修改bootstrap.mlockall: true，禁止内存交换

jvm配置文件(GC)：jvm.options
-Xms1g 初始分配内存1g 总内存的50%但不能超过32G
-Xmx1g 最大使用内存1g

mac中配置文件路径：
/usr/local/etc/elasticsearch

3，Elasticsearch索引配置

使用mappings新建index
curl -X PUT 'localhost:9200/kline_test' -H 'Content-Type: application/json' -d '
{
"settings": {
    "number_of_shards": ,#分片数
    "number_of_replicas" :#副本数：未批量导入数据时建议不要进行副本
},
  "mappings": {
    "kline_data": {
      "properties": {
        "code": {
          "type": "text", #数据类型
        },
        "name": {
          "type": "text","analyzer": "ik_max_word",#使用可以对文本进行最大数量的分词
          "search_analyzer": "ik_max_word"
        },
        "market": {
          "type": "byte"，
        },
        "time": {
          "type": "date" ,
   　　　　"format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis",#指定数据的查询格式
        },
       "mongo_id": {
　　　　　　"type": "text",
　　　　　　"index": False #不对该字段进行索引，既无法作为查询条件
　　　　　　}
      }
    }
  }
}' 

※特别提示：在6.1版本之后doc的字段属性：

　　1，index的配置参数变更为True 或 False 而非之前的：not_analyzed和no

　　2，include_in_all参数取消，使用copy_to来自定义_all查询

　　3，详细参数说明见 http://www.cnblogs.com/dxf813/p/8447467.html

4，谨慎分片

　　当在ElasticSearch集群中配置好索引后, 在集群运行中你是无法调整分片设置。 如需要调整分片数量, 也只能新建索引并导入数据后通过更换别名aliases
　　对数据进行重新索引，虽然会比较耗时, 但至少能保证不会停机

 

　　每个分片都是有额外的成本的:

• • 每个分片本质上就是一个Lucene索引, 因此会消耗相应的文件句柄, 内存和CPU资源
  • 每个搜索请求会调度到索引的每个分片中. 如果分片分散在不同的节点倒是问题不大.，但当分片开始竞争相同的硬件资源时, 性能便会逐步下降
  • ES使用词频统计来计算相关性，当然这些统计也会分配到各个分片上，如果在大量分片上只维护了很少的数据, 则将导致最终的文档相关性较差

　　分片数量的确定：

　　　　原则：每个分片最好不超过30G，尽量不多过多分片

　　　　计算数量：在确定之初最好能估算出日后数据的总量，然后再进行分片（例如：未来数据可能是300G，那就至少需要10-11个分片）

　　　　※为保证查询质量，建议还是分片数量不要过大；网上有的人说分片不能超过20有的不能超过100

　　　　※个人认为需根据实际情况来进行优化，如果数据量再大且在增加额外的节点(ES会自动完成分片在不同节点上的分布平衡)后效率仍然没有改善，可新建另一个索引，然后通过程序中间件进行访问控制

　　　　※另外通过中间件可以进行特定数据存入指定分片(参数：_shards:0,1,2)，从而达到特定数据的集中存储，提高查询效率

 

　　节点数量确定（初期）：

　　　　节点数量<=分片数量*(副本数量+1)

 

5，使用optimize优化

　　-随着时间的推移，ElasicSearch中每个shard的数据也会越来越多，索引越来越大，而生成的segment（在每个shard中，每个索引文件实际是由多个sgment文件组成）也会越来越多。

　　而segment越多的话，则查询的性能越差，所以通过调用optimize命令，将多个segment合并成更少数量的segment(最少为一个)，从而来提高查询性能。

• • curl -XPOST http://localhost:9200/shb01/_optimize?max_num_segments=1

　　-在es中删除一个文档后不会立即从硬盘中删除只会标记这个文档被删除，lucene会产生一个.del文件，而在检索过程中这个文件还会参与检索只不过在最后会被过滤掉，

　　这样其实也会影响效率，我们可以定期删除这些文件，同合并索引片断一样可以通过curl

• • curl -XPOST http://localhost:9200/_optimize?only_expunge_deletes=true