消息存储数据库选型调研

亿级别消息存储	✔	✔(可以通过分库分表支持)	✔	✔	✔
单条消息查询	✔	✔	✔	✔	✔
根据用户/组/模板/时间/其他业务字段 分页查询消息	✔	✔	✘	✔	✔(有查询限制)
消息更新(更新确认时间/消息状态/发送结果)	✔	✔	✘	✔	✔
根据用户/组/模板/时间/其他业务字段 统计各个维度的消息发送情况	✔(支持简单的全文检索)	✔(不支持全文检索，会有性能瓶颈)	✘	✔(会有性能瓶颈，不支持全文检索)	✔
事务原子性保证(多条写入/更新场景)	✔(仅支持批量事务)	✔(支持完整的事务)	✘	✘	✘
支持并发查询	单节点上万QPS	单节点上万QPS		单节点上万QPS	单节点上万QPS
可扩展性	✔(支持前端/后端分别扩展)	✔	✔	✔	✔
查询响应时间	通过优化可达到亚秒级	通过优化可达到亚秒级		通过优化可达到亚秒级	通过优化可达到亚秒级
实时写入性能	通过优化可达数十万每秒	通过优化可达数十万每秒	优化后可达上百万每秒	优化后可达数十万每秒	比较拉胯，优化后勉强能达万级别
后端使用难度	兼容mysql协议，入门简单，使用难度较低	简单，后端很多项目都在使用	没有尝试过作为数据库来用，使用经验少，难度较高	简单，后端很多项目都在用	简单，后端很多项目都在用
学习成本	兼容mysql协议，入门简单，简单使用学习成本较低	极低	简单使用学习成本较低	简单使用学习成本较低	简单使用学习成本较低

kafka用于消息队列是合适的，但是对于数据的查询分析和修改场景支持都比较弱，无法满足业务场景

Elasticsearch和mongo都无法保证事务原子性，对于多条数据批量新增和更新场景无法保证一起成功，Elasticsearch的写入性能拉胯但可以通过延迟批量写入来弥补，mongo对数据分析场景支持比较弱

mysql是比较全面的且后端对mysql的掌握都很好，缺点就在于在单表数据量较大时性能会急剧下降，且对数据分析场景支持一般

doris对全文检索支持不是很好且不支持完整的事务，但是相较而言比较全面，特别是在数据分析场景比较出色，从长远考虑未来应用程序与大数据结合使用的场景还是很多的，用消息中心来试水风险比较小

方案一：mysql+doris组合存储，mysql存储配置信息(渠道、模板、策略、发送人、组信息等)，doris存储发送的消息信息(发送请求、发送结果)用于查询和分析，doris单表可支持亿级别数据，且写入性能查询性能各方面都不错，比较均衡，与mysql互补很合适

方案二：mysql+elasticsearch也可以满足所有业务场景，只不过mysql在单表数据量达到五百万级别后性能会急剧下降，需要额外设计一套分库分表方案来保证性能，架构的复杂度较高；Elasticsearch的查询性能很好，后端对es的使用也很熟练，写入性能可以通过延迟批量写入来弥补，二者可作为互补

倾向用第一种方案组合存储