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

2021-11-20 04:08:23 +08:00
 LeeReamond

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

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

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

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

6478 次点击
所在节点    Elasticsearch
36 条回复
njitzyc
2021-11-20 04:13:57 +08:00
这跟数据库差太远了把。。。
dayeye2006199
2021-11-20 04:34:43 +08:00
应用领域不同不要强行上啊。。
medivh
2021-11-20 05:31:30 +08:00
"1 、不支持事务。这个不是大问题,我司事务基本靠业务端解决,不加给数据端。应该很多公司都这么操作,毕竟事务本身有局限性。",“之前尝试过 oralce 感觉学习成本太高,也没有质变级提升”

你的问题在于看到太少想得太多
Ariver
2021-11-20 08:05:32 +08:00
从 mysql 到 oracle 都觉得学习成本太高的话,到 es 的成本......
zjsxwc
2021-11-20 08:27:09 +08:00
es 性能差,单机运行时间长还容易崩溃,楼主你确定?
ospider
2021-11-20 08:27:51 +08:00
把自己在知乎上的回答搬运一下:

> 我们组还真有一个小应用完全用 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
2021-11-20 08:52:02 +08:00
"迁移目的是为了追求更高的插入性能和更低的搜索延迟,mysql 进行分库分表+集群各种优化后,数据量太庞大的情况下搜索延迟还是不尽如人意"

如果真有这么大数据量,还是先关注下 ES 的成本。
jianjian714
2021-11-20 09:06:06 +08:00
专工专用,es 就做一些模块的搜索就挺好;如果大数据那就需要考虑使用大数据相关数据库,如:HBase ; mysql 做好分库分表,冷热数据,几亿数据也问题不大
strawberryBug
2021-11-20 09:43:15 +08:00
@ospider 关于第一点,es 官方提供封装好的客户端,rest high level client ,代码构建查询语句,不太容易出错。

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

我司算是深度使用 es ,比较头疼的是事务多一点😂
totoro52
2021-11-20 09:53:34 +08:00
好家伙你想 es 替代关系型数据库? 等你真正用上 es 再说吧,那玩意坑多到你害怕,光一个索引延迟这个就能把你整死,我们公司的业务 es 只负责查,其它均采用 mysql ,数据同步一份宽的到 es ,并且 es 官方自身的产品定义是搜索引擎而非数据库
totoro52
2021-11-20 09:55:36 +08:00
不要想着去用什么替代什么,而是两者互补
danhahaha
2021-11-20 09:57:13 +08:00
mysql 可以在 128M 内存跑起来,es 至少得 4G

绝大多数公司用不到
chihiro2014
2021-11-20 10:24:36 +08:00
用它来和 mysql 做异构查询倒是可以
huage
2021-11-20 11:26:15 +08:00
不可能广泛使用,术业有专攻,将不同的软件和技术用到一起的集大成者才是王道
guangming3055
2021-11-20 11:29:24 +08:00
es 主要还是用来搜索的,一对多还好 多对多关系根本没法处理
skinny
2021-11-20 11:53:40 +08:00
别接触一个“新”东西就觉得这是未来,太幼稚了
sadfQED2
2021-11-20 12:18:45 +08:00
你知不知道 es 的索引刷新有延迟?别说事物,就这一点就不可能替代。而且 es 也不是关系数据库的替代品,es 和关系数据库是互补关系才对
hronro
2021-11-20 12:46:42 +08:00
而且 ES 似乎是不能跨 Index 查询数据的,这点就可以劝退很多人了
adoal
2021-11-20 12:47:21 +08:00
对于在典型的事务型业务系统里都不肯(或者不会)用关系数据库的特性而只是当一个数据表存储来读写的互联网大厂架构师的孝子贤孙们来说,真的是没有比关系数据库更差劲的数据存储系统了。
shanghai1998
2021-11-20 12:53:55 +08:00
可以两边都跑一段时间,看下效果呗;
现有 mysql 继续跑着,es 也上一份,看下能不能满足需要

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/816686

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX