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

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

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

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

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

guanlinzhang1996

2021-11-20 21:52:16 +08:00

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

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