Elasticsearch 在未来会全面替代传统的关系型数据库吗？使用上有什么坑吗？

[LeeReamond]

被业务每日新增的数据量所困扰，花了两个小时大概了解了一下 es ，感觉这个东西 [似乎] 可以完全替代关系型数据库的业务。也就是当完全不讨论它的设计初衷，即全文搜索的应用领域，单纯地考虑 es 替代 sql 储存关系型数值数据，似乎看起来也不错？

目前看来的优势： 1 、虽然声称是 nosql ，确实也是不支持 sql ，但是与 redis 等 nosql 不同，es 仍然可以进行一些包含关系型逻辑的搜索。这满足了日常业务的最低档条件。 2 、号称速度很快，全文搜索速度毋庸置疑，如果单纯拿来存数据的话，我没有测试过，不知道速度。 3 、横向扩展的便利性非常香，横向扩展方便不得不说是今天一个太大的优势了。点名批评 oracle ，可能是我笨，真的觉得集群学起来好费劲。 4 、数据库本身，以及工具链的安装非常友好。我本身 java 只能写 helloworld ，但是大概搜了搜直接官网和 github 下了几个工具感觉就完全能用了，初见的低成本令人心旷神怡。与之相对的，传统关系型数据库，比如某甲骨文，安装过程和工具链都给人一种沉重的感觉。

目前了解的缺点： 1 、不支持事务。这个不是大问题，我司事务基本靠业务端解决，不加给数据端。应该很多公司都这么操作，毕竟事务本身有局限性。 2 、权限管理很垃圾，这个是痛点之一，不过感觉大多数业务场合，靠前端中间件的话，也未必不是不能凑合？ 3 、性能提升主要吃内存，落盘会让性能下降。这个我没测试过不了解。

总之目前是在考虑要不要尝试迁移，迁移目的是为了追求更高的插入性能和更低的搜索延迟，mysql 进行分库分表+集群各种优化后，数据量太庞大的情况下搜索延迟还是不尽如人意，之前尝试过 oralce 感觉学习成本太高，也没有质变级提升，这次 es 确实让人眼前一亮，不过既然主流工业界没有这么做，也许还存在一些坑也说不定，比如存在数据被污染问题？数据流偶尔缺失问题？更新时效性不足的问题？或者无法处理并发修改的种种问题？有没有踩过坑的大佬讲一讲如何，还有未来发展趋势。

[njitzyc]

这跟数据库差太远了把。。。

[dayeye2006199]

应用领域不同不要强行上啊。。

[medivh]

"1 、不支持事务。这个不是大问题，我司事务基本靠业务端解决，不加给数据端。应该很多公司都这么操作，毕竟事务本身有局限性。"，“之前尝试过 oralce 感觉学习成本太高，也没有质变级提升”

你的问题在于看到太少想得太多

[Ariver]

从 mysql 到 oracle 都觉得学习成本太高的话，到 es 的成本......

[zjsxwc]

es 性能差，单机运行时间长还容易崩溃，楼主你确定？

[ospider]

把自己在知乎上的回答搬运一下：

> 我们组还真有一个小应用完全用 ES 做存储，那叫一个坑爹。

> 对于小型应用，虽然性能不是问题，但是一样蛋疼。

> 1. ES 没有 ORM ，所以的代码里基本上就是查询的 JSON Query 满天飞，非常乱不说，还容易出错。
> 2. 对于很简单的 SQL 操作，ES 也没有很好的操作方式。比如说 select * from xxx 这么简单的操作，ES 是不支持的。ES 最多返回 10000 条数据，所以你必须自己用 cursor 封装一个读取的操作才能获取所有数据。
> 3. ES 也不是一个很好的文档数据库，对于数组的 append 操作并不直接支持，需要很复杂的操作。

> ES 本质上是一个倒排索引加上半吊子的 MongoDB ，虽然用作全文索引非常优秀，但是直接当做主库用还是欠缺不少支持的。

https://www.zhihu.com/question/45510463/answer/2070577256

[corningsun]

"迁移目的是为了追求更高的插入性能和更低的搜索延迟，mysql 进行分库分表+集群各种优化后，数据量太庞大的情况下搜索延迟还是不尽如人意"

如果真有这么大数据量，还是先关注下 ES 的成本。

[jianjian714]

专工专用，es 就做一些模块的搜索就挺好；如果大数据那就需要考虑使用大数据相关数据库，如：HBase ； mysql 做好分库分表，冷热数据，几亿数据也问题不大

[strawberryBug]

@ospider 关于第一点，es 官方提供封装好的客户端，rest high level client ，代码构建查询语句，不太容易出错。

append 可以尝试使用 script+update by query 。

我司算是深度使用 es ，比较头疼的是事务多一点😂

[totoro52]

好家伙你想 es 替代关系型数据库？ 等你真正用上 es 再说吧，那玩意坑多到你害怕，光一个索引延迟这个就能把你整死，我们公司的业务 es 只负责查，其它均采用 mysql ，数据同步一份宽的到 es ，并且 es 官方自身的产品定义是搜索引擎而非数据库

[totoro52]

不要想着去用什么替代什么，而是两者互补

[danhahaha]

mysql 可以在 128M 内存跑起来，es 至少得 4G

绝大多数公司用不到

[chihiro2014]

用它来和 mysql 做异构查询倒是可以

[huage]

不可能广泛使用，术业有专攻，将不同的软件和技术用到一起的集大成者才是王道

[guangming3055]

es 主要还是用来搜索的，一对多还好 多对多关系根本没法处理

[skinny]

别接触一个“新”东西就觉得这是未来，太幼稚了

[sadfQED2]

你知不知道 es 的索引刷新有延迟？别说事物，就这一点就不可能替代。而且 es 也不是关系数据库的替代品，es 和关系数据库是互补关系才对

[hronro]

而且 ES 似乎是不能跨 Index 查询数据的，这点就可以劝退很多人了

[adoal]

对于在典型的事务型业务系统里都不肯（或者不会）用关系数据库的特性而只是当一个数据表存储来读写的互联网大厂架构师的孝子贤孙们来说，真的是没有比关系数据库更差劲的数据存储系统了。

[C603H6r18Q1mSP9N]

可以两边都跑一段时间，看下效果呗；
现有 mysql 继续跑着，es 也上一份，看下能不能满足需要

[likeunix]

我觉得 es 的查询语法很难受

[ospider]

还有最重要的一点，ElasticSearch 现在的 License 在大公司已经没法用了……

[ffxrqyzby]

如果事务不是主要考虑的因素, lz 可以试一试

[cs419]

未来会替代...
术业有专攻 他俩赛道都不同啊
再说 solr mongodb mariadb tidb 这些都是路人甲么

[lyz1990]

缓缓打出一个问号

[neochen13]

不是有个 clickhouse

[xjlnjut730]

坑可就太多了，关联查询、事务、写入后不能保证立即读，CRUD 场景基本都不太能替代。而且 ES 的运维成本非常高，集群动不动就 green/yellow ，需要花很多精力在上面。我感觉就适合大数据情况下单表分页、模糊搜索、推荐、缓存等场景。

[xjlnjut730]

还有，更新性能极差。

[gamexg]

以前使用时，发现一些聚合函数返回的值是不准确或是估算值。业务上面是否可以接受？

[terranboy]

“存“关系不方便 就用来“查”的东西

[Mithril]

@ospider 看业务类型，非云服务供应商的话 SSPL 也可以用的。

@adoal 确实，搞不定事务怪不能横向扩展就完了。

[guanlinzhang1996]

现在一个应用系统都是专事专干。要是要事务，就用关系型数据库，想要 NoSQL ，用 MongoDB ，或者 DynamoDB
Elasticsearch 的 refresh 和 merge 等操作的原因被称为准实时分布式搜索引擎，系统设计考虑可用性 > 准确性。Elasticsearch 主要关注大规模数据的查询，聚合，按照查找关键字对查询结果进行相关性排序
对于搜索引擎，丢一篇文档，少一篇文档其实前端感知不明显

ES 常见场景：网站搜索引擎，应用运行状态分析(SIEM)，实时数仓(这一功能逐渐被 ClickHouse 等取代)

[deplivesb]

为啥楼主会拿 es 和关系数据库比较？这俩完全就不是一个东西吧，人家 es 官方自己也没说自己是个数据库啊，而且就索引延迟这一点你觉得适合作一般的关系数据库么？

[fuxkcsdn]

es 支持 sql 语法，虽然很多 sql 特性不支持，也不支持跨索引查询
我司当时选择上 es （主要用来聚合查询，常规查询还是走 mysql ），很大程度是因为 es 支持 sql 语法
当然，现在得为过去的偷懒买单了

[qq1340691923]

@hronro 多个 index 设置相同的别名，然后查询别名

[holinhot]

数据延迟怎么解决？ 写入的数据要过一会儿才有结果