Elasticsearch 在未来会全面替代传统的关系型数据库吗？使用上有什么坑吗？
source link: https://www.v2ex.com/t/816686
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
被业务每日新增的数据量所困扰，花了两个小时大概了解了一下 es ，感觉这个东西 [似乎] 可以完全替代关系型数据库的业务。也就是当完全不讨论它的设计初衷，即全文搜索的应用领域，单纯地考虑 es 替代 sql 储存关系型数值数据，似乎看起来也不错？
目前看来的优势： 1 、虽然声称是 nosql ，确实也是不支持 sql ，但是与 redis 等 nosql 不同，es 仍然可以进行一些包含关系型逻辑的搜索。这满足了日常业务的最低档条件。 2 、号称速度很快，全文搜索速度毋庸置疑，如果单纯拿来存数据的话，我没有测试过，不知道速度。 3 、横向扩展的便利性非常香，横向扩展方便不得不说是今天一个太大的优势了。点名批评 oracle ，可能是我笨，真的觉得集群学起来好费劲。 4 、数据库本身，以及工具链的安装非常友好。我本身 java 只能写 helloworld ，但是大概搜了搜直接官网和 github 下了几个工具感觉就完全能用了，初见的低成本令人心旷神怡。与之相对的，传统关系型数据库，比如某甲骨文，安装过程和工具链都给人一种沉重的感觉。
目前了解的缺点： 1 、不支持事务。这个不是大问题，我司事务基本靠业务端解决，不加给数据端。应该很多公司都这么操作，毕竟事务本身有局限性。 2 、权限管理很垃圾，这个是痛点之一，不过感觉大多数业务场合，靠前端中间件的话，也未必不是不能凑合？ 3 、性能提升主要吃内存，落盘会让性能下降。这个我没测试过不了解。
总之目前是在考虑要不要尝试迁移，迁移目的是为了追求更高的插入性能和更低的搜索延迟，mysql 进行分库分表+集群各种优化后，数据量太庞大的情况下搜索延迟还是不尽如人意，之前尝试过 oralce 感觉学习成本太高，也没有质变级提升，这次 es 确实让人眼前一亮，不过既然主流工业界没有这么做，也许还存在一些坑也说不定，比如存在数据被污染问题？数据流偶尔缺失问题？更新时效性不足的问题？或者无法处理并发修改的种种问题？有没有踩过坑的大佬讲一讲如何，还有未来发展趋势。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK