基于500w业务数据的存储选型

存储需求

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

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

 

数据场景

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

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。

上一篇:ES军规


下一篇:Spring Cloud Eureka 入门 (二)服务提供者详解