三年多的搜索研发经历，万亿级集群管理经历，集群优化搜索优化经历。将生产环境的集群，检索性能提升了数十倍。也遇到过大大小小的生产事故。在工作中有幸能够得到前谷歌中国首席架构陈老师的指导。在搜索方面，自己也积累了蛮多的经验。
在篇文章中，先粗略的分享一下，在搜索方面，在使用elasticsearch做搜索方面，应该有哪些知识储备。如何做搜索？如何做好的搜索？如何提升性能。
想要做好搜索，底层知识一定要扎实。在我看来，首先是es都有哪些功能，都提供了哪些API，是第一层。只有对es了解的面面俱到以后，才能写好功能需求，来什么需求都能处理，这时候可以做个出色的开发工程师。但是想要做搜索工程师，还是远远不够的，这时候至少要根据我本篇文章所提到的包含的知识方向、优化方向等内容，包含源码方面，都有深入的了解。才能去做优化优化，才能做好搜索。剩下的是长时间的积累，最好的成长来源于生产实践。当然，在大规模数据检索场景下，才会暴露更多问题，面临更多挑战。剩下的就是深度钻研，不断的解决生生产中的挑战。诸如万亿级数据检索秒级响应的需求，超大规模中的集群管理，稳定性保障。生产环境中遇到的堆空间不足等挑战。
想好做好搜索，需要日积月累（大概需要1w个小时把）。需要大量的知识储备，需要大量的学习，调研，包括测试验证。最终才能做好。
最后，大家如何有更好的搜索优化建议，可以传授给我，将不胜感激。大家有任何搜索相关方面的问题，都可以私聊我，进行讨论。我会毫无保留的和你交流我的经验。目标只有一个，把搜索做好，把我的搜索做好，把大家的搜索做好。
每个API最好都能深度了解其底层原理。多去看看源码。古人云知彼知己方能百战不殆。在你深入了解以后，才能知道它为什么快，又为什么慢，它的瓶颈在哪里，它适用哪些场景。其中优秀的设计思想，和巧妙的代码逻辑，可以让我们学习，提升自己的代码能力。其不足的点，也可以作为未来可提升可改造的点。
这里有一些这两年整理的学习资料。感兴趣，可以学习学习
elasticsearch两年学习资料整理分享
万物皆有根，在程序设计中，数据结构就是底层的基石。数据结构完全决定了性能。先去了解底层的数据结构，才能更好的去做优化。业务逻辑上100行优化，抵不上底层数据结构的1行优化。这里举个简单的例子。es中有keyword类型，和long类型。只有在了解了底层数据结构以后，就会知道，long类型在底层是用BKD树维护的。keyword类型会走倒排表。根据数据结构的特点特性我们很清楚，假如是做排序，或者范围查询，自然而然是BKD树更好一些。假如是做精准点查询（也就是term精准查询），那肯定是keyword更合适一些，走倒排表，走内存加速。特别是在大量查询的情况下，效果会更加明显。由于文章篇幅的原因，这里就不做过多的介绍了。仅作为抛转引玉把！
这里可以看看我写过的几篇文章。
Es底层查询原理、数据结构、及性能分析_es数据结构
Elasticsearch 存储原理-lucene底层数据结构_es底层存储结构
深入解析什么是LSM-Tree_lsm tree
关于es中聚类 与 Doc Values 与 列式存储问题_es列式存储
（可扩展，任意源码模块，例如集群管理模块、滚动查询模块）（不仅仅是Elasticsearch源码， 更有Lucene源码）
我反复推荐去从源码中获取答案。去研究研究源码，可以提升我们的应变能力。在源码中，我们可以找到很多问题的最佳解。这里还是举个例子，在工作中做过最多的优化，肯定是查询和写入优化。可是如何去真正的做优化呢？从网上看看别人的经验贴？纸上得来终觉浅，绝知此事要躬行。不如自己去源码中了解原理。问题便能迎刃而解。例如，从Lucene源码和es源码中去看查询原理。我们能够知道在查询流程中，检索是检索在实际上发生在数据节点，分为两个阶段，第一个阶段是query，第二个阶段是将数据取回。数据节点获取数据后汇集给协调节点。（这些内容可能网上大部分经验贴中都有。但是我看过网上所有的关于这方面的帖子，没有人说，查询在lucene中最后是落在段上的。在源码中，查询多个段，是串行的。也就是段越多，查询排队的时间越长。此外在es中，一个请求，在一个节点上的查询分片的并发度是5，假如查询涉及的分片，在一个节点上的分布大于5，则需要一次排队。这将大大增加查询延迟。如果是做搜索优化的，可能看到这里，自己心中便已有了优化的方法。如何能不让它排队呢？如何对es掌握较深的话，其实就一个参数。
这样就可以调整不用排队了。这时候又要去想想，这么调整，会有什么风险呢？实际调整完，发现并没有什么提升是怎么回事？（这里实际上又涉及到了es search 线程池的问题，底层CPU资源的问题。假如CPU不多，查询又多，线程池都被占用了，这里再怎么调整，都是无效的）此外，上边有提到，在段上的查询是串行的。想要提升检索性能，是不是可以通过减少段数？那如何减少段呢？es还是有提供API，就是forceMerge。这个又是怎么用的呢，有什么风险？这里就不再展开了。希望小伙伴们接着去探索。内容太多了，我无法全讲出来。
这里再抛砖引玉一下，除了我上述提到的参数，还有哪些可以优化呢？
此外这里是我写过的文章。
es 读流程源码解析
ES indexSort 原理源码解析_es排序原理
elasticsearch DSL部分 源码解析_elasticsearch dsl解析模块
es不仅是一个非常出色的搜索引擎。而且它还是一个社区，非常活跃的社区成员特出各种各样的优化思路。lucene和es都在这样的优化建议的给养下，飞速的发展，快速的更新。拥抱开源的力量，切勿闭门造车，感受开源的力量，应用开源的力量。
es的版本更新非常快。多则一个月，少则一周，就是一个小版本。多去看看都更新了些什么。总是有好处的。因为你在这个版本头痛的问题，无解的问题，说不一定在下一个版本，就得到官方的解决了。一个搜索场景的优化，你在逻辑上优化了半天，效果捉襟见肘。往往官方的一次改动，很就是很大幅度的提升。
这里是我近两年来整理的 7.X版本和8.X版本的新特性。
elasticsearch 7.X全部版本的新特性与重大变化_elasticsearch7新特性
ES 8.x新特性一览(完整版)_elasticsearch 新特性
说白了。es是一个出色的天然分布式的壳子。lucene才是底层处理检索逻辑的核心。es中经常说的分片，其实就是一个lucene实例。
索引在es源码中，其实只能这个壳子是如何包装这个流程的。光是这个壳子，已经非常出色了。说起搜索引擎，可能很多人都能说出来es。但是很少人能说出来lucene。
作为一个数据库引擎，底层的实现细节，都在lucene中。数据究竟是如何维护的？如何存储的？什么设计思想，什么逻辑？我个人反反复复看了很多次lucene，从看不懂，到恍然大悟，原来是这样。再到拍案叫绝，原来还可以这么干。我们要善于站在巨人的肩膀上，继续前行。前提是爬上伟人的肩膀。
说了这么多，还是去看看lucene源码吧。一开始可以先看看别人写的解析文章。慢慢的自己去理解源码。
自己动手编译一下源码。是第一步。
内容太多，暂不整理。这里提一下，GPT这么强，应该把它作为工具，来辅助理解和学习源码。
elasticsearch源码结构一览_elasticsearch 源码
借助chatGPT强大的源码理解能力，来快速学习elasticsearch 7.11.1整体源码结构（用chatGPT学源码太香了）
想优化ES检索，先了解底层Lucene，Lucene源码结构一览_lucene 源码解析
这里可以看我这篇文章。这是我的生产实践经验。
几千亿级集群管理，近百个实用优化参数，涵盖集群、索引、客户端
这里可以看我这篇文章。
几千亿级集群管理，近百个实用优化参数，涵盖集群、索引、客户端
这块内容很多，未来单独出一篇文章，来介绍分词器优化。这里简单提一下，通过优化分词器，可以解决30%以上的搜索召回问题！
这里看我这一篇文章。
关于elasticsearch的极限写入优化问题
这个这里先不写了。专利还在受理。还未进入公布阶段。等公布了再分享。敬请期待。
这里是我写的搜索优化的专栏，该专栏中包含了几十篇，生产优化的经验。
下边的专栏，包含了100多篇elasticsearch搜索相关的原创文章。
这里看我这一篇文章。
ES通过抽样agg聚合性能提升3-5倍
参看我这篇文章
白话ES搜索相关性问题_es tie_breaker
敬请期待，后面会整理文章。
敬请期待，后面会整理文章。
敬请期待，后面会整理文章。
es是一个分布式搜索引擎。在分布式中，由于数据分布不均匀问题，会产生短板效应，或者说长尾效应。在实际的生产中，我们之前会经常出现，几百个节点中，仅有部分节点负载高。
可在国家专利网站上根据名称搜索： 数据分片调整方法、装置、设备及可读存储介质
https://pss-system.cponline.cnipa.gov.cn/retrieveList?prevPageTit=changgui
下边的内容，后续会陆续不断的整理。
要不要选择使用ES——ES中的利与弊
最佳集群规划方案
最佳机器配置方案
最佳性能测试方案
最佳数据治理方案
最佳数据架构方案
最佳参数优化方案
最佳集群写入方案
最佳集群查询方案
最佳数据迁移方案
最佳集群监控方案
最佳自动化运维方案
集群降本增效方案
抉择本地化还是上云
使用ES打造私有AI搜索
语义检索方案
跨模态检索方案
万亿级数据治理优化分享
万亿级数据集群遇到的生产问题