Elasticsearch是一个基于Lucene的搜索服务器，其搜索的核心原理是倒排索引，今天谈下在日常项目中使用它遇到的一些问题及优化解决办法。
一. 搜索的深度分页问题
在日常项目中，经常会有分页搜索并支持跳页的需求，类似百度、Google搜索那样，使用ES进行这类需求的搜索时一般采用from/size的方式，from指明开始的位置，size指定获取的条数，通过这种方式获取数据称为深度分页。
通过这种分页方式当我取 from为11000，size为10时，发现无法获取：
ES报错说超过了max_result_window
初步解决方案：
我修改了索引的设置，将max_result_window设置为了10000000：
PUT ccnu_resource/_settings
{
"index": {
"max_result_window": 10000000
}
}
这样做虽然解决了问题，并且目前在性能上也没有太大问题。一次当我用Google搜索时时，突发奇想，想试试Google的最大分页数：
我发现Google提示：Google为所有查询的结果数都不会超过1000，然后我迅速尝试了百度和微软的BING：
百度只显示76页，当修改url时，76页以外的也不会显示，这时候会跳到第一页，微软BING只会显示97页，当你继续下一页时它会回退当前页的前一页，这时候我重新查阅了ES分页遍历相关资料，这种from/to的方式采用的是深度分页机制，并且目前所有分布式搜索引擎都存在深度分页的问题。
ES深度分页：
由于数据是分散存储在各个分片上的，所以ES会从每个分片上取出当前查询的全部数据，比如from：9990，size：10，ES会在每个分片上取10000个document，然后聚合每个分片的结果再排序选取前10000个document；所以当from的值越来越大，页数越来越多时，ES处理的document就越多，同时占用的内存也越来越大，所以当数据量很大、请求数很多时，搜索的效率会大大降低；所以ES默认max_result_window为10000。
所以如果要使用from/size的方式分页遍历，最好使用ES默认的max_result_window，可以根据自己的业务需求适当增加或减少max_result_window的值，但是建议以跳页的方式分页最好控制页数在1000以内，max_result_window的值最好不要修改。
二. Mapping设置与Query查询优化问题
在ES中创建Mappings时，默认_source是enable=true，会存储整个document的值，当执行search操作的时，会返回整个document的信息。如果只想返回document的部分fields，但_source会返回原始所有的内容，当某些不需要返回的field很大时，ES查询的性能会降低，这时候可以考虑使用store结合_source的enable=false来创建mapping。
PUT article_index
{
"mappings": {
"es_article_doc":{
"_source":{
"enabled":false
},
"properties":{
"title":{
"type":"text",
"fields":{
"keyword":{
"type":"keyword"
}
},
"store":true
},
"abstract":{
"type":"text",
"fields":{
"keyword":{
"type":"keyword"
}
},
"store":true
},
"content":{
"type":"text",
"store":true
}
}
}
}
}
可以设置_source的enable:false，来单独存储fields，这样查询指定field时不会加载整个_source，通过stored_fields返回指定的fields，并且可以对指定field做高亮显示的需求：
GET article_index/_search
{
"stored_fields": [
"title"
],
"query": {
"match": {
"content": "async"
}
},
"highlight": {
"fields": {
"content": {}
}
}
}
使用store在特定需求下会一定程度上提高ES的效率，但是store对于复杂的数据类型如nested类型不支持：
# nested类型
PUT article_index_nested
{
"mappings": {
"es_article_nes_doc": {
"properties": {
"title": {
"type": "text",
"fields": {
"keyword": {
"type": "keyword"
}
}
},
"comment": {
"type": "nested",
"properties": {
"username": {
"type": "keyword"
},
"content": {
"type": "text"
}
}
}
}
}
}
}
添加数据：
PUT article_index_nested/es_article_nes_doc/1
{
"title": "Harvard_fly 浅谈 ES优化",
"comments": [
{
"username": "alice",
"date": "2018-11-13",
"content": "aaa"
},
{
"username": "bob",
"date": "2018-11-12",
"content": "bbb"
}
]
}
这种nested类型的store就不支持了，只能通过_source返回数据，如果需要返回指定field可以在search中通过_source指定field：
GET article_index_nested/_search
{
"_source": ["title","comments"],
"query": {
"bool": {
"must": [
{
"match": {
"comments.username": "alice"
}
},
{
"match": {
"comments.content": "aaa"
}
}
]
}
}
}
三. ES读写优化问题
ES读性能的优化主要是查询的优化，在查询中尽量使用filter，如果遇到查询慢可以使用explain进行慢查询，进而优化数据模型和query；对于ES的写优化，最好采用bulk批量插入，下面以python的api作为例子说明：
def bulk_insert_data(cls, qid_data_list):
"""
批量插入试题到ES库
:param qid_data_list: qid ES结构列表
:return:
"""
if not isinstance(qid_data_list, (list, )):
raise ValueError('qid_data_list数据结构为列表')
es = connections.get_connection()
index_name = cls._doc_type.index
doc_type_name = cls.snake_case(cls.__name__)
def gen_qid_data():
for dt in qid_data_list:
yield {
'_index': index_name,
'_type': doc_type_name,
'_id': dt['qid'],
'_source': dt
}
bulk(es, gen_qid_data())
使用bulk批量插入数据到ES，在Python中bulk位于elasticsearch.helpers下，但是使用bulk并不是一次插入的数据量越大越好，当一次插入的数据量过大时，ES的写性能反而会降低，具体跟ES硬件配置有关，我测试的一次插入3000道试题详情数据会比一次2000道速度慢，3000道试题详情大约30M左右。
如果追求写入速度，还可以在写入前将replicas副本设置为0，写入完成后再将其设置为正常副本数，因为ES在写入数据时会将数据写一份到副本中，副本数越多写入的速度会越慢，但一般不建议将replicas副本设置为0，因为如果在写入数据的过程中ES宕机了可能会造成数据丢失。
四. ES配置优化问题
在ES的集群配置中，master是ES选举出来的，在一个由node1、node2、node3组成的集群中初始状态node1为主节点，node1由于网络问题与子节点失去联系，这时候ES重新选举了node2为主节点，当node1网络恢复时，node1会维护自己的集群node1为主节点，这时候集群中就存在node1和node2两个主节点了，并且维护不同的cluster state，这样就会造成无法选出正确的master，这个问题就是脑裂问题。
脑裂问题的解决办法(quorum机制)：
quorum计算公式：quorum = 可选举节点数/2 + 1
只有当可选举节点数大于等于quorum时才可进行master选举，在3个可选举节点中，quorum=3/2+1=2 在node1失去网络响应后 node2和node3可选举节点为2 可以选举，当node1恢复后，node1只有一个节点，可选举数为1，小于quorum，因此避免了脑裂问题；即设置discovery.zen.minimum_master_nodes：quorum，可避免脑裂问题