业务运用场景
- 数据基本不用update， 不频繁的范围查询
- 数据存储量较大（为以后准备）
- 选择占用磁盘较小的db
- 业务对数据库插入操作频繁，为避免影响其它业务，需要将直播业务的DB 独立出来，选择另外的db
db类型分析（只做简单表达，有兴趣可以自行了解）
sqlite
优点
- 整个数据库都包含在磁盘上的一个文件中，因此它有很好的迁移性
- 功能简约,小型化,追求最大磁盘效率
- 支持数据库大小至2TB
缺点
- SQLite 的数据库权限只依赖于文件系统，没有用户帐户的概念，
- SQLite 的缺陷之一是它的写入操作。这个数据库同一时间只允许一个写操作，因此吞吐量有限, mysql 连接插入5000条的时间是2.56秒，sqlite 是46.5秒 (本机操作)
- 不支持分布式
MongoDB
- 占用的空间很大，榆社政府网站因为它属于典型空间换时间原则的类型(直接不选择)
- 数据结构由键值(key=>value)对组成。MongoDB 文档类似于 JSON 对象
HBase (基本不符合应用场景)
- 海量数据存储能力，超高的数据读写性能
- HBase 不能支持 where 条件、Order by 查询，只支持按照主键 Rowkey 和主键的 range 来查询，但是可以通过 HBase 提供的 API 进行条件过滤
MariaDB(TokuDB 存储引擎TOKUDB_ZLIB 压缩算法)
优点
- TokuDB 除了支持现有的索引类型外， 还增加了(第二)集合索引, 以满足多样性的覆盖索引的查询, 费县县情网在快速创建索引方面提高了查询的效率
- 数据压缩。 官方的建议: 6核数以下的机器建议标准压缩, 反之可以使用高级别的压缩。
- 高压缩比，默认使用zlib进行压缩，尤其是对字符串(varchar,text等)类型有非常高的压缩比，比较适合存储日志、原始数据等。官方宣称可以达到1：12
- 在线添加索引，不影响读写操作
- 非常快的写入性能， Fractal-tree在事务实现上有优势,无undo log，官方称至少比innodb高9倍
- 数据量可以扩展到几个TB；
- 不会产生索引碎片
缺点：
- 不支持外键(foreign key)功能，如果您的表有外键，切换到 TokuDB引擎后，此约束将被忽略
- TokuDB 不适大量读取的场景，因为压缩解压缩的原因。CPU占用会高2-3倍，但由于压缩后空间小，IO开销低，平均响应时间大概是2倍左右。
- online ddl 对text,blob等类型的字段不适用
- 没有完善的热备工具，只能通过mysqldump进行逻辑备份
适用场景
- 访问频率不高的数据或历史数据归档
- 范围查询多
空间占用对比（一个索引）
| 类型 | 10W | 20W | 30W | 100W |
|---|---|---|---|---|
| mysql5.7(innodb) | 17M | 27M | 36M | 100M |
| mysql5.7(myisam) | 5.8M | 11.8M | 17.9M | 59.7M |
| sqlite3 | 7.2M | - | - | - |
| mariadb(totudb) | 1.1M | 3.1M | 4.6M | 14.29M |
查询对比
| 类型 | 10W | 5W |
|---|---|---|
| mysql5.7 | 0.21 | 0.10 |
| sqlite3 | 0.30 | 0.14 |
| mariadb | 0.19 | 0.07 |
写入对比
| 类型 | 5000次 | 50000次 |
|---|---|---|
| mysql5.7 | 2.56 | 0.10 |
| sqlite3 | 46.5 | 0.14 |
| mariadb | 1.69 | 21.86 |
综合分析
- MariaDB（TokuDB 存储引擎） 场景基本全符合， 目前阿里，腾讯都有在线上使用（采用）
- sqlite 空间不占优势、整体速度不占优势(不采用)
- HBase 不能支持 where 条件、Order by 查询，只支持按照主键 Rowkey 和主键的 range 来查询，但是可以通过 HBase 提供的 API 进行条件过滤（不采用）
- MongoDB 占用空间大 (不采用)
- mysql5.7(myisam) 占用空间适中，但不是最优 (不采用)
