这取决于你需要ElasticSearch做什么？首先每个数据库都有自己的权衡，ElasticSearch支持大数据的扩展，灵活的单个对象的存储和快速搜索查询。但是它的代价是牺牲多表连接，事务和延迟。
ES只是一个搜索引擎，适合存储一些（有限的）静态数据！而MySQL是个关系数据库啊！在分布式系统中常用ES作为前端静态数据存储，最终的数据存储都是在MySQL里面的。并且ES都是更新频率很低的数据，因为ES更新数据会引起整个ES性能低下。
ElasticSearch不支持原子事务，如果某处出现错误，不会回滚更改。这对于银行系统是不可接受的。比如银行转账，你必须同时更新同步多个表。ES写入数据后，需要0.5秒左右的时间才能被查询到。但是ES搜索速度比mongo等数据库更快更好。
ES没有ORM，所以的代码里基本上就是查询的JSONQuery满天飞，非常乱不说，还容易出错。ES是倒排索引，数据库是Btree索引。所以ES是写入慢，读取快。数据库是写入快，读取慢。
对于很简单的SQL操作，ES也没有很好的操作方式。比如说select*fromxxx这么简单的操作，ES是不支持的。ES最多返回条数据，所以你必须自己用cursor封装一个读取的操作才能获取所有数据。
社区和公司内也有其他团队把ES应用于OLAP分析、文档数据库等场景，有需要的团队可结合场景需求评估测试。由于不支持事务，以及在建立索引方面的计算/存储成本，ES并不适合于OLTP及离线日志数据处理等场景。
其实是因为elasticsearch倒排索引，导致回表性能本来就很难优化。并且，elasticsearch对于查询缓存，没有做很多优化导致的，直接用单id查询es性能也是极好的，因为做了优化。
ES也不是一个很好的文档数据库，对于数组的append操作并不直接支持，需要很复杂的操作。而且ElasticSearch没有安全机制。你必须自己提供安全保障。
ES本质上是一个倒排索引加上半吊子的MongoDB，虽然用作全文索引非常优秀，但是直接当做主库用还是欠缺不少支持的。别随意用“替代”这词说几年前说spark替代hadoop说的最凶的，但是在日常上基本离不开hdfs，这也是一样的道理。