来自个人博客地址选择MariaDB的压缩数据引擎TokuDB
业务运用场景
- 数据基本不用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 | - |
sqlite3 | 46.5 | - |
mariadb | 1.69 | 21.86 |
综合分析
- MariaDB(TokuDB 存储引擎) 场景基本全符合, 目前阿里,腾讯都有在线上使用(采用)
- sqlite 空间不占优势、整体速度不占优势(不采用)
- HBase 不能支持 where 条件、Order by 查询,只支持按照主键 Rowkey 和主键的 range 来查询,但是可以通过 HBase 提供的 API 进行条件过滤(不采用)
- MongoDB 占用空间大 (不采用)
- mysql5.7(myisam) 占用空间适中,但不是最优 (不采用)
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。