IM消息数据库调研
IM系统中最核心的部分是消息系统，消息系统中最核心的功能是消息的同步和存储：
- 1）消息的同步：将消息完整的、快速的从发送方传递到接收方，就是消息的同步。消息同步系统最重要的衡量指标就是消息传递的实时性、完整性以及能支撑的消息规模。从功能上来说，一般至少要支持在线和离线推送，高级的IM系统还支持『多端同步』；
- 2）消息的存储：消息存储即消息的持久化保存，这里不是指消息在客户端本地的保存，而是指云端的保存，功能上对应的就是『消息漫游』。『消息漫游』的好处是可以实现账号在任意端登陆查看所有历史消息，这也是高级IM系统特有的功能之一。
数据库选型
消息系统最核心的两个库是消息同步库和消息存储库，两个库对数据库有不同的要求：
| 数据模型 | Timeline模型 | Timeline模型 |
| 写能力 | 高并发写，10万TPS | 高并发写，少量读，万TPS |
| 读能力 | 高并发范围读,10万TPS | 少量范围读，千级TPS |
| 存储规模 | 保存一段时间内的同步消息，TB级。保留千万级的Timeline模型 | 保存全量消息，百TB级。保留亿级Timeline模型 |
总结下来，ToC IM对数据库的要求有如下几点：
- 1）表结构设计能够满足Timeline模型的功能要求：不要求关系模型，能够实现队列模型，并能够支持生成自增的SeqId；
- 2）能够支持高并发写和范围读，规模在十万级TPS；
- 3）能够保存海量数据，百TB级；
- 4）能够为数据定义生命周期。
对于ToB的IM要求可以降低：
- 1）表结构设计能够满足Timeline模型的功能要求：不要求关系模型，能够实现队列模型，并能够支持生成自增的SeqId；
- 2）能够支持高并发写和范围读，规模在万级TPS；
- 3）能够保存海量数据，TB级；
- 4）能够为数据定义生命周期。
对于以上要求首先排除OLAP 数据库，OLAP 数据库在高并发写和实时更新场景性能都比较差。
其次排除elasticsearch这类搜索数据库，对于IM系统来说，高并发写的场景是远比高并发读的场景多的。
罗列出以下数据库：
| 支持生成自增的SeqId | 专为时间序列数据设计的数据库，支持队列模型和自增的 SeqId | 高度可扩展的分布式数据库，支持队列模型和自增的 SeqId | 分布式 SQL 数据库，支持队列模型和自增的 SeqId | 支持通过 AUTO_INCREMENT 实现自增的 SeqId，可以设计队列模型 | 支持通过 SERIAL 或 IDENTITY 列实现自增的 SeqId，也可以设计队列模型 | 适用于需要存储大量非结构化数据的场景，通过额外设计可支持生成自增序号 | 提供了 Timeline 模型，能够满足 Timeline 模型的功能要求，支持队列模型和自增的 SeqId |
| 支持高并发写和范围读，规模在万级TPS | 支持，优化了对高并发写入和范围查询的支持，适用于处理大规模时间序列数据 | 支持 | 支持，适合处理大规模数据 | 在高并发写入和范围读取方面表现良好，特别是在简单的读写操作中 | 在高并发写入和范围读取方面表现出色，特别是在处理复杂事务时 | 支持，范围读和实时更新性能没有前面数据库性能好 | 能够支持高并发写入和范围读取 |
| 能够保存海量数据，TB级 | 支持 PB 级数据存储 | 支持 PB 级数据存储 | 支持 PB 级数据存储 | 能够处理 PB 级数据，需要合理的表分区和索引设计来优化性能 | 能够处理 PB 级数据，并且支持多种存储选项和优化技术，如表分区、索引优化等 | 支持 PB 级数据存储 | 支持 PB 级数据存储 |
| 能够为数据定义生命周期 | 支持数据生命周期管理，可以通过设置保留策略来自动删除过期数据。 | 支持数据生命周期管理，可以通过 TTL（Time To Live）实现 | 支持数据生命周期管理，可以通过表分区和数据清理策略实现 | 支持通过事件调度程序（Event Scheduler）实现数据生命周期管理，例如定期删除旧数据。 | 支持通过 TTL（Time To Live）索引实现数据生命周期管理，也可以使用 cron 作业或 PostgreSQL 的 pg_cron 扩展来实现定期数据清理 | 支持数据生命周期管理，可以通过 TTL 索引等方式实现 | 支持数据生命周期管理，可以为数据定义生命周期 |
| 使用/维护成本 | 非常高(没人用过，使用成本和维护成本都很高) | 非常高(没人用过，使用成本和维护成本都很高) | 高(与mysql类似，国内有一些公司在用，但我们公司没有用过) | 使用成本很低，维护成本较高(需要进行分库分表，可作为过渡版本) | 一般（用的不多，线上只有少量非核心业务使用） | 低(高并发实时更新和范围查询可能会遇到瓶颈，使用WiredTiger 引擎万级别应该不会有问题) | 不可用，阿里云独有存储库 |
通过上面比较，我们计划先用mysql存储，后面替换成tidb或者Cassandra和InfluxDB数据库(需要一段时间的调研和学习)。