使用ElasticSearch的44条建议

es中建索引是指创建一个保存数据的目录，用于保存倒排索引，索引创建之后是不可变的（Immutable），只允许新增字段。

因为lucene中field是带类型的，不同类型的字段进入倒排索引后会经过压缩，long/int/short占用的字节长度不一，如果修改字段类型，很可能导致从索引文件中解压字段失败，更不要提string=>int之类的变换了；此外es会将文档id压缩存储（有序列表->差值形式->压缩），并通过跳跃表来提高查询性能，倒排索引查出term对应的doc_id集合，再用doc_id取field value用于排序或聚合，其实是lucene的实现，所以要变更索引文件代价很大，需要解压=>变更=>压缩，大量的CPU和io操作。

es1.x版本默认date类型处理会在format parse失败后尝试用long.valueOf来转换，假设字段配置为date类型，format为YYYY-MM-dd HH:mm:ss，那么传入一个"12345"的string类型，es1.x版本是不会报错的，会把"12345"转成long再转成UTC时间；es5.x版本已经修复这个问题。

如题。

es的source是单独作为一个字段存储的，而且是保持传入的样式原样保存，假设字段A类型为long，如果传入的doc={A: "12345"}，即使A为string类型也是可以正确录入的，但是返回的source中字段A还是保持string形式"12345"，不会转换成配置的long类型。

Es作为存储来说更像是一个文档数据库，下文有提到。

es版本执行写请求时，如果源文档设置的version与已存在的文档冲突（默认策略provided version > stored version算成功），会报version conflict异常，即使是在index或者create操作时显式设置version，也有可能会抛出版本冲突异常。

如题，除非修改VersionType为gte（设置force=true也行，不建议做，会强行覆盖原数据），否则有并发更新时，如果别的请求先于你的更新，乐观锁检查就会失败。

update时可以通过设置retry-on-conflict来降低版本冲突异常出现次数，在遇到version冲突时，引擎会根据设置的retry次数（默认是0）来自动重试，如果重试后更新成功则返回成功，当然在极端情况下（重试n次之后依然冲突）还是会抛version conflict异常。

注意，设置retryOnConflict请保证此次操作是幂等的，如果不是，还是在业务程序内处理重试吧，比如一个带状态的字段更新，A请求更新为1，B请求更新为2，B先于A更新成功，A报conflict异常，如果设置了重试，最终的更新结果是状态变为1，sad。

es的match操作不走缓存，即使索引量较小（几十万文档），一次匹配全文档的match操作（match: {title: xxx}）至少有几十万次计算（与文档数正相关），如果qps很高，同样会因为集群CPU过高而阻塞search线程池，导致集群无响应。

如题，match操作每次都会实打实的计算，耗CPU，搜索应用务必保证基础的结果缓存（需要自己实现）可用，减少match请求次数。

translog有request落盘的方式（每次写数据都会落盘）和async方式（batch，累积一定量数据后落盘），es5.x默认使用的是request方式，也就是优先保障数据不丢；但es1.x只有async方式，以性能优先，每隔一段时间（默认5s）检查是否需要将translog落盘，在机器掉电情况会有数据丢失风险。

translog的持久化参数主要有三个：index.translog.durability控制通过request还是async方式持久化到磁盘，如果通过async方式，index.translog.flush_threshold_size控制堆积多少数据后触发一次flush操作，index.translog.sync_interval控制间隔多少时间出发一次flush操作。

如果Es应用场景数据更新很频繁，新对象生命周期很短，如果young区分配比较小，可能会造成大量短生命周期的新对象涌入old区，引起full gc导致集群不能正常响应（视old gc的算法而定，如果是g1则full gc会退化成serial gc），需要控制young区在合适的比例，但是也会造成ygc的停顿时间变长，表现为比较明显的rt毛刺。

视gc算法而定，g1算法的ygc也会stw，cms算法在heap超过16g情况下表现不是很好。

操作es常见的三种异常：DocumentAlreadyExists（文档已存在，有并发create操作易发生），VersionConflict（版本冲突，有并发update操作易发生），DocumentMissing（文档不存在，有并发的create／update／delete操作时易发生）。

Es5.x取消了DocumentAlreadyExists异常，也将其视为VersionConflict。

should查询子句在query和filter中语义不同，在filter中should条件必须至少满足一个（is or not的问题），在query中如果同时存在must或must_not条件则不要求should条件必须满足一个（how well的问题，should条件满足会提高查询得分_score），如果要求query中should与filter的语义类似，可以设置bool字句中的minimum_should_match参数为1解决。

bool query中的should默认不做必须命中要求（只有should条件除外），bool filter中的should必要至少命中其中一个子条件。

推荐将不用来计算相似度的字段的norm属性关闭，比如时间/状态等仅用来filter或aggregation的字段，可以减小索引大小，默认会用1 byte/doc来存储字段的norm值，即使某个文档根本没有对应的字段。

tf/idf是经典的相似度计算模型，可以用来理解相似度计算，一个查询先分解为n个term，计算每个term的tf/idf值（其中就有norm），然后以该值作为空间向量权重，形成n维向量空间，再应用余弦定理计算n维空间内查询词与文档的相似度，得到文档匹配分。

Es5.x默认使用bm25作为相似度计算方法了。

Es的核心是倒排索引，也就是term -> doc_id的形式，如果是分词字段，索引过程是先分词，然后将分词后的term与文档id结对成为倒排索引文件，假设索引字段为title=“测试商品”，采用bigram的分词方式，那么最终的倒排索引是"测试"=>id / "试商"=>id / "商品"=>id；match查询则是将查询词分词后转为term，再用term去和倒排索引进行"精确"匹配，比如查询"商品"，分词后term="商品"，和倒排表精确匹配得到doc_id即是查询结果，如果搜索"商"，分词term="商"，倒排索引中是没有这个term的，因此查询结果为空；搜索引擎的match查询并不等同与mysql的like查询，如果要搜索类似mysql的"商品%"条件，Es的表现是不太好的。

Es没有B树索引，prefix查询是通过状态机实现的。

match操作能不能搜到结果主要看存储字段分词后的term能不能与查询条件分词后的term匹配上，假设"美观建筑真好看"分词后得到"美观"/"建筑"/"真"/"好看"/"好"，如果用term搜索"真好看"，那么在倒排表中无法找到对应的词条（term不分词），找不到结果；如果用match搜索"真好看"，那么也会被分词为"真"/"好看"/"好"，这时就可以在倒排表中找到对应的词条了；再比如搜索"观建"，假设分词后得到"观"/"建"/"观建"，虽然字段中存在这几个字符，但是倒排表中并没有，所以也找不到结果。

match_phrase匹配比较严格，在全匹配的基础上还要求字符顺序一致，可以有效提高查询准确率，但是为了保证召回率，一般情况下会搭配一个半匹配match使用，例如："bool":{"should":[{"match_phrase":{"title":"test"}},{"match":{"title":"test"}}]}。

比如"漂亮又美观的建筑"，通过match查询"漂亮 建筑"可以得到结果，但是通过match_phrase查不到，因为"漂亮"和"建筑"之间的position_gap>1，可以通过slop参数控制position_gap的大小。

使用scan操作时需注意，es1.x版本init scan不会返回hits，只有在next scroll时才会返回，循环调用scan时注意控制条件，第一次应当判断totalHits>0，后续可以用hits.length>0判断。

scan操作只有Es1.x版本支持，Es5.x版本只提供scroll。

es1.x版本scroll和scan是不同的操作，在scan时如果设置size＝10，则返回size num_of_shards条数据，假设索引分了5个shard，共返回50条数据，而普通scroll操作时如果设置size＝10，则最多只会返回size条数据，即使索引分了5个shard，也只会返回10条数据，但是普通scroll效率没有scan高；es5.x对默认排序的scroll操作做了定向优化来替换scan，因此只保留了scroll。

按照段内顺序（doc_id）直接出结果，减去聚合排序步骤，但是得到的结果可以被认为是无序的，doc_id按照写入顺序排列。

es的数值类型都是带符号的，尽量将数值字段值控制在signed long范围内[-2^63]~[2^63-1]，否则只能用分拆方法或者用string类型来存储，但是会使排序或者范围查询达不到预期效果。

对于java不是很熟悉的同学更需注意，不要因为数值范围限制而导致重建索引。

索引mapping默认关闭了自动映射功能，写入不在mapping中的字段会抛出异常，原因是自动映射是根据第一次遇到的字段内容来推断类型的，假设字段A是商品名称且事先未配置mapping，那么如果第一个写入es的doc中字段A内容是"12345"，es就会给字段A定义为long类型，就不符合预期了。

推荐将mapping中的dynamic设置为strict，在出现未配置的字段时抛出异常，避免因为字段自动映射错误而导致重建索引（原因见01条）。

es通过任务队列来削峰限流，默认search queue=1000，index queue=200，如果短时流量过高导致队列溢出，就会抛出EsExecutionReject异常，而任务队列都是全集群共享的（某索引大量占用队列就会导致其他索引占不到资源，而无法响应），如果多索引共享集群，尽量能控制每个索引的写入速率。

如题，另外最好也能控制每个索引的match qps，避免过多match导致CPU资源耗尽。

慢查询比较多的索引也同样会堵塞es的search任务队列（典型的如单一的海量数据索引，短时一个波峰很容易导致es抛Reject异常），因此线上业务最好根据自身应用场景开启索引的慢查询日志。

Es默认的慢查询阈值有点大（秒级），一般偏存储类的应用能接受的rt在200ms以内，线上业务需要做好慢查询优化，比如没有合理使用用filter缓存/terms条件内id过多/多次sort/match长度过长/索引数据量过大等。

Es的Java API需要通过捕捉运行时异常来处理异常操作。

如题，写业务代码最好加上try catch代码块。

es的增改删（cud）操作本质都是lucene的index/delete两种操作的组合，update操作就是先取出stored的原文档字段，与本次操作数据合并后重新index回索引，然后delete原文档，也因此写操作index queue其实就包含了所有增改删的任务。

lucene暴露的接口是addDocument/updateDocument，而addDocument接口还是调用updateDocument方法，不要只看名字，其实updateDocument就是先写入新文档（不是partial update），然后标记老文档为deleted状态。

Es是一个近实时（NRT）的服务，索引的刷新时间（refresh_interval）控制了文档数据的延时程度，如果设置了-1，则新增文档或被更新的文档必须等到索引的translog达到commit条件触发刷新操作后才能可见。

也就是达到index.translog.flush_threshold_size配置的大小，进行一次lucene commit操作，生成新段并打开，注意不要混淆索引的flush操作和translog的fsync操作。

因为lucene在删除文档时只是标记删除，标记删除的doc_id在查询出候选结果时被用来过滤，标记删除的文档只有在merge阶段才会被物理删除，真正释放磁盘空间和机器资源，一般更新比较多的索引残留的deleted docs会比较多（更新就是index＋delete的组合），在实际的搜索过程中，标记删除的索引文档会和普通文档一样会被加载到内存并纳入计算，也会被decode到doc_id，撑大倒排索引，这直接影响到索引的读写性能。

Es的删除操作（也就是lucene的删除操作）是先标记删除，并单独在一个文件中存放标记删除的doc_id，用于在查询时将删除文档过滤掉；删除的文档只有在段合并（merge）阶段通过重写索引文件才会物理删除。

更新太频繁导致merge跟不上新产生的标记删除文档，可以通过deleted文档比例来判断更新操作是否过于频繁，尽量合并多个字段的更新为一次请求。

Es带sort的查询需要在倒排索引匹配结束后，拿到索引文档的id_set（此时无序），然后通过id获取对应字段的值（fielddata/doc_value），通过优先级队列或者其他容器来计算顺序，建议能少做sort就少做。

如题，尽量减少带文档字段排序的请求，如果有多个字段排序，避免第一字段值太单一（第一排序相等，降级到第二字段排序来确定文档顺序）

另外尽量避免用string/array/nested等高级类型来做排序，string排序是字典序，多值字段排序会有更多运行时计算，会拖慢查询影响时间。

Es的_score排序表示按照查询匹配分排序，需要注意两点：1. 比如term之类的精确匹配其得分是固定值的；2. 模糊查询match条件返回的得分经过normalize之后也可能会得到相同的得分，得分相同的查询结果会在结果展示上表现出一定的随机性，建议在_score之后加上第二排序条件，在匹配分相同时保证顺序固定，比如：[{"_score":"desc"},{"_id":"desc"}]。

如题，另外需要注意的是，如果查询的意图是match，匹配度最高在前，但是又在sort条件中指定了字段排序，比如time:desc，那么得到的结果是满足match匹配度（默认75%）前提下time越新的越前（一般是不满足期望的）。解决方法可以是设置匹配度100%，要求全部文字匹配，或者用上面提到的方法，将_score排序放到第一位。

close索引的时候最好先把alias去掉，如果一个alias包含多个索引，其中一个索引带着alias被close掉，用这个alias来检索会失败。

Es可以通过一个alias来关联多个真实索引，可以实现比如按天切分的索引当作单一索引使用，但是如果alias包含了closed状态的索引，Es不会跳过这个索引，而是会抛出IndexClosed异常。

使用了nested字段类型的索引，其创建某个文档，如果其中嵌套了2个子文档，加上父文档，总共会创建2+1个文档。

使用nested字段类型如果嵌套文档过多，会导致索引极速膨胀，影响读写性能，使用嵌套字段务必先了解清楚业务应用场景。

lucene 6.x使用有限状态机FSA来提高模糊查询性能（fuzzy/prefix），但是实现有缺陷，使用了递归来判断状态机是否有限状态，如果前缀查询输入了一个长字符串（状态机很大），在调用Operations.isFinite方法时会导致栈溢出StackOverflow异常，使得执行此查询的索引的shard所在进程直接退出，Es6.x版本修复，6以下版本建议限制查询长度及正则查询，同时控制索引shard个数，避免全集群机器全部宕机。

lucene内部用了一个递归操作来判断状态机是否有限，如果是个无限状态机或者状态机很大，递归太深就会导致栈溢出。。sad。

es5.x版本在update时会判断更新前后的值是否有变化，如果欲更新字段的新值与已存在的值一致，那么会跳过实际的写操作直接返回OK，所以如果发现更新返回成功，但是version没有自增，可以检查是否欲更新字段的值与已存在的值相同。

如果发现更新后version没有变化，可以check一下是否此类情况，如有依赖version自增的业务，这点更是务必明确。

Es作为存储更像是个文档数据库，存的是个json，返回的数据格式也是json反序列化时自动推测的，不会按照预置的mapping字段类型返回，Es设置的mapping对存储内容无效，只是在建索引时类型检查/转换用。

Es的_source内部是lucene的一个indexed=false/stored=true的字段，之所以单独存放到一个_source字段，猜想是为了提高存储内容的访问速度，如果是用lucene索引字段的stored内容，取一次source就需要遍历全部fields了。

推荐根据字段的取值来设置字段类型，如小于7个枚举值可以用byte，减少索引文件的overhead，也避免在Es中存储大容量字段，即使不用来索引；可以不索引的字段就不索引（indexed: no），可以减小倒排索引文件，提高读写性能。

lucene生成的索引文件在存储时会根据字段类型占用的字节长度进行补齐，方便跳跃访问，用精确的字段类型可以减少io上的虚耗。

Es中存储的大字段也会在段文件中保存（段文件有很多不同用途文件组成），会影响读写性能（merge操作会变多，也变慢，访问频率如果很高也会导致内存中不断生成大对象）

分词后的字段会变成小粒度的词条，比如"美观的建筑"分词后可能会变成"美观"/"建筑"（视分词算法而定），不会保留原始内容（"美观的建筑"不会进入倒排表），也就无法用term条件来查询了，只能用match。

如果需要同时对某个字段进行多种分词（包括不分词），可以通过multi-field来解决。

分词问题详见第24条。

这里列了遇到比较的一些点，不是全部，更多的细节还需要深入挖掘。

欢迎大家长按关注跳跳爸的微信公众号：