yonggeit的博客

Created with Raphaël 2.3.0何种数据类型我的确认？结束yesno

通过这个案例，我们可以看到合理调整分片分配策略对于维护Elasticsearch集群性能的重要性。通过本文的深入讲解和实战案例分析，我们希望您能够更好地理解和应用Elasticsearch的分片分配策略。合理的分片分配不仅能够提升集群性能，还能在面对数据量增长和节点变化时保持集群的稳定性。希望您能够将这些知识应用到实际工作中，优化您的Elasticsearch集群。

在当今信息爆炸的时代，如何从海量文本数据中快速准确地检索出相关信息，成为了一个迫切需要解决的问题。自然语言处理（NLP）技术的发展为这一挑战提供了新的解决方案。Elasticsearch，作为一个强大的搜索引擎，通过集成NLP技术，使得文本嵌入和向量搜索成为可能。本文将带你深入了解如何部署Elasticsearch进行NLP任务，包括文本嵌入和向量搜索的详细步骤和实践案例。

ES数据建模实例讲解与实战技巧一级目录二级目录三级目录一级目录二级目录三级目录

Elasticsearch，作为开源的分布式搜索和分析引擎，以其强大的全文搜索能力、数据分析和操作的灵活性而闻名。它通常用于实现复杂的搜索功能，如日志分析、全文搜索、操作情报等。随着数据量的增长和业务需求的扩展，单一集群可能无法满足所有的需求，这时跨集群搜索（Cross-Cluster Search，简称CCS）就显得尤为重要。CCS允许用户在多个Elasticsearch集群之间执行联合搜索，这意味着你可以在一个查询中同时搜索多个集群的数据，而不需要在应用层手动合并结果。

在当今的数据驱动时代，Elasticsearch已成为处理大规模数据集的事实标准。它不仅提供了快速的搜索能力，还支持复杂的数据分析。然而，随着数据量的不断增长，如何高效地管理这些数据成为了一个挑战。Elasticsearch ILM（Index Lifecycle Management）应运而生，它允许我们自动化地管理索引的整个生命周期，从而优化性能和成本。使用ILM主要涉及两个步骤：定义生命周期策略和应用该策略到索引。

Elasticsearch是一个基于Lucene的搜索引擎，它提供了分布式、多租户能力的全文搜索引擎，具有HTTP web接口和无模式JSON文档的特点。Elasticsearch能够解决日益增长的数据量和实时性要求，是当前最流行的企业级搜索引擎。它通常用于日志分析、全文搜索、操作情报等场景。Elasticsearch的安全配置涉及多个方面，包括权限控制、数据加密、审计日志等。通过合理配置这些安全特性，我们可以有效地保护Elasticsearch集群的数据安全，防止数据泄露和未授权访问。

Elasticsearch的冷热架构为我们提供了一种灵活、高效的数据存储与检索方案。通过合理规划和配置，我们可以实现数据的高性能访问和低成本存储，满足不同业务场景的需求。随着Elasticsearch技术的不断发展，我们有理由相信它将在大数据处理领域发挥更加重要的作用。

在配置和使用熔断器时，最佳实践包括开启以利用G1垃圾收集器的特性，以及根据实际情况调整其他配置。了解熔断器的工作原理和配置对于维护Elasticsearch集群的稳定性和性能至关重要。通过深入理解熔断器的机制，我们可以更好地管理Elasticsearch集群的资源，确保在高负载情况下系统的稳定性和响应能力。熔断器不仅是资源管理的工具，也是系统设计中重要的安全网。

Elasticsearch搜索流程及原理详解一级目录二级目录三级目录一级目录二级目录三级目录

从 stackoverflow 上了解到，当 Elasticsearch 所在磁盘占用大于等于 95% 时，Elasticsearch 会将所有相关索引自动置为只读（Elasticsearch 官方文档有介绍）。从错误信息的大意来看，要操作的索引是只读的，无法进行插入或删除操作。然而，这个索引自从创建以来，从未修改过配置，为何会突然报错呢？在一个稳定运行的功能中，突然收到报错。建议采用第一种，注意解决之后，需要手动把被锁的索引的只读模式关闭。

分片大小差不多的情况下，节点 76 的分片数还比别的节点还少 10 个左右，它的磁盘空间反而多占用了 8TB。这是不是太奇怪了？事出反常必有妖，继续往下查。

可以看出 ik_max_word 分词器把所有的字典结果都匹配出来了，同时也看到了好几个词元的位置是有重叠的，比如：“中华人民”“中华”“华人”这几个词元，位置在0-4这段有着不同的重叠。我们先来看 ik_max_word 的切分模式：执行文本的最细粒度分割，将分段详尽地生成各种可能的组合。来看下“中华人民共和国国歌”的例子，这里为了更加直观的体现字典树的匹配模式，我们把字典库的内容也列出来。ik_smart 的分词结果并不是 ik_max_word 的分词结果的子集。

首先通过refresh在内存中生成新的Segment段时，由于段数据是此时生成的，很容易确保段数据是有序的，此外在段合并的过程中涉及到端数据的重整，这时候也可以确保合并后的新段的数据是有序的。但是我们知道，Elasticsearch的Segment段数据是不可变的，这是为了写入的时候可以进行顺序写而提高磁盘的IO效率，同时可以提高段文件的缓存命中率，不至于一条数据被修改，整个段的数据缓存都要失效的情况。可以想象一个链表结构，如果需要确保它的有序性，在插入新数据的时候需要对链表节点进行移动。

"title":{"fields":{},},这里，为了验证分词，同时使用了ik_smart和ik_max两种分词。实际开发中不需要，因为：两种分词共存，会导致导入数据创建索引的时候，索引会非常大，对磁盘和检索性能都会有影响。

在使用 Elasticsearch 时，我们总有需要修改索引映射的时候，这时我们只能进行 _reindex。事实上，这是一个相当昂贵的操作，因为根据数据量和分片数量，完整复制一个索引可能需要几个小时。花费的时间不是大问题，但更严重的是，它会影响生产环境的性能甚至功能。相信大家都明白，数据迁移会消耗大量硬盘资源，肯定会影响性能，但功能呢？让我们以常规的 _reindex 为例。假设我们在索引上创建了一个别名。如果没有别名，我们就有大麻烦了。常规的reindex程序分为两个步骤。

ES集群规划及节点角色规划最佳实践

​早在 2022 年 2 月，当 Elasticsearch 8.0 发布时，Python 客户端也发布了 8.0 版本。它是对 7.x 客户端的部分重写，并带有许多不错的功能（如下所述），但也带有弃用警告和重大更改。今天，客户端的 7.17 版本仍然相对流行，每月下载量超过 100 万次，占 8.x 下载量的 ~50%。​根据我作为 urllib3 维护者的经验，我知道投资 urllib3 2.0 迁移指南 1 并帮助用户迁移是有回报的。

档，然后下次查询中会对之前已经返回的文档进行忽略过滤，同时在。

比如发送到节点的时间，节点本身的空闲资源情况等。这句话的大概意思是，bulk的index操作性能是高于单文档的index操作的。所以在大量重复id的情况下，会大量触发refresh操作，（不重复的情况就不会）产生很多小的segments，然后又触发很多segment merge操作。要理解其中的缘由，首先必须了解ES的update操作，是先get出来最新的文档，然后在内存里更新，最后再写回去。ES官方是建议在业务场景允许的情况下，尽量使用bulk操作来提高index的性能，官方文档是这么说的。

编辑器添加goproxy。

k1 : 控制非线性词频率归一化（饱和），Elasticsearch中默认值为1.2。用人能看懂的话说就是词语在文档中出现的次数对于得分的重要性。例如说我觉得在某些场景，一个搜索词在文档中出现越多则越接近我希望搜索的内容，就可以将这个参数调大一点。b ：控制文档长度对于分数的惩罚力度。变量b处于分母上，它乘以刚刚讨论过的字段长度的比值，Elasticsearch中的b 默认值为0.75。如果b较大，则文档长度相对于平均长度的影响更大。

从stackoverflow上查到，当Elasticsearch所在磁盘占用大于等于95%时，Elasticsearch会把所有相关索引自动置为只读。（Elasticsearch官方文档有介绍）发现确实这个索引的 read_only_allow_delete 属性是 true，由此导致了无法再向其中插入文档。建议采用第一种，注意解决之后，需要手动把被锁的索引的只读模式关闭。可是这个索引自从创建，从来也没有修改过配置，为什么忽然报错呢？看错误信息大意是要操作的索引是只读的，不能进行插入或删除。

基本查询有两种语法：左侧的简单语法，不能使用任何选项， 右边有一个扩展的。接收 true, false 或者设置一个固定的值，默认是 10000.查看索引信息（包括缓存大小，数据大小，分片在节点的分布，索引健康状态等）1. 32g以内，超过则jvm无法使用压缩指针，导致堆内存利用率变低。具有聚合、突出显示、过滤的完整搜索示例......，关于 Elastic 的重要内容来源;，快速启动任何 Elastic 软件;注意：只有部分舒心支持动态更新。创建文档（自动生成的 ID）手动刷新到OS cacche。

它可以存储一个计数 包含每个术语的文档，一个术语在特定术语中出现的次数 文档，每个文档中术语的顺序，每个文档的长度， 所有文档的平均长度等。文本字段中的每个单词都需要是可搜索的， 这意味着数据库需要能够在单个字段中索引多个值（在本例中为单词）。文档更新的工作方式与此类似：当文档更新时，旧的 文档的版本被标记为已删除，而新版本的 文档在新区段中编制索引。句段是不可变的，因此无法从较旧的句段中删除文档， 也无法更新较旧的句段以反映文档的较新版本。这样，新的 文档可以相对便宜地添加到索引中。

想象一下，我们有一个查询 will 的权重较低，而一个不常见的术语 like 将具有较高的权重。常用术语，如 或 contribute 与大多数文档相关的内容很少，因为它们出现在大多数文档中，而术语并不常见 喜欢或帮助我们放大最有趣的内容 文件。—— 处理向量的数学 - 提供用于比较向量的工具 多维向量之间的角度，这意味着我们可以将 上面对包含许多术语的查询解释的相同原则。时，我们实际上是在谈论 文档中的字段。每个字段都有自己的倒排索引，因此， 对于 TF/IDF 目的，字段的值是文档的值。

顾客可能会使用不同的关键词搜索相同的产品。例如，他们可能搜索“冰箱”或“冷藏库”。通过使用同义词，电商平台可以确保无论客户使用哪种术语，都能找到相关的产品。例如：“画匠、画工、画师”三个是同义词，“番茄，西红柿”是同义词......人们可能使用不同的关键词来描述或搜索同一事件或主题。例如，“COVID-19”、“冠状病毒”和“新型冠状病毒”都可能指向与疫情相关的文章。某特定新闻场景下，中文和英文要做同义词处理，举例：科学 和 science 是同义词，数据 和 data 是同义词.....

所有以下 cURL/API 请求都可以在 Elasticsearch Service >“API Console”（API 控制台）中作为 Elasticsearch API 的 cURL 发出，或者在 Kibana >“Dev Tools”（开发工具）下进行。如果这不是您第一次触发熔断器，或者您怀疑这会是一个持续存在的问题（例如，堆利用率持续保持在 85％，那么就是考虑扩展资源的时候了）；这部分内存最大不超过物理 RAM 的一半，如果您确认是这种情况，就需要考虑一下，要么扩展集群，要么减少对集群的需求。

自建的Elasticsearch集群，从8.0版本开始，也默认地简化了安全功能，为用户用户认证、基于角色的访问控制进行用户授权、使用 TLS 加密的节点到节点通信、使用 HTTPS 与 Elasticsearch API 进行加密通信。为什么我们需要进行如此的安全配置，并启用SSL/TLS对Elasticsearch的服务进行认证与通信加密？总的来说，将Elasticsearch集群配置为使用HTTPS和TLS可以提高数据的保护和安全性，对于任何要求数据保密性的场合，都是一个重要的安全措施。

ctx.href.url 如果非空且 ctx.href.url 以 http 开头，则：href.insecure 设置为：true。上面脚本是借助 ingest pipelie 实现：取子串内容，源串为：“hello world”，取出后的子串为：“hello”。update / update / update_by_query / reindex 场景，使用：ctx._source；如上实例，借助 painless 脚本实现了获取日期类型数据的年份，是借助 getYear( ) 的函数实现的。

使用Testcontainers测试Elasticsearch插件。

1. 需要一个搜索词库/语料库，不要和业务索引库在一起，方便维护和升级语料库2. 根据分词及其他搜索条件去语料库中查询若干条（京东13条、淘宝（天猫）10条、百度4条）记录返回3. 为了提升准确率，通常都是前缀搜索

【代码】Elasticsearch查询方法汇总。

原理上可以理解为前缀树，加速查询。我们已经知道在elasticsearch中每个shard每隔1秒都会refresh一次，每次refresh都会生成一个新的segment，按照这个速度过不了多久segment的数量就会爆炸，所以存在太多的segment是一个大问题，因为每一个segment都会占用文件句柄，内存资源，cpu资源，更加重要的是每一个搜索请求都必须访问每一个segment，这就意味着存在的segment越多，搜索请求就会变的更慢。到了极端的情况，写入速度很高的时候，40%都被占用，导致OOM。

先回顾几个概念：ES的Index是个逻辑概念，实际由若干shard组成，而shard就是Lucene的Index，即真正存储数据的实体。当有数据需要存储的时候，就需要先分配shard。具体来说需要分配shard的场景包括：数据恢复，主分片（primary）、副本分片的分配，再平衡（rebalancing），节点的新增、删除。对于分布式存储系统来说，数据的分布非常重要，ES shard的分配工作由ES的master节点负责。

⼀、分析器1.1概念：分析器包括：1. 字符过滤器(CharacterFilters)：⾸先，字符串按顺序通过每个 字符过滤器。他们的任务是在分词前整理字符串。⼀个字符过滤器可以⽤来去掉HTML，或者将 & 转化成 and；2. 分词器(Tokenizer)：字符串被 分词器 分为单个的词条。得到分词，标记每个分词的顺序或位置（⽤于邻近查询），标记分词的起始和结束的偏移量（⽤于突出显⽰搜索⽚段），标记分词的类型；

一直以来，ES 堆中常驻内存中占据比重最大是 FST，即 tip(terms index) 文件占据的空间，1TB 索引大约占用2GB 或者更多的内存，因此为了节点稳定运行，业界通常认为一个节点 open 的索引不超过5TB。现在，从 ES 7.3版本开始，将 tip 文件修改为通过 mmap 的方式加载，这使 FST占据的内存从堆内转移到了堆外由操作系统的 pagecache 管理。参考 ES 7.3 的 release-notes ：现在我们来聊一聊其中的一些细节。hybridfs。

Lucene 并不是为低延迟而设计的系统，查询毛刺主要受 GC 和 IO 的影响，GC 层面在于合理的规划JVM内存，避免频繁 GC 和 FGC，IO 层面的可以考虑使用 SSD，RAMDISK 或预留足够的 pagecache来解决。

当Elasticsearch所在磁盘占用大于等于95%时，Elasticsearch会把所有相关索引自动置为只读。不管使用哪种方式,解决后需要将read_only_allow_delete设置成null,索引才会恢复正常写入。上面的read_only_allow_delete为true说明索引进入了只读状态。如果使用9300的tcp端口会出现类似下面的错误。写入数据会在集群的日志文件中发现类似下面的错误。可以通过下面的api查看当前索引状态。

在此阶段需要注意的最重要的一点是，匹配的文档分为两个阶段。首先是一个 approximations的过程（找到近似匹配的doc），它可以有效地迭代倒排中与查询匹配的文档的超集（超集包含着不匹配的doc），是因为这些超集的迭代是通过 nextDoc / advance来操作的。但实际情况要复杂一些。如果您读了上面的求交集如何执行的描述，则会发现 nextDoc（）和 advance（target）的执行顺序是基于 cost（）决定的，而 matches（）的执行顺序是基于 matchCost（）决定的。