Elasticsearch是开源搜索引擎，在深入使用Elasticsearch搜索引擎过程中，积累了一些经验和技巧，建议用户在使用云搜索服务时，作为参考。

提高索引效率

• 使用多进程或多线程发送数据到Elasticsearch

一个单线程发送bulk请求不能够发挥一个集群的索引能力。为了更好地利用集群的资源，应该使用多线程或多进程来发送数据，提升数据处理效率。

对于相同大小的bulk请求，通过测试可以得到最优的线程数量。可以逐步增加线程数量直至到集群中的机器Load或CPU饱和。建议使用“nodes stats”接口查看节点中的cpu和load状态，您可以通过“os.cpu.percent”、“os.cpu.load_average.1m”、“os.cpu.load_average.5m”和“os.cpu.load_average.15m”参数信息了解详细信息。

例如，在执行bulk请求时，使用的线程数量为2个，观察Load和CPU的情况，如果未饱和，可再增加线程数量。当线程数量增加到N个时，此时Load和CPU已饱和，建议就采用N个线程去执行bulk请求提高索引效率。通过测试获得最优的线程数量。

• 增加refresh_interval刷新的间隔时间

默认情况下，每个分片每秒自动刷新一次。但并不是所有场景都需要每秒刷新。在使用Elasticsearch索引大量的日志文件，想优化索引速度而不是近实时搜索，可以通过设置，降低每个索引的刷新频率。

PUT /my_logs 
{ 
  "settings": { 
    "refresh_interval": "30s" 
  } 
}

• 在初始化索引时，可以禁用refresh和replicas数量

如果需要一次导入较大数据量的数据进index里面时，可以先禁用refresh，把“refresh_interval”设置成为“-1”，把“number_of_replicas”设置成“0”。当数据导入完成后，将refresh_interval和number_of_replicas设置回原来的值。

选择合适的分片数和副本数

在创建索引数据时，建议指定相关的分片数和副本数，否则会使用服务器中的默认配置参数“shards=5, replicas=1”，即分片数为5，副本数为1。

分片数，与检索速度非常相关的指标，如果分片数过少或过多都会导致检索比较慢。分片数过多会导致检索时打开比较多的文件，且会导致多台服务器之间通讯慢。而分片数过少会导致单个分片索引过大，所以检索速度慢。

根据机器数、磁盘数、索引大小等设置分片数，建议单个分片不要超过30GB。总数据量除以分片数，则为分片的大小。

PUT /my_index 
{ 
  "settings": { 
    "number_of_shards":   1, 
    "number_of_replicas":  0 
  } 
}

将数据存放在不同的索引

Elasticsearch是基于Lucene进行索引和存储数据的，主要的工作方式是密集的数据，即所有的document拥有相同的字段。

• 避免把无关联的数据放在同一个index

不要把完全不同的数据结构document放在同一个index里。可以考虑创建一些较小的index，用较少的shard去存储。

• 避免不同的type放在同一个index

多个type放在单个index看起来是个简单的方法，但是Elasticsearch并不是基于type来存储的，不同的type在单个index会影响效率。如果type没有非常相似的mapping，建议放到一个单独的index。

• 同一个index里面不同type之间字段不能冲突

如果有两个不同的type，每个type都有同名的字段，但映射不同，这在Elasticsearch是不允许的。

按照时间范围创建索引

在Elasticsearch用于存储跟时间相关的数据时，如日志数据，建议按照时间范围创建索引，而不是把所有数据都存放到一个超级大的索引里面。

基于时间范围索引。可以开始于一个按年的索引（logs_2014）或按月的索引（logs_2014-10）。当数据量变得非常庞大的时候切换到一个按天的索引（logs_2014-10-24）。

按照时间范围创建索引具有如下优势：

• 扩容的时候根据当前数据量选择合适的shard和Replica

针对时间范围创建的每个索引都可以灵活的设置Shard数和Replica数，从而可以避免在一开始设置一个很大的shard来考虑扩容的情况。在集群扩容之后也可以方便的设置时间范围周期来适配集群规模。

• 删除旧数据只需要删除旧的索引

DELETE /logs_2014-09

• 利用alias机制可以在索引间灵活切换

例如，将logs_current的alias机制中的logs_2014-09索引删除，并在此alias机制中新增logs_2014-10索引。

POST
/_aliases{"actions": [{ "add":    { "alias":
"logs_current",
"index": "logs_2014-10" }},{ "remove": { "alias":
"logs_current",
"index": "logs_2014-09" }}]}

• 针对不再更新的索引，如上周或者上月的索引，进行索引优化以提高查询效率

将logs_2014-09-30索引下多个小segment合并成一个大的分片，以提高查询效率。

7.x之前版本

PUT /logs_2014-09-30/_settings 
{ "number_of_replicas": 0 } 
 
POST /logs_2014-09-30/_forcemerge?max_num_segments=1 
 
PUT /logs_2014-09-30/_settings 
{ "number_of_replicas": 1 }

7.x之后版本

PUT /logs_2014-09-30/_settings  
{ "number_of_replicas": 0 }  
 
POST /logs_2014-09-30/_forcemerge 
{ 
  "max_num_segments":1 
} 
 
PUT /logs_2014-09-30/_settings  
{ "number_of_replicas": 1 }

优化索引配置

• 区分text和keyword

在Elasticsearch中string字段被拆分成两种新的数据类型：text用于全文搜索的，而keyword用于关键词搜索。

对于不需要分词的字符串精确值字段，如标签或枚举，建议配置为keyword类型。

7.x之前版本

PUT my_index1 
{ 
  "mappings": { 
    "my_type": { 
      "properties": { 
        "tags": { 
          "type":  "keyword" 
        }, 
        "full_name": { 
          "type":  "text" 
        } 
      } 
    } 
  } 
}

7.x之后版本

PUT my_index1  
{  
  "mappings": {  
         "properties": {  
        "tags": {  
          "type":  "keyword"  
        },  
        "full_name": {  
          "type":  "text"  
        }  
      }  
    }  
  }

• 基于text字段的聚合统计

分词字段的聚合统计不是一种常见的需求。在Elasticsearch对于分词字段的聚合统计需要用到fielddata，默认是禁用的，开启fielddata会带来较大的内存负担。

建议的做法是分词字符串进行多字段映射，映射为一个text字段用于全文检索，和一个keyword字段用于聚合统计。

7.x之前版本

PUT my_index2 
{ 
  "mappings": { 
    "my_type": { 
      "properties": { 
        "full_name": { 
          "type": "text", 
          "fields": { 
            "raw": {  
              "type":  "keyword" 
            } 
          } 
        } 
      } 
    } 
  } 
}

7.x之后版本

PUT my_index2 
{ 
    "mappings": { 
            "properties": { 
                "full_name": { 
                    "type": "text", 
                    "fields": { 
                        "raw": { 
                            "type": "keyword" 
                        } 
                    } 
                } 
            } 
        } 
  }

使用索引模板

Elasticsearch支持通过索引模板控制一些新建索引的设置（settings）和映射（mappings），如限制分片数为1，并且禁用_all域。索引模板可以用于控制何种设置（settings）应当被应用于新创建的索引：

• 索引模板可以通过template字段指定通配符。
• 多个索引模板可以通过order指定覆盖顺序。数值越大，优先级越高。

如下示例表示，logstash-*匹配的索引采用my_logs模板，且my_logs模板的优先级数值为1。

7.x之前版本

PUT /_template/my_logs  
{ 
  "template": "logstash-*",  
  "order":    1,  
  "settings": { 
    "number_of_shards": 1  
  }, 
  "mappings": { 
    "_default_": {  
      "_all": { 
        "enabled": false 
      } 
    } 
  }, 
  "aliases": { 
    "last_3_months": {}  
  } 
}

7.x之后版本

7.x之后版本
PUT /_template/my_logsa 
{ 
  "index_patterns": ["logstasaah-*"], 
  "order": 1, 
  "settings": { 
    "number_of_shards": 1 
  }, 
  "mappings": { 
    "properties": { 
      "_all": { 
        "enabled": false 
      } 
    } 
  }, 
  "aliases": { 
    "last_3_months": {} 
  } 
}

数据备份和恢复

Elasticsearch副本提供了高可靠性，让您可以容忍零星的节点丢失而不会中断服务。

但是，副本并不提供对灾难性故障的保护。对这种情况，您需要的是对集群真正的备份，在某些东西确实出问题的时候有一个完整的拷贝。

备份集群，您可以使用创建快照的功能，将集群的数据保存到OBS桶中。其备份过程是智能的。第一个快照建议是数据的完整拷贝，后续的快照会保留的是已存快照和新数据之间的差异。随着您不时的对数据进行快照，备份也在增量的添加和删除。这意味着后续备份会相当快速，因为它们只传输很小的数据量。

用过滤提高查询效率

过滤器的执行速度非常快，不会计算相关度（直接跳过了整个评分阶段），而且很容易被缓存。

通常当查找一个精确值的时候，我们不希望对查询进行评分计算。只希望对文档进行包括或排除的计算，所以我们会使用constant_score查询以非评分模式来执行term查询并以一作为统一评分。

并以一作为统一评分。
GET /my_store/products/_search 
{ 
    "query" : { 
        "constant_score" : {  
            "filter" : { 
                "term" : {  
                    "city" : "London" 
                } 
            } 
        } 
    } 
}

采用scroll API返回大量数据

当返回大量数据时，先查后取的过程支持用from和size参数分页，但有限制。结果集在返回之前需要在每个分片上先进行排序，然后合并之后再排序输出。使用足够大的from值，排序过程可能会变得非常沉重，使用大量的CPU、内存和带宽。因此，强烈建议不要使用深分页。

为了避免深度翻页，推荐采用scroll查询返回大量数据。

scroll查询可以用来对Elasticsearch有效地执行大批量的文档查询，而又不用付出深度分页那种代价。scroll查询允许我们先做查询初始化，然后再批量地拉取结果。

查询（query）与过滤（filter）的区别

性能差异： 一般情况下，一次过滤会比一次评分的查询性能更优异，并且表现更稳定。

当使用过滤情况时，查询被设置为一个“不评分”或“过滤”查询。即这个查询只是去判断是否匹配，结果是yes或no。

例如，以下情况是典型的过滤情况：

• created时间是否在2013与2014这个区间？
• status字段是否包含published这个单词？
• lat_lon字段表示的位置是否在指定点的10km范围内？

当使用查询情况时，查询会变成一个“评分”的查询。和不评分的查询类似，也要去判断这个文档是否匹配，同时还需要判断这个文档匹配的程度如何。此查询的典型用法是用于查找以下文档：

• 查找与full text search这个词语匹配的文档。
• 包含run这个词，也能匹配runs、running、jog或者sprint。
• 包含quick、brown和fox这几个词，词之间离的越近，文档相关性越高。
• 标有lucene、search或java标签，标签越多，相关性越高。

验证查询是否合法

查询在和不同的分析器与不同的字段映射相结合时，会比较难理解，可以用validate-query API来验证查询是否合法。

示例：在Kibana的Console界面中，执行如下命令。validate请求会告诉您这个查询不合法。

7.x之前版本

GET /gb/tweet/_validate/query  
{  
 "query": {   
 "tweet" : {  
   "match" : "really powerful"  
  }   
}  
}

7.x之后版本

GET /gb/tweet/_validate/query   
{  
"query": {  
   "productName" : {  
  "match" : "really powerful"  
  }  
  }  
 }

为了找出查询不合法的原因，可以把explain参数加到查询字符串中，执行如下命令。

7.x之前版本

GET /gb/tweet/_validate/query?explain  
{ 
"query": { 
   "tweet" : { 
  "match" : "really powerful" 
  } 
  } 
 }

7.x之后版本

GET /gb/tweet/_validate/query?explain 
{   
 "query": {  
 "productName" : {   
   "match" : "really powerful"   
  }  
}   
}

返回结果如下所示，可以从返回结果看出查询类型（match）与字段名称（tweet）搞混了。

{ 
  "valid": false, 
  "error": "org.elasticsearch.common.ParsingException: no [query] registered for [tweet]" 
}

因此，对于合法查询，使用explain参数将返回可读的描述，这对准确理解云搜索服务是如何解析query是非常有帮助的。