存储需求
当前业务系统的定位是数据密集型应用（相对应的还有计算密集型应用），具有很大的存储需求。
数据库的选型和设计直接关系到服务质量，包括可用性、稳定性，以及服务所提供的价值。
数据场景
选型前，需要根据自己的具体业务，充分调研数据场景。包括：
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 索引字段=? | where 索引字段 in (?) | where 业务字段=? | insert 新数据 | update 旧数据 | ||
| ES（业务字段设置为keyword） | 2.7G | 1445 34ms 37ms | 1481 33ms 38ms | 1493 33ms 37ms | 1506 33ms 37ms | 1492 34ms 41ms |
| MySQL（业务字段加索引） | 1.626G(数据0.576+索引1.05) | 1657 30ms 35ms | 1658 30ms 34ms | 1662 30ms 33ms | 798 63ms 75ms | 800 62ms 67ms |
| MySQL（业务字段不加索引） | 0.876G(数据0.576+索引0.3) | 1667 30ms 34ms | 1678 30ms 34ms | 4 12423ms 16973ms | 786 64ms 70ms | 820 61ms 72ms |
结论
压测结果来看，在百万量级下mysql不加索引时搜索搜索性能是很差的；
而加了索引后Mysql和ES性能表现差不多，mysql 写场景稍差。
根据业务考虑，以后扩展可能会经常增加字段，而新加字段不可能每列都加索引，这样MySQL就会出现查询性能瓶颈，因此采用ES。
