MySQL
背景
之前在公司做的一个数据库测试，为后续公司技术选型提供参考。业务场景大概是：
- 按照10万/天/每台采集设备流量预估，1月 = 10w × 30 = 300w条数据
- 要做到80台采集设备，1月= 300w × 80 = 2.4亿条数据
按照上述数据量来预估，服务器每月产生的数据达2亿左右，mysql数据库在单表达到千万级别，单纯的数据查询功能就会出现瓶颈。
一些调研方案
- merge引擎（mysql）
- mycat分库分表中间件（mysql）
- elasticsearch搜索引擎
- redis（Nosql）
- MongoDB（Nosql）
- 时间序列数据库（TSDB）
| 存储方案 | 测试数据量 | 存储策略 | 测试结果 | 结论 | 备注 |
|---|---|---|---|---|---|
| merge引擎 | 1亿 | 分10个表 | 1. 条件查询：5秒左右 2. count查询：10秒+ |
对于我们的业务系统，分页查询需要15秒+的响应时间 | 该测试结果在覆盖索引的条件下结果，如果查询未覆盖索引，结果会更糟 |
| mycat分库分表中间件 | 1亿 | 分10个表 | 1. 条件查询：秒级左右 2. count查询：秒级左右 |
分页查询响应时间在5秒左右 | 该测试结果在覆盖索引的条件下结果，如果查询未覆盖索引，结果同merge引擎 |
| elasticsearch搜索引擎 | 1亿 | 未做处理 | 秒级响应 | 1. 亿级数据查询在秒级响应，但存储达到30G+ 2. 本身支持分布式 3. 后期运维复杂，对数据备份和数据清理还未做研究 4. 针对我们目前的单机产品，不太适合 |
|
| redis | - | 内存存储 | 未做具体测试 | 1. 内存存储，查询速度快 2. 但数据全部存储在内存中，随着时间累积内存逐渐被消耗完，且掉电数据全丢，需要额外做持久化 3. 不适合做条件查询 4. 适合做缓存方案 |
|
| MongoDB | 未做测试 | 非关系型数据库，但可以处理一些简单的关系型查询，速度快，后续还需根据业务需求做一些测试 |
图片源自网络，侵权必删！
网友评论