直接使用Elasticsearch替代关系型数据库执行CRUD是否存在问题？

一、不依托关系型数据库，直接用ES做全量CRUD的隐患 #

• 数据可靠性与一致性缺陷：ES本身没有事务ACID保障，跨分片/多文档操作无法保证原子性，且默认是近实时写入，异常场景下（比如节点宕机、网络分区）出现数据丢失、不一致的概率远高于MySQL、PostgreSQL等成熟关系型数据库，也没有闪回、事务回滚等能力，误操作后数据很难恢复。
• 成本与性能适配问题：ES为了支持检索会为字段创建多套索引结构，相同原始数据的存储占用是关系型数据库的3_{5倍，存储成本显著更高；另外针对主键点查、小范围精准查询的性能比关系型数据库低1}2个数量级，完全不适合高频简单查询场景。
• 运维复杂度陡增：ES集群出现分片损坏、数据不一致等故障时，数据恢复的难度和耗时远高于关系型数据库，日常运维、扩缩容的门槛也更高。

二、高数据更新频率下的性能劣化问题 #

高更新频率下ES必然会出现性能劣化，核心原因有两个：

• ES的更新本质是标记删除旧文档+写入新文档，旧文档不会立刻被物理清理，需要等到后台Segment Merge阶段才会被删除，更新越频繁，无效文档占比越高，查询性能会持续下降，同时Merge过程会消耗大量CPU、磁盘IO资源，进一步挤压读写请求的资源。
• 高并发更新场景下非常容易出现版本冲突、写入队列堆积的问题，严重时会触发ES的写入熔断机制，直接拒绝业务请求。

三、全量更新设置setRefreshPolicy(IMMEDIATE)的性能影响 #

这个操作对性能的负面影响极大，绝对不建议在高并发写入场景开启：

• 该策略要求每次写入请求都立刻触发Refresh操作，生成新的Segment并对外可见，而Refresh本身是资源消耗很高的操作，默认配置下ES1秒才执行一次，改成每请求触发会导致频繁生成小Segment，后续还要消耗大量资源做Segment合并，很容易把集群的CPU、磁盘IO打满。
• 实测同等硬件配置下，开启IMMEDIATE刷新策略的集群写入性能比默认策略低90%以上，还极易触发节点OOM、离线等故障。

最佳实践建议：ES的定位是检索引擎，更适合作为关系型数据库的辅助检索层，仅同步需要检索的字段提供搜索能力，核心业务数据还是存储在关系型数据库中更稳妥。

内容的提问来源于stack exchange，提问作者tianzhenjiu