convert ingest 预处理 + reindex 结合方案。

In our last blog post of the Modernizing Nextdoor Search Stack series, we explained the Query Understanding and the ML models that power our Query Understanding Engine. We also covered the nuances of the Search at Nextdoor and what it takes to understand the customer intent. This time, we will be focusing on the retrieval of the search results and ranking.

Elasticsearch 7.9 之前的版本中的节点类型：数据节点、协调节点、候选主节点、ingest 节点，在 Elasticsearch 7.9 以及之后 版本中有了升级，升级了什么呢？

节点类型升级为节点角色（Node roles）。节点角色分的很细：数据节点角色、主节点角色、ingest节点角色、热节点角色等。

如何定时创建快照、定时删除时间比较久的历史快照呢？

搜索平台的公共集群，由于业务众多，对业务的es查询语法缺少约束，导致问题频发。业务可能写了一个巨大的查询直接把集群打挂掉，但是我们平台人力投入有限，也不可能一条条去审核业务的es查询语法，只能通过后置的手段去保证整个集群的稳定性。

我在做 Elasticsearch 相关咨询和培训过程中，发现大家普遍更关注实战中涉及的问题，下面我选取几个常见且典型的问题，和大家一起分析一下。

• 订单表、账单表父子文档可以实现类似 SQL 的左连接吗？通过 canal 同步到 ES 中，能否实现类似左连接的效果？具体应该如何建模？
• 一个人管理 1000 家连锁门店，如何更高效地查询自己管辖的商品类目？企微 一个人维护了 1000 个员工，如何快速查询自己管辖的员工信息？
• 随着业务的增长，一个索引的字段数据不断膨胀（商品场景变化，业务一直加字段），有什么解决方法？
• 一个索引字段个数设置为 1500 个，超出这个限制，会不会消耗 CPU 资源和造成写入堆积？
• 日志诊断用于机器学习基线，需要将 message 分离出来，怎么在写入前搞定？

如果我们对上述实战问题进行归类，就都可以归结为 Elasticsearch 数据建模问题。

本文将以实战问题为基准，手把手带你实践 Elasticsearch 数据建模全流程，重点解析基于业务角度、数据量角度、Setting 、Mapping ，以及复杂索引关联，这五个层面中涉及的数据建模实战问题，让你学完即可应用到工作中。

Elasticsearch（简称：ES）功能强大，其背后有很多默认值，或者默认操作。这些操作优劣并存，优势在于我们可以迅速上手使用 ES，劣势在于，其实这些默认值的背后涉及到很多底层原理，怎么做更合适，只有数据使用者知道。用 ES 的话来说，你比 ES 更懂你的数据，但一些配置信息、限制信息，还是需要在了解了 ES 的功能之后进行人工限制。

Over the past few years Content Engineering at Netflix has been transitioning many of its services to use a federated GraphQL platform. GraphQL federation enables domain teams to independently build and operate their own Domain Graph Services (DGS) and, at the same time, connect their domain with other domains in a unified GraphQL schema exposed by a federated gateway.

最简单、最常用的解决方式就是：写入前做好数据清洗，去掉“特殊字符”、“空格”等。

现在 ElasticSearch 大量应用在搜索领域，开发者可以通过其提供的多样的查询api达到希望的搜索效果，而且Elasticsearch版本也一直在不断迭代，以满足开发者的需要。但是，实际开发过程中，可能需要将搜索和自己的业务场景进行结合，来达到自定义的排序、搜索规则。Elasticsearch针对这种情况，提供了插件的功能，可以这么说，如果能够学会使用插件，那我们就有了自由扩充Elasticsearch功能的手段,对搜索的掌控力就能提升一个档次。

高 JVM 内存使用率会降低集群性能并触发断路器错误（导致内存熔断）。

为了防止这种情况发生，如果节点的 JVM 内存使用率持续超过 85%，官方建议采取措施降低内存压力。

Elasticsearch 高 CPU 使用率通常意味着一个或多个线程池不足以支撑业务需求。

如果线程池资源耗尽，Elasticsearch 将拒绝与线程池相关的请求。

本系列文章介绍如何修复 Elasticsearch 集群的常见错误和问题。

这是系列文章的第一篇，主要探讨：Elasticsearch 磁盘使用率超过警戒水位线，怎么办？

在cluster1上有如a，b两索引，均有字段filed_a，索引a，b各自包含其它字段，建立新索引如c，要求c包含a索引全部文档，且在a和b索引关联字段 field_a 相同的文档中把b文档其它字段更新到索引c中。

涅槃选品是京东零售内的战略级bigboss项目，项目主要致力于构建商品底层能力，打通提报、投放流程，实现选品的线上化、规则化与智能化；通过多方协作盘货，充分表达营销、品类、运营/采销等多方意志。

业务上的多样化需求，导致在项目初期面临以下众多技术难点与挑战。

最近几个线上问题，都和 Mapping 字段更新有关系，问题列表如下：

问题 1：

Mapping新创建后，还可以更新吗?

问题 2:

群友 A：有人知道怎么在kibana里面给索引新增，删除字段吗？

群友 B: 不就是改 mapping 吗

群友 A：怎么改？

群友 B：写dsl啊…

群友 A：只能加不能删吧？

问题 3：

各位同学们 现在有个业务需求帮忙看一下？

需求:将 A 索引中一个为 String 的字段修改为 boolean。

例: sdry:"1" -> sdry:true。

问题 4：

join 类型怎么修改 join，append一个新的child？

业务需要 append join children，官方也说可以 append，但是又没给方案，我尝试都失败了。

四个问题都可以归结为 Mapping 更新问题，我们一起梳理实践一把。