ElasticSearch缺ACID特性解决方案及与PostgreSQL/Kafka/ksql性能对比咨询

方案1：替换为其他数据库的优劣 #

PostgreSQL #

• 优势：完整支持ACID事务，数据可靠性远高于ES做主库的场景；内置JSONB类型可兼容原有半结构化数据存储需求，7.0+版本内置的全文检索能力在千万级以下数据集场景下性能接近ES；生态成熟，支持GIN、GiST等多类索引适配多维度检索、聚合需求
• 劣势：纯全文检索超大规模（亿级以上单索引）、高吞吐查询场景下性能比ES低20%~35%；分布式集群扩展能力弱于ES，分布式部署和运维复杂度更高；原有基于ES DSL的查询逻辑需要适配改写，改造量较大

Kafka+ksqlDB #

• 优势：支持流场景下的Exactly-Once语义，写入吞吐量远高于ES；天然适配事件溯源架构，适合写多读少的实时数据流场景；水平扩展能力极强，集群扩容门槛极低
• 劣势：不属于通用的文档/关系型数据库，不支持高频随机更新、复杂事务查询场景；ksqlDB的查询能力有限，不支持复杂全文检索、多维度嵌套聚合；查询延迟高于ES，存储成本是ES的1.5~2倍

方案2：搭配其他组件和ES共存的优劣 #

常规实现逻辑为：选ACID兼容的数据库（PG/MySQL等）作为主存储承担写入，ES仅作为检索加速层；写入链路先写主库保障事务，再通过CDC工具同步数据到ES，查询链路直接走ES复用原有能力。

• 优势：完全保留ES原有全文检索、多维度聚合的性能优势，现有查询逻辑几乎不需要改造；主库保障ACID特性，从根源规避ES丢数风险；架构改造成本远低于完全替换方案
• 劣势：整体架构复杂度提升，需要额外维护主库、数据同步链路组件；存在数据同步延迟（常规为百毫秒级，强一致读需求需要直接走主库）；存储成本上升，需要同时维护主库、ES两份数据

性能差异测试方案 #

测试前置准备 #

• 梳理自身业务的核心负载模型：读写占比、全文检索请求占比、聚合查询占比、点查询占比、单请求数据体量、峰值QPS要求
• 准备和生产完全对齐的测试数据集，数据量级、字段结构、索引配置和生产环境一致

核心测试指标 #

• 写入侧：不同并发下的写入QPS、P95/P99写入延迟、写入成功率
• 查询侧：不同查询类型下的P95/P99查询延迟、单节点/集群查询QPS
• 可靠性侧：模拟节点宕机、网络分区故障场景下的数据一致性、数据丢失率、故障恢复时长

测试注意事项 #

• 所有测试方案的硬件资源配置保持一致，CPU、内存、磁盘类型、网络带宽对齐
• 执行不少于1小时的长时间压测，排除冷启动、缓存命中波动带来的测试结果偏差
• ES搭配组件的方案，需要把数据同步链路的延迟、同步失败重试开销纳入测试统计范围

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