如何做搜索？如何做搜索优化？如何在搜索领域快速成长？

一、知识方向

1.1 倾向于技术细节，底层原理。

? 每个API最好都能深度了解其底层原理。多去看看源码。古人云知彼知己方能百战不殆。在你深入了解以后，才能知道它为什么快，又为什么慢，它的瓶颈在哪里，它适用哪些场景。其中优秀的设计思想，和巧妙的代码逻辑，可以让我们学习，提升自己的代码能力。其不足的点，也可以作为未来可提升可改造的点。

1.2 ES中的底层数据结构

? ?万物皆有根，在程序设计中，数据结构就是底层的基石。数据结构完全决定了性能。先去了解底层的数据结构，才能更好的去做优化。业务逻辑上100行优化，抵不上底层数据结构的1行优化。这里举个简单的例子。es中有keyword类型，和long类型。只有在了解了底层数据结构以后，就会知道，long类型在底层是用BKD树维护的。keyword类型会走倒排表。根据数据结构的特点特性我们很清楚，假如是做排序，或者范围查询，自然而然是BKD树更好一些。假如是做精准点查询（也就是term精准查询），那肯定是keyword更合适一些，走倒排表，走内存加速。特别是在大量查询的情况下，效果会更加明显。由于文章篇幅的原因，这里就不做过多的介绍了。仅作为抛转引玉把！

1.3 ES中的读写源码原理

（可扩展，任意源码模块，例如集群管理模块、滚动查询模块）（不仅仅是Elasticsearch源码，?更有Lucene源码）

? ?我反复推荐去从源码中获取答案。去研究研究源码，可以提升我们的应变能力。在源码中，我们可以找到很多问题的最佳解。这里还是举个例子，在工作中做过最多的优化，肯定是查询和写入优化。可是如何去真正的做优化呢？从网上看看别人的经验贴？纸上得来终觉浅，绝知此事要躬行。不如自己去源码中了解原理。问题便能迎刃而解。例如，从Lucene源码和es源码中去看查询原理。我们能够知道在查询流程中，检索是检索在实际上发生在数据节点，分为两个阶段，第一个阶段是query，第二个阶段是将数据取回。数据节点获取数据后汇集给协调节点。（这些内容可能网上大部分经验贴中都有。但是我看过网上所有的关于这方面的帖子，没有人说，查询在lucene中最后是落在段上的。在源码中，查询多个段，是串行的。也就是段越多，查询排队的时间越长。此外在es中，一个请求，在一个节点上的查询分片的并发度是5，假如查询涉及的分片，在一个节点上的分布大于5，则需要一次排队。这将大大增加查询延迟。如果是做搜索优化的，可能看到这里，自己心中便已有了优化的方法。如何能不让它排队呢？如何对es掌握较深的话，其实就一个参数。

GET index-000010/_search?max_concurrent_shard_requests=10

这样就可以调整不用排队了。这时候又要去想想，这么调整，会有什么风险呢？实际调整完，发现并没有什么提升是怎么回事？（这里实际上又涉及到了es search 线程池的问题，底层CPU资源的问题。假如CPU不多，查询又多，线程池都被占用了，这里再怎么调整，都是无效的）此外，上边有提到，在段上的查询是串行的。想要提升检索性能，是不是可以通过减少段数？那如何减少段呢？es还是有提供API，就是forceMerge。这个又是怎么用的呢，有什么风险？这里就不再展开了。希望小伙伴们接着去探索。内容太多了，我无法全讲出来。

? 这里再抛砖引玉一下，除了我上述提到的参数，还有哪些可以优化呢？

1.3 ES各版本新特性，与性能提升

? es不仅是一个非常出色的搜索引擎。而且它还是一个社区，非常活跃的社区成员特出各种各样的优化思路。lucene和es都在这样的优化建议的给养下，飞速的发展，快速的更新。拥抱开源的力量，切勿闭门造车，感受开源的力量，应用开源的力量。

? ?es的版本更新非常快。多则一个月，少则一周，就是一个小版本。多去看看都更新了些什么。总是有好处的。因为你在这个版本头痛的问题，无解的问题，说不一定在下一个版本，就得到官方的解决了。一个搜索场景的优化，你在逻辑上优化了半天，效果捉襟见肘。往往官方的一次改动，很就是很大幅度的提升。

1.4 Lucene底层数据维护方式

? 说白了。es是一个出色的天然分布式的壳子。lucene才是底层处理检索逻辑的核心。es中经常说的分片，其实就是一个lucene实例。

? 索引在es源码中，其实只能这个壳子是如何包装这个流程的。光是这个壳子，已经非常出色了。说起搜索引擎，可能很多人都能说出来es。但是很少人能说出来lucene。

? 作为一个数据库引擎，底层的实现细节，都在lucene中。数据究竟是如何维护的？如何存储的？什么设计思想，什么逻辑？我个人反反复复看了很多次lucene，从看不懂，到恍然大悟，原来是这样。再到拍案叫绝，原来还可以这么干。我们要善于站在巨人的肩膀上，继续前行。前提是爬上伟人的肩膀。

? ?说了这么多，还是去看看lucene源码吧。一开始可以先看看别人写的解析文章。慢慢的自己去理解源码。

1.5 如何编译源码，在源码上做改造

? 自己动手编译一下源码。是第一步。

1.6 Es源码结构

?内容太多，暂不整理。这里提一下，GPT这么强，应该把它作为工具，来辅助理解和学习源码。

二、优化方向

2.1 ES集群参数优化（上百个实战参数）

? 这里可以看我这篇文章。这是我的生产实践经验。

几千亿级集群管理，近百个实用优化参数，涵盖集群、索引、客户端-CSDN博客

2.2 ES?访问ES，代码优化、参数优化（从底层讲参数优化）

?? 这里可以看我这篇文章。

几千亿级集群管理，近百个实用优化参数，涵盖集群、索引、客户端-CSDN博客

2.3 分词器优化方案，满足更多搜索场景，提升召回率

? 这块内容很多，未来单独出一篇文章，来介绍分词器优化。这里简单提一下，通过优化分词器，可以解决30%以上的搜索召回问题！

2.4 数据写入优化

? 这里看我这一篇文章。

关于elasticsearch的极限写入优化问题-CSDN博客

2.5 检索性能优化（有专利）

? 这个这里先不写了。专利还在受理。还未进入公布阶段。等公布了再分享。敬请期待。

? 这里是我写的搜索优化的专栏，该专栏中包含了几十篇，生产优化的经验。

https://blog.csdn.net/star1210644725/category_12341074.html?spm=1001.2014.3001.5482

? 下边的专栏，包含了100多篇elasticsearch搜索相关的原创文章。

https://blog.csdn.net/star1210644725/category_9654555.html

2.6 聚合分析性能优化

? 这里看我这一篇文章。

ES通过抽样agg聚合性能提升3-5倍-CSDN博客

2.7 BM25相关性算法与优化

?参看我这篇文章

白话ES搜索相关性问题_es tie_breaker-CSDN博客

2.8 排序优化——提升召回效果

? 敬请期待，后面会整理文章。

2.9 脚本排序性能优化

??敬请期待，后面会整理文章。

2.10 底层数据存储优化（索引设计优化）

??敬请期待，后面会整理文章。

2.11 集群分片平衡优化（有专利）

? es是一个分布式搜索引擎。在分布式中，由于数据分布不均匀问题，会产生短板效应，或者说长尾效应。在实际的生产中，我们之前会经常出现，几百个节点中，仅有部分节点负载高。

? 可在国家专利网站上根据名称搜索：?数据分片调整方法、装置、设备及可读存储介质

https://pss-system.cponline.cnipa.gov.cn/retrieveList?prevPageTit=changgui

下边的内容，后续会陆续不断的整理。

三、方案方向

要不要选择使用ES——ES中的利与弊

最佳集群规划方案

最佳机器配置方案

最佳性能测试方案

最佳数据治理方案

最佳数据架构方案

最佳参数优化方案

最佳集群写入方案

最佳集群查询方案

最佳数据迁移方案

最佳集群监控方案

最佳自动化运维方案

集群降本增效方案

抉择本地化还是上云

使用ES打造私有AI搜索

语义检索方案

跨模态检索方案

四、经验分享

万亿级数据治理优化分享

万亿级数据集群遇到的生产问题

五、搜索产品化

如何打造搜索中台，减少搜索在集团内部的重复开发工作，建设低代码开发平台。