存储需求
当前业务系统的定位是数据密集型应用（相对应的还有计算密集型应用），具有很大的存储需求。
数据库的选型和设计直接关系到服务质量，包括可用性、稳定性，以及服务所提供的价值。
数据场景
选型前，需要根据自己的具体业务，充分调研数据场景。包括：
1. 要存储什么样的数据？
2. 估算数据量：包括总行数，占用空间大小，是否会有单条数据超过128k的情况等。
3. 是否有频繁的读写操作？
4. 是否对精确查询、模糊搜索、多样化的检索场景有较高的需求和性能要求？
5. 对事务是否有很强的依赖？
6. 是否需要结构化数据存储，且数据结构可能会变化？例如新增一列column。
7. 存储成本预算。
8. 团队熟悉度。
存储选型
常见的存储有 MySQL，PostgreSQL，MongoDB，ES 等，进行横向比较：
| 类型 | 存储 | 特点 | 成本（参考某商业化公有云） |
|---|---|---|---|
| 关系型数据库 | MySQL |
| 中 8核16G 3节点 600GB 2.42k/月 |
| PostgreSQL |
| 高 8核32G 2节点 600GB 2.31k/月 | |
| NoSQL - KV型数据库 | Redis |
| 低 16G 3节点 1.24k/月 |
| NoSQL - 文档型数据库 | MongoDB |
| 中 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。
标签：存储,500w,数据库,查询,索引,选型,数据,ES 来源： https://blog.csdn.net/Canon_in_D_Major/article/details/122548118
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。