存储需求

当前业务系统的定位是数据密集型应用（相对应的还有计算密集型应用），具有很大的存储需求。

数据库的选型和设计直接关系到服务质量，包括可用性、稳定性，以及服务所提供的价值。

 

数据场景

选型前，需要根据自己的具体业务，充分调研数据场景。包括：

1. 要存储什么样的数据？

2. 估算数据量：包括总行数，占用空间大小，是否会有单条数据超过128k的情况等。

3. 是否有频繁的读写操作？

4. 是否对精确查询、模糊搜索、多样化的检索场景有较高的需求和性能要求？

5. 对事务是否有很强的依赖？

6. 是否需要结构化数据存储，且数据结构可能会变化？例如新增一列column。

7. 存储成本预算。

8. 团队熟悉度。

 

 存储选型

常见的存储有 MySQL，PostgreSQL，MongoDB，ES 等，进行横向比较：

类型	存储	特点	成本（参考某商业化公有云）
关系型数据库	MySQL	强大的事务能力 读写性能高（实际性能取决于业务代码） 索引提供强大的快速检索能力 适合存储大量的结构化数据	中 8核16G 3节点 600GB 2.42k/月
	PostgreSQL	具有强一致性事务能力的关系型数据库 对 SQL 标准的支持度极高 具有较高的数据一致性和可靠性	高 8核32G 2节点 600GB 2.31k/月
NoSQL - KV型数据库	Redis	单线程KV存储，纯内存操作，通过rdb/aof实现持久化 支持string、list、set、hash等多种数据结构 基于key的读具有极高的查询效率 不擅长做value搜索	低 16G 3节点 1.24k/月
NoSQL - 文档型数据库	MongoDB	文档型数据库，在概念和功能上非常贴近于关系型数据库 通过将热数据存放在物理内存的机制实现快速读写 具有高可用和可扩展性 支持动态新增 column 多适用于固定字段查询、单一查询	中 6核16G 3节点 500GB 1.96k/月
	ES	分布式搜索的文档型数据库 倒排索引提供了高效搜索能力，在海量数据下有较高的查询效率 在全文检索、模糊查询、组合字段查询场景下有较高的效率	中 8核16G 3节点 600GB 2.49k/月

 

MySQL / ES 性能压测

存储配置：8核16GB，双节点，400G存储；

数据量：500W；

并发度：50；

压测结果：（数据列分别为 【QPS】 + 【AVG_TIME】 + 【P95_TIME】）

数据库	磁盘占用	读场景				写场景
		where app_id=?	where unique_id in (?)	where 用户维度=?	where 存储维度=？	insert 新数据	update 旧数据
ES（业务字段设置为keyword）	2.7G	1445  34ms  37ms	1481  33ms  38ms	1493  33ms        37ms	1523  32ms        35ms	1506  33ms  37ms	1492  34ms  41ms
MySQL（业务字段加索引）	1.626G(数据0.576+索引1.05)	1657  30ms  35ms	1658  30ms  34ms	1662  30ms        33ms	1672  29ms        33ms	798    63ms  75ms	800    62ms  67ms
MySQL（业务字段不加索引）	0.876G(数据0.576+索引0.3)	1667  30ms  34ms	1678  30ms  34ms	4        12423ms  16973ms	4        13475ms  14963ms	786    64ms  70ms	820    61ms  72ms

 

结论

压测结果来看，在百万量级下mysql不加索引时搜索搜索性能是很差的；

而加了索引后Mysql和ES性能表现差不多，mysql 写场景稍差。

根据业务考虑，以后扩展可能会经常增加字段，而新加字段不可能每列都加索引，这样MySQL就会出现查询性能瓶颈，因此采用ES。