Elasticsearch Mapping 如果不做特殊设置，默认为 dynamic。dynamic 的本质就是：不加约束的动态添加字段。这样对某些日志场景，可能会产生大量的未知字段。字段如果持续激增，就会达到 Elasticsearch Mapping 层面的默认上限，对应设置和默认大小为：index.mapping.total_fields.limit：1000。

我们把这种非预期字段激增的现象或结果称为：字段膨胀。

拿自己线上环境示例，说一下 dynamic 的副作用。在一个实际业务环境，混淆了检索和写入的语法，会导致将检索语句动态认定为新增 Mapping 字段。

当然，如果是非常复杂的大 bool 检索语句，会导致 Mapping 变得非常复杂甚至会出现字段膨胀的情况。

在使用Elasticsearch的过程中，你还在为构建Elasticsearch的DSL语句而苦恼？还在为构建复杂冗长的条件而头疼？还在为一次次的响应提取而奔溃？那么你需要一个简单方便易上手的ES ORM框架：ebatis！

在常规检索的基础上，用户期望返回基于特定字段的聚合结果，且用户期望分页查看检索和聚合结果。

如下图所示：以2020东京奥运会热点新闻亚洲飞人"苏炳添”为例，用户期望查看有关“苏炳添”的新闻，同时期望查看相同标题的相似文章列表。

在使用 Elasticsearch 过程中，不免还会有 Mysql 等关系型数据库的使用痕迹，以下两个都是实战开发问到的问题：

• Elasticsearch 新增字段，能在 Mapping 设置默认值吗？
• Elasticsearch 有什么好的方式维护文档的 create_time （创建时间）和 update_time （更新时间）吗？

本文就从 Elasticsearch 默认值的实现方案说开去。

有个复杂的场景涉及到按照求和后过滤，user_id是用户编号，gender是性别，time_label是时间标签，时间标签是nested结构，intent_order_count是意向订单数量，time是对应时间。

现在要筛选出在20210510~20210610，意向订单数总和为26的男性用户，请问应该怎么写dsl语句？

感觉这个场景很复杂，涉及到array判断后求和，然后求和结果做筛选条件。

关于人生，有人这么说：“人，生来一个人，死去一个人，所以，人生就是一个人生老病死的简称。”

在基于日志、指标、实时时间序列的大型系统中，集群的索引也具备类似上图中相通的属性，一个索引自创建之后，不可能无限期的存在下去， 从索引产生到索引“消亡”，也会经历：“生、老、病、死”的阶段。

我们把索引的“生、老、病、死”的全过程类比称为索引的生命周期。

用好文件缓存是关键。

问题1：想请问下，一次性获取索引上的某个字段的所有值（100 万左右），除了把 max_result_window 调大 ，还有没有啥方法？

问题2：关于 es 的分页，每次拿 20 条展示在前台，然后点击下一页，在查询后面的20条数据，应该要怎么写？

问题3：From+size、Scroll、search_after 的本质区别和应用场景分别是什么？

聚合分析中较为常见的 percentiles 百分位数分析。n 个数据按数值大小排列，处于 p% 位置的值称第 p 百分位数。比如说，每次网站请求访问的耗时，需要统计其 TP99，也就是整体请求中的 99% 的请求的最长耗时。

本篇文章着重分析 ElasticSearch 在全文搜索前如何使用 ik 进行分词，让大家对 ElasticSearch 的全文搜索和 ik 中文分词原理有一个全面且深入的了解。

Elasticsearch 写入问题涉及写入流程、写入原理及优化策略。

在寻求解决方案的时候，我们要先问一下：为什么大家喜欢用 wildcard 实现模糊检索?

得到的答复往往是：顺手，类似Mysql like 查询，短、平、快的达到了产品经理的要求，满足了项目需求。

但，这忽略了性能问题以及可能带来的灾难后果。

所以，解决方案应该从根源上入手，以寻求彻底解决。

自定义分词同义词这个细节官方文档解释的不细，死磕一把，探个究竟。

在生产环境搭建或维护 Elasticsearch 集群和个人搭建集群的小打小闹有非常大的不同。

有数百万数据需要导入 Elasticsearch 做性能对比测试，但当前数据存储在 Mysql 中，且核心字段以 Json 字符串形式存储。有没有又快又好的方法？接收同事是非开发人员，如果不写一行代码（脚本）就更好了！

Elasticsearch 线程池和队列问题，这篇说透了！