我们团队基于Elasticsearch开发了一款将数据从数据库实时同步至Elasticsearch的工具——搜索平台，其实现方式主要是通过flink将数据库中已有的存量数据导入Elasticsearch，并订阅数据表的binlog，将实时改动也同步至Elasticsearch。

AIoT团队在搜索平台上维护了一个较大的索引，其写入平均有2k到3k的tps，查询也有数百QPS。由于该索引较重要且占用资源较多，因此使用Elasticsearch的template功能将之单独部署在专用的机器上。

从5月底开始，写入此索引的flink实时任务就会偶现失败重启的情况，经排查，发现是写入Elasticsearch的请求超时导致的，结合当时机器的cpu占用等指标判定是写入tps过高导致Elasticsearch无法承受，因此，将该索引所占的机器从2台升级到3台，并使用业务数据进行了一轮写入压测，发现能支撑业务方的写入速率，扩完后较长一段时间内，该索引也一直没有出现问题，因此认为问题已经被解决了。

假定有两个索引 index1、index2，这两个索引中有大量相同数据。类似：linux 下的 diff 命令的操作，找出一个索引中存在而在另外一个索引不存在的数据。

es能通过两个字段差值进行查询吗？类似 select * from myindex where endtimes- starttime > 10 这种？

Elasticsearch java 客户端各个版本的发展演进历史、选择哪个、如何选择是本篇文章要解决的问题。

领域特定语言（DSL），如 SQL、Elasticsearch Querystring 等，往往是为专门的目的设计的。在特定的任务中，DSL 通过在表达能力上做的妥协换取在某一领域内的高效。

在飞书套件日志系统的私有化研发过程中，为了符合研发同学查询日志的习惯，尝试使用 Elasticquery Querystring（下简称为 Querystring）作为过滤器的查询条件语句，由此需要可用的 Golang Querystring 解析器。由于目前开源界无法找到完善的实现，尝试使用 Goyacc 自行构建。

In a previous post, we described the indexing architecture of Studio Search and how we scaled the architecture by building a config-driven self-service platform that allowed teams in Content Engineering to spin up search indices easily.

This post will discuss how Studio Search supports querying the data available in these indices.

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功能的手段,对搜索的掌控力就能提升一个档次。