ElasticSearch和普通数据库存储

这取决于你需要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倒排索引，导致回表性能本来就很难优化。并且，elasticsearch对于查询缓存，没有做很多优化导致的，直接用单id查询es性能也是极好的，因为做了优化。

ES 也不是一个很好的文档数据库，对于数组的 append 操作并不直接支持，需要很复杂的操作。而且ElasticSearch没有安全机制。你必须自己提供安全保障。

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

参考文章：

https://baijiahao.baidu.com/s?id=1721820719672976775&wfr=spider&for=pc