为什么不要使用elasticsearch

互联网上有很多文章，都在讲为什么要使用elasticsearch，却很少有人讲为什么不要使用elasticsearch。作为深入研究elasticsearch四年，负责公司万亿级别检索的操盘手，借着这篇文章，给大家分享一下，为什么不要使用elasticsearch。

一、不要使用的理由

1. 学习成本

elasticsearch的文档蛮多的，而且看一遍什么用都没有，而且看一遍的时间成本很长。但是多看几遍，绝对有用。“书读百遍其义自见”。

一个参数都要看好久，研究好久。关键还不一定能看出来，这参数有啥用。看明白了，还不一定对（有时候没看懂是好事，不会翻车）。这些要结合生产实践才有机会接触到，才有用。

做好es搜索，这条路，我已经走了四年，这已经是第五个年头了。前年定的flag，看完全部的源码，到现在还没有实现。仅仅看了冰山一∠。这四年看完了网上所有包含es优化的帖子。看了市面上有的全部的es的书籍。看了N遍官方文档。现在API都没记全，仅能做到，知道需要的时候去哪里找！

等我把es都看明白的时候，又发现，这些不够，底层数据结构，还有lucene这些。 es只是一个分布式壳子。于是一年又过去了，回头看，之前的那些似乎都忘了，仅有一点印象。等看完了lucene的底层原理，惊叹，wo c! 前辈为何如此聪明。绝了！只是又发现这才刚入门，顶多算精通es，才明白我是做es的，不是做搜索的。这就像，当你到达了一个山顶，才看到了更高的山峰。这个阶段，可以做到很好的使用es，可以去优化性能，可以得心应手的完成功能需求。但是想要在搜索这条路上走下去，还有更多的事情要做。query改写，意图识别，粗排，精排，这些优化召回质量的东西，像无底洞一样。

GTP火热后，RAG又是一个好的方向。

此外，es官方版本更新的很快。可能我们学习的速度赶不上更新的速度（当然有点夸张）

2. 需要场景

如果问：“你为什么不学，不想学这些？”

回答：“学了没用” ，这是真的，推动一个人进步的是需求。就像水涨船高一样，船的高度，是由水决定的。当然我们有选择海域的机会，但是不多。

我自己的经验来看，一开始做18亿数据的集群，我当时已经提升了数十倍了。我觉得自己很了不起。但是在现在看来（万亿量级搜索优化），真想承认当时的井底之蛙。还记得之后拿着这18亿数据优化经验，去面试同程，被虐的体无完肤，感受到当时面试官不想面下去的尴尬。当时我还想向他请教怎么优化，面试官并没有回答我，只说了一句好好看看文档。当时还有点不理解，确实浪费时间。当我今天面试别人的时候，我体会到了这一点。不过，我分享了自己的经验。所以任何时候不要妄自菲薄，别人能达到的高度，我们也能达到，只是时间问题。

也是机会巧合，接触到现在这家万亿级数据级的检索优化工作。但是这种需求量总是小的，能有多少家公司数据量有万亿? 同样，我做了两年了，query改写，意图识别这些召回相关的优化，我也没有做过。

是环境决定了我们的高度！是需求成就了我们，这是真的！

3. 集群成本

尽管Elasticsearch是一种功能强大、灵活且广泛使用的搜索和分析引擎，但它也存在一些潜在的挑战和限制。

都说es很快，检索首选es。但是作为过来人，Elasticsearch需要大量的内存、存储和计算资源来有效地运行。如果你的应用程序规模较小或资源受限，可能不适合使用Elasticsearch。

es是天然的分布式，很轻松hold住海量数据检索。但是代价是极其昂贵的，很多人优化搜索，第一想到的是堆机器，能用钱解决的问题都不是问题。一台服务器的成本至少在10W，一台服务器能高性的运行（保证写入和检索的性能），大概嫩挂载的数据在10T。这里可以算一下，假如数据是PB，想要扩一倍集群，成本是多少？大概一千万。从堆机器来解决优化的这条路，绝对不是通向罗马的那一条。

es能够保证检索速度，是很吃资源的！比如SSD磁盘是必备的，如果你很关注检索性能的话。我敢保证，钱花在SSD上绝对是值的。花一倍的钱去扩一倍机器，不如从HDD换成SSD。

那好下边再来聊聊从技术角度的优化成本。

4.技术复杂性

其实在第一点，学习成本上已经聊过了。 Elasticsearch是一个复杂的工具，需要深入理解其配置、管理和优化。团队没有足够的经验或资源来管理它，可能会导致性能下降或系统不稳定。一个小小的参数就能降低N倍性能，好不夸张。同样一个小小的参数也能提升N倍。

文档上有蛮多参数，可以考虑优化的，但是都需要时间去弄明白它。但是能不能用，在特大规模集群上使用，敢吗？

并且我觉得很多优化是藏才源码中的。像开好车，还真得打开引擎盖看一看。

此刻，折腾的第五年，我可能还停留在不知道我不知道的阶段。选择做es搜索，这就是一条不归路。大把的时间，大把的头发都要花掉。

5.维护难度

Elasticsearch需要定期维护和更新以确保安全性和性能。如果团队缺乏必要的专业知识或时间来进行维护，可能会面临安全漏洞或性能问题。即使有着丰富经验的人，也会经常翻车。

其实在大体量数据下，很多问题都会放大。假如数据有100G，重做升级一下，也就是两天的时间。但是PB级别的数据，怎么调整呢，怎么业务无感知呢？通常很多问题，确实可以通过升级版本来解决。但是船大不好掉头，这也是真的。

人工成本蛮高的！es想要运行的快，需要对es领域有深入研究的专精人员。才可以。

这里给大家分享几个case：

在6.X之前的版本中，在大体量数据下，会有堆空间不足的问题。这在7.X版本可以得到很好的缓解。因为官方做了源码的改动，把FST从堆内挪到了堆外。

在7.X版本中，仍然会遇到堆空间不足的问题。字节的同学了一个lucene的bug。因为threadlocal的原因，无法释放堆空间。随着索引变多，检索次数变多，堆可用空间越来越少。这会让检索莫名其妙的变慢。多少人还处于水生火热之中，天天慢查询报警，不知所措。这一问题在8.X得到了解决。

还有一个问题，在低版本中（ 7.16 之前）。无法通过后天命令关闭聚合分析任务。这对熔断非常不友好。很多次节点打挂，都是聚合分析请求导致的。

总之运维很头疼，想做好更头疼。想好了嘛？还要用es嘛？

6. 鱼和熊掌不可兼得

像mysql，数据量大于300w就会变慢了。 es确实有非常好的查询能力，非常好的写入能力。但这都是有代价的，由底层数据结构决定。例如这些没有的能力：

mapping不可改，不能改index属性

根本原因是因为它是日志合并树的概念，无法对已经写入的数据做修改（改字段）。官方文档中介绍了几种修改mapping的方法。一个是新建一个字段，程序中所有地方修改名字，这对于复杂的项目容易出错，而且无法保留原来的数据；另一个是利用aliaa创建一个新的索引，但是所有数据需要重新导入，这需要很长时间，操作性不强。

无法多对多

Elasticsearch中提供3中关联关系，Field collapsing（严格来说不是关联），Nested object，Parent-child。前两种都是直接将一个mapping声明在另一个mapping中，第三种关联是在创建子文档是指明他的父文档，但是一个子文档只能有一个父文档，因此也不能实现多对多的关联。其实如果理解了ES的目的是提升检索效率，就不难理解为什么没有多对多关联了，在关系数据库里这就是个效率瓶颈。

es无法做多表查询，父子关联查询，性能是极低的。只能考虑大宽表解决。

es没有事务

对事务有要求的，则需要自己实现。