选择MariaDB的压缩数据引擎TokuDB

HBase (基本不符合应用场景)

1. 海量数据存储能力，超高的数据读写性能
2. HBase 不能支持 where 条件、Order by 查询，只支持按照主键 Rowkey 和主键的 range 来查询，但是可以通过 HBase 提供的 API 进行条件过滤

MariaDB(TokuDB 存储引擎TOKUDB_ZLIB 压缩算法)

优点

1. TokuDB 除了支持现有的索引类型外， 还增加了(第二)集合索引, 以满足多样性的覆盖索引的查询, 费县县情网在快速创建索引方面提高了查询的效率
2. 数据压缩。 官方的建议: 6核数以下的机器建议标准压缩, 反之可以使用高级别的压缩。
3. 高压缩比，默认使用zlib进行压缩，尤其是对字符串(varchar,text等)类型有非常高的压缩比，比较适合存储日志、原始数据等。官方宣称可以达到1：12
4. 在线添加索引，不影响读写操作
5. 非常快的写入性能， Fractal-tree在事务实现上有优势,无undo log，官方称至少比innodb高9倍
6. 数据量可以扩展到几个TB；
7. 不会产生索引碎片

缺点：

1. 不支持外键(foreign key)功能，如果您的表有外键，切换到 TokuDB引擎后，此约束将被忽略
2. TokuDB 不适大量读取的场景，因为压缩解压缩的原因。CPU占用会高2-3倍，但由于压缩后空间小，IO开销低，平均响应时间大概是2倍左右。
3. online ddl 对text,blob等类型的字段不适用
4. 没有完善的热备工具，只能通过mysqldump进行逻辑备份

适用场景

1. 访问频率不高的数据或历史数据归档
2. 范围查询多

空间占用对比（一个索引）

查询对比

写入对比

综合分析

1. MariaDB（TokuDB 存储引擎） 场景基本全符合， 目前阿里，腾讯都有在线上使用（采用）
2. sqlite 空间不占优势、整体速度不占优势(不采用)
3. HBase 不能支持 where 条件、Order by 查询，只支持按照主键 Rowkey 和主键的 range 来查询，但是可以通过 HBase 提供的 API 进行条件过滤（不采用）
4. MongoDB 占用空间大 (不采用)
5. mysql5.7(myisam) 占用空间适中，但不是最优 (不采用)

选择MariaDB的压缩数据引擎TokuDB

标签：本机   where   系统   写入   归档   兴趣   table   word   直接