存储应用事件历史及上下线状态的最优实现方案是什么

结合你描述的业务规模、核心需求，优先选择常规关系型数据库（如MySQL、PostgreSQL）即可，Elasticsearch属于可选补充方案而非必选，具体判断逻辑如下：

优先选关系型数据库的核心理由 #

• 数据规模极低，完全无性能压力：单区域单日最多20条事件，就算部署100个区域，全年累计也才不到100万条数据，两类存储都能轻松承载，不需要为了性能强行上ES
• 匹配核心需求的实现成本更低：
  • 你的核心需求之一是上下线时长统计，需要关联同一区域的相邻上下线事件做计算，关系型数据库的窗口函数、事务特性可以很方便的实现这类逻辑，代码复杂度远低于ES
  • 状态变更事件属于核心审计数据，关系型数据库的ACID特性能保证写入可靠性，不会出现丢数据、重复写入的问题，满足客户端可靠展示历史的要求
  • 常规查询（按区域、时间范围查事件列表）只需要加(region_id, occur_time)联合索引就能做到毫秒级返回，完全满足业务需求
• 运维成本更低：不需要额外搭建ES集群、维护索引生命周期、处理分片均衡之类的问题，如果你现有业务已经在使用关系型数据库，直接复用现有基础设施即可

适合用Elasticsearch的场景 #

只有当你同时满足以下所有需求时，再考虑引入ES：

• 有全文检索需求：需要对上下线原因字段做任意关键词检索，比如要筛选所有包含「断电」「网络波动」关键词的历史事件，这类场景ES的全文检索能力远优于关系型数据库的模糊查询
• 有多维度聚合分析需求：需要大量按故障类型、操作人、区域、时间交叉统计的BI类需求，比如统计不同区域各故障类型的平均故障时长，ES的聚合查询实现效率更高
• 已有成熟的ES运维体系，不需要从零搭建维护

折中方案 #

如果同时需要关系型数据库的可靠性、事务能力，又需要ES的全文检索/聚合能力，可以把核心事件存在关系型数据库作为唯一正本，通过增量同步机制（如binlog同步）把数据同步到ES做检索加速即可。

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