ElasticSearch和普通数据库存储

最新推荐文章于 2025-01-09 19:33:11 发布

mark_59747688

最新推荐文章于 2025-01-09 19:33:11 发布

阅读量552

点赞数

分类专栏：数据库文章标签：数据库大数据

本文链接：https://blog.youkuaiyun.com/m0_59747688/article/details/129716224

版权

ElasticSearch擅长大数据搜索与扩展，但不支持多表连接和事务，适合静态数据存储。它具有写入慢、读取快的特点，适用于全文索引和简单查询。然而，其不支持复杂的SQL操作，不适用于需要原子事务的场景，如银行系统。此外，ES不是好的文档数据库，且对查询缓存优化不足，直接用作主库存在局限性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

这取决于你需要ElasticSearch做什么？首先每个数据库都有自己的权衡，ElasticSearch支持大数据的扩展，灵活的单个对象的存储和快速搜索查询。但是它的代价是牺牲多表连接，事务和延迟。

ES只是一个搜索引擎，适合存储一些（有限的）静态数据！而MySQL是个关系数据库啊！在分布式系统中常用ES作为前端静态数据存储，最终的数据存储都是在MySQL里面的。并且ES都是更新频率很低的数据，因为ES更新数据会引起整个ES性能低下。

ElasticSearch不支持原子事务，如果某处出现错误，不会回滚更改。这对于银行系统是不可接受的。比如银行转账，你必须同时更新同步多个表。ES写入数据后，需要0.5秒左右的时间才能被查询到。但是ES 搜索速度比mongo等数据库更快更好。

ES 没有 ORM，所以的代码里基本上就是查询的 JSON Query 满天飞，非常乱不说，还容易出错。ES是倒排索引，数据库是Btree索引。所以ES是写入慢，读取快。数据库是写入快，读取慢。

对于很简单的 SQL 操作，ES 也没有很好的操作方式。比如说 select * from xxx 这么简单的操作，ES 是不支持的。ES 最多返回 10000 条数据，所以你必须自己用 cursor 封装一个读取的操作才能获取所有数据。

社区和公司内也有其他团队把 ES 应用于 OLAP 分析、文档数据库等场景，有需要的团队可结合场景需求评估测试。由于不支持事务，以及在建立索引方面的计算 / 存储成本，ES 并不适合于 OLTP 及离线日志数据处理等场景。

其实是因为elasticsearch倒排索