batman

fromsize每种分页方式在不同的场景下有不同的优势和劣势。

在 Elasticsearch 中，terms_set查询通常用于在一个字段上进行多值匹配，并支持设置一个条件（例如最小匹配数量），让查询结果更具灵活性。为了展示如何使用terms_set查询，我们首先会创建一个索引，写入一些数据，然后演示如何进行查询。

操作类型目标说明示例index插入或替换文档插入，如果文档已经存在则会被替换。create插入仅在文档不存在时插入文档，如果文档已存在，则返回错误。update更新仅更新文档的一部分内容，文档必须存在。如果文档不存在，则返回错误。index用于插入新文档或替换现有文档。create用于仅在文档不存在时插入新文档，若文档已存在则返回错误。update用于更新现有文档的部分内容，若文档不存在则返回错误。

类型描述适用场景在多个字段上查找匹配，只选择相关性最强的字段作为最终匹配结果（默认）。如果只关注单个最相关字段，适用于精确匹配。将多个字段的相关性得分累加，最终返回得分最高的结果。如果多个字段的匹配结果对最终排序有较大影响。将多个字段合并为一个整体进行查询，适用于查询词分布在不同字段中的情况。如果多个字段包含查询的不同部分，且它们属于相同的概念。适用于你只关心最相关的字段结果时，通常用于精确匹配查询。适用于你希望多个字段的匹配都能影响查询结果时，适合宽松匹配。

操作通常用于合并或更新文档数据，确保目标文档的存在，同时避免因为文档不存在而导致的错误。非常适用于那些需要频繁更新或插入数据的场景，特别是在你不确定文档是否已经存在的情况下。的索引，并且你想通过文档 ID 来插入或更新用户信息。有时你可能需要使用脚本来动态更新文档的字段。在 Elasticsearch 中，upsert。如果文档中的字段是数组或对象，你也可以使用。索引，文档包含一个订单的详情。是一个常见的操作，用于执行文档的。插入一个新的订单或者更新现有订单。中使用脚本来更新字段值，或者在。

fuzzy查询：用于执行基于编辑距离的模糊匹配，适用于拼写错误、变体或近似匹配。fuzzinessAUTO：自动设置编辑距离。数字（如12）：指定允许的最大编辑距离。0：要求完全匹配。：设置匹配的前缀长度。：控制查询扩展的最大变体数量。

与嵌套类型不同，flattened类型是用于存储具有复杂、变化字段的结构。它将复杂对象展平，允许更灵活的查询和存储。flattened在 Elasticsearch 中，flattened类型字段非常适合存储结构化和非结构化的数据，它将嵌套的数据展平成平面结构，并可以通过简单的键值对来访问。在增、删、改、查操作上，flattened增（Indexing）：直接将复杂的 JSON 对象存入字段，Elasticsearch 会自动展平。查（Search）：通过常规查询语法查询展平后的字段。

首先，我们需要创建一个索引，并在映射中定义一个嵌套类型字段。假设我们有一个文档，其中包含一个嵌套的“address”字段，表示一个人可能有多个地址。"name": {},"age": {},"type": "nested", // 嵌套类型"city": {},在 Elasticsearch 中，嵌套类型允许你对结构化数据进行高效的存储和查询，但由于嵌套字段在查询时会被当作独立文档来处理，因此需要特别关注查询和更新的语法。通过nested。

在以上实战中，对应第一种情况，Object对象可以添加新的属性，添加了last字段。对应第二种情况，first添加了keyword类型，以组合构造fields。对应第三种情况，user_id添加了ignore_above。❑在已经存在的字段里面可以添加fields，以构成一个字段多种类型。❑ignore_above是可以更新的。❑Object对象可以添加新的属性。更新映射的操作如下所示。但以下3种情况例外。对此，实战验证如下。

我们可以清晰看到，插入第6条数据会触发max_docs:5的条件，原来的索引my-index-20250709-000001会继续保留，而新写入的第6条数据滚动到了新索引my-index-20250709-000002中。目前采用冷热集群架构，其中热节点使用SSD，并具有良好的索引和搜索性能，将数据保存4天后推送到温节点中，并使用HDD进行存储。某客户的线上业务场景如下：系统每天增加6TB日志数据，高峰时段的写入和查询频率都很高，导致Elasticsearch集群压力大，经常出现查询缓慢的问题。

映射类似于关系型数据库中的Schema（模式）。Schema在关系型数据库中是指库表包含的字段及字段存储类型等基础信息。映射定义由两部分组成：元字段、数据类型字段。

在以上实战中，对应第一种情况，Object对象可以添加新的属性，添加了last字段。举例：string类型匹配为text和keyword两种类型，但实际用户极有可能只期望排序和聚合的keyword类型，或者只需要存储text类型，如网页正文内容只需要全文检索，不需要排序和聚合操作。答：boolean类型、float类型、long类型、Object类型、Array类型、date类型、字符串类型。获取映射发现，create_date是text和keyword组合类型，不是我们期望的date类型。

业务需求是这样的：有一个作者字段，比如Li，LeiLei；Han，MeiMei以及LeiLei Li……现在要对其进行精确匹配。对此，你有什么想法？你可能会考虑用自定义分词的方式，通过分号分词。但是这样的话，如果检索Li，LeiLei，那么LeiLei Li就不能被搜索到，而我们希望LeiLei Li也被搜索到。并且对于这种分词，Li，LeiLei中间不加逗号也不能匹配到。但是为什么在映射里面添加停用词也是无效的呢？

当对keyword类型的字段进行高亮查询时，若值为123asd456，查询sd4，则高亮结果是＜em＞123asd456＜em＞。那么，有没有办法只对sd4高亮呢？用一句话来概括问题：明明只想查询ID的一部分，但高亮结果是整个ID串，此时应该怎么办？Ngram是一种基于统计语言模型的算法。Ngram基本思想是将文本里面的内容按照字节大小进行滑动窗口操作，形成长度是N的字节片段序列。此时每一个字节片段称为gram。

这两个参数共同提供了一种强大的控制机制，确保只有当所提供的版本信息与文档的最新状态一致时，才会执行写入操作。

也就是说，新插入的文档在刷新到段（内存中）之前是不能被搜索到的，如图所示。使用倒排索引的坏处是更新了词典词库后，老的索引不能生效，如果要使其可搜索，则必须重建整个索引或者借助reindex操作迁移索引。为了防止Elasticsearch集群宕机造成数据丢失，为了保证可靠存储，一个文档被索引之后，Elasticsearch就会将其添加到内存缓冲区，并且同时写入事务日志文件(translog)中。❑如果设置了副本，则数据会先写入主分片，主分片再同步到副本分片，同步操作会加重磁盘IO负担，间接影响写入性能。

【代码】Elasticsearch8.x 向量搜索实现图搜图及文搜图。

生产环境中大数据量的查询可以通过skipped shards 时间来过滤分片来提高查询效率。通过timeDate可以跳过149个分片。待查询的分片数大于 128。

自动刷新流程每秒会创建一个新的段（由动态配置参数refresh_interval决定），导致短时间内段数量暴增。而段数目太多会带来众多问题，包含但不限于如下几点。❑资源消耗：每一个段都会消耗文件句柄、内存和CPU运行周期。❑搜索变慢：每个搜索请求都必须轮流检查每个段，所以段越多，搜索也就越慢。Elasticsearch通过在后台进行段合并来解决上述问题。小段被合并到大段，这些大段再被合并到更大的段。段合并的时候会将那些旧的已删除文档从文件系统中清除。

在Elasticsearch（ES）中，您可以使用“预处理”（通常是通过处理器、Ingest Pipeline等方式）将JSON类型的数据转换为Object类型。假设您的文档中包含一个字段，字段内容是一个JSON字符串，您希望将其转换为对象格式。脚本也提供了在文档更新时动态转换数据的能力。处理器，允许在数据索引之前将JSON字符串解析成对象。处理器来将JSON类型数据转换为Object类型的示例。字段的一个对象，您可以在查询中直接使用该字段。来定义字段类型也是一种不错的选择。中的JSON字符串将被转换为。

使用enrich创建 Enrich Policy：定义从源索引中提取数据的规则。执行 Enrich Policy：执行政策并创建匹配数据。创建 Ingest Pipeline：在管道中使用enrich处理器，将匹配的数据合并到目标文档中。使用 Pipeline 索引数据：使用指定的管道进行文档索引。查询数据：查询文档，查看合并后的数据。更新和清理：根据需求更新或删除 enrich policy。通过enrich。

match_phrase检索适用于注重精准度的召回场景。与match检索（分词检索）不同，match_phrase检索更适合称为短语匹配检索。这是因为match_phrase检索要求查询的词条顺序和文档中的词条顺序保持一致，以确保更高的精准度。实战中建议——在需要精确匹配短语时使用match_phrase检索，以满足高精准度召回的需求。

Painless 是 Elasticsearch 中强大且高效的脚本语言，广泛应用于查询、更新、聚合、排序等多种操作。通过使用 Painless 脚本，开发者可以对 Elasticsearch 的行为进行细粒度的控制和动态计算，从而实现更灵活的功能。在实际应用中，合理使用 Painless 脚本能够帮助解决复杂的数据计算需求，但也需要注意性能和安全性，避免过度使用脚本影响集群性能。

因此，Elasticsearch 会在后台定期执行合并操作，将多个小段合并成较大的段，以提升查询效率并减少磁盘空间的使用。每当一个层次中的段数超出限制时，Elasticsearch 就会触发合并操作，将小段合并为更大的段，并向更高层次迁移。这些层次帮助管理段的合并，避免过度合并小段，同时确保合并后的段大小合理，能够有效地提升查询性能。采用分层的策略来管理段的合并，它的主要目标是控制每个层次中的段的数量、大小以及合并的频率，从而提高索引的查询效率，并避免过早或过频繁的合并。）来手动触发合并操作。

启用查询慢日志：可以通过设置查询慢日志阈值来启用，通常记录执行时间较长的查询。启用索引慢日志：记录索引、删除等操作的耗时，帮助定位性能瓶颈。使用慢日志能够帮助你监控和调优 Elasticsearch 的性能，发现并优化长时间运行的查询和索引操作。