选择MariaDB的压缩数据引擎TokuDB

来自个人博客地址
选择MariaDB的压缩数据引擎TokuDB

业务运用场景

  1. 数据基本不用update, 不频繁的范围查询
  2. 数据存储量较大(为以后准备)
  3. 选择占用磁盘较小的db
  4. 业务对数据库插入操作频繁,为避免影响其它业务,需要将直播业务的DB 独立出来,选择另外的db

db类型分析(只做简单表达,有兴趣可以自行了解)

sqlite

优点

  1. 整个数据库都包含在磁盘上的一个文件中,因此它有很好的迁移性
  2. 功能简约,小型化,追求最大磁盘效率
  3. 支持数据库大小至2TB

缺点

  1. SQLite 的数据库权限只依赖于文件系统,没有用户帐户的概念,
  2. SQLite 的缺陷之一是它的写入操作。这个数据库同一时间只允许一个写操作,因此吞吐量有限, mysql 连接插入5000条的时间是2.56秒,sqlite 是46.5秒 (本机操作)
  3. 不支持分布式

MongoDB

  1. 占用的空间很大,因为它属于典型空间换时间原则的类型(直接不选择)
  2. 数据结构由键值(key=>value)对组成。MongoDB 文档类似于 JSON 对象

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. 范围查询多

空间占用对比(一个索引)

类型10W20W30W100W
mysql5.7(innodb)17M27M36M100M
mysql5.7(myisam)5.8M11.8M17.9M59.7M
sqlite37.2M
mariadb(totudb)1.1M3.1M4.6M14.29M

查询对比

类型10W5W
mysql5.70.210.10
sqlite30.300.14
mariadb0.190.07

写入对比

类型5000次50000次
mysql5.72.56
sqlite346.5
mariadb1.6921.86

综合分析

  1. MariaDB(TokuDB 存储引擎) 场景基本全符合, 目前阿里,腾讯都有在线上使用(采用)
  2. sqlite 空间不占优势、整体速度不占优势(不采用)
  3. HBase 不能支持 where 条件、Order by 查询,只支持按照主键 Rowkey 和主键的 range 来查询,但是可以通过 HBase 提供的 API 进行条件过滤(不采用)
  4. MongoDB 占用空间大 (不采用)
  5. mysql5.7(myisam) 占用空间适中,但不是最优 (不采用)
    原文作者:大呜
    原文地址: https://segmentfault.com/a/1190000013102488
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞