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，可避免脑裂问题