MySQL内核月报 2014.10-TokuDB· 引擎特性·压缩

TokuDB除了有着较好的写性能外，还有一个重要的特性：压缩，而且大部分情况下压缩效果很不错。

目前TokuDB有４种压缩算法：



使用上也比较简单：






可能大家会有一个疑问：如果一个表创建的时候压缩算法是tokudb_quicklz，我可以通过ALERT TABLE改成其他算法吗？答案是：可以的！


TokuDB在底层实现上，用1byte来标记当前block的压缩算法，并持久化到磁盘，当压缩算法改变后，从磁盘读取数据然后解压缩的代码类似：




是不是很机智？


在使用TokuDB的过程中，一般不会改变压缩算法，除非默认的tokudb_zlib不给力，TokuDB是大block(4MB)，压缩效果较好，enjoy~
				


				
时间： 2024-09-11 11:57:28

		
		


		


	

	
	

		


		
MySQL内核月报 2014.10-TokuDB· 引擎特性·压缩的相关文章


						

		

			

                MySQL内核月报 2014.11-TokuDB·　引擎特性·　FAST UPDATES
			

		

		

									

				MySQL的update在执行时需要做read-modify-write: 操作路径还是比较长的,TokuDB提供了fast update语法,让＂某些＂场景下update更快,无需做read和modify直接write. 用法: NOAR语句: 语义是:插入一条记录,如果该记录存在(id为1),就对count的值做加法操作,不存在则做插入. 注意: fast updates的条件是比较苛刻的,必须满足: 看了这些苛刻的条件后,有种＂臣妾做不到＂的感觉了吧,可以看出TokuDB一直为细节而努力.			

		

	

				

		

			

                MySQL内核月报 2014.09-MySQL·　引擎差异·create_time in status
			

		

		

									

				背景 在MySQL数据库中,我们利用show table status命令可以得到表的状态信息,其中一列信息为create_time,表示表的创建时间.对于不同的存储引擎(如InnoDB/MyISAM/MEMORY)我们都能得到create_time的数值.我们知道不同的存储引擎表的文件结构是不同的,因此实现表的创建时间create_time的机制也是不同的.下面着重探讨InnoDB和MyISAM在create_time上的区别. 实验 我们先做一些实验来看看create_time的特点.在In			

		

	

				

		

			

                MySQL内核月报 2014.12-MySQL·　优化改进· GTID启动优化
			

		

		

									

				背景 GTID 可以说是 MySQL 5.6 版本的一个杀手级特性,它给主备复制带来了极大的便利,RDS只读实例就是强依赖于这个特性.然而GTID在给我们带来便利的同时,也埋下了许多坑,最近几期内核月报中GTID的频繁出现也说明了这一点,对其我们可以说是既爱又恨. GTID 并不是免费午餐,要使用它是要有代价的,为了保证GTID这个体系能够运转起来,需要做许多相关的工作,比如binlog里每个事务要多记 gtid_event 这种事件.写binlog的时候要生成 gtid.要维护几个GTID集合			

		

	

						

		

			

                MySQL内核月报 2014.12-TokuDB· Binary Log Group Commit with TokuDB
			

		

		

									

				MySQL在开启Binary Log的情况下,使用2PC(图1)来保证事务(XA)完整性的,每次提交事务需要做: 每个事务在提交的时候都要做3次fsync以确保日志真正的落盘,这样在log里,一个事务就会有3种状态: 这样,无论处于任何一个状态,事务的完整性都不会被破坏,但是每次提交会产生3次fsync,性能非常低. 为了提升性能,MySQL 5.6增加了group commit功能,当多个事务并发提交时,让多个都在等待fsync的事务合并做一次fsync,大大提升了吞吐量. 但是这个优化还需要			

		

	

				

		

			

                MySQL内核月报 2014.08-TokuDB·社区八卦·TokuDB团队
			

		

		

									

				第一期先介绍下TokuDB团队吧. TokuDB自从开源后(更赞的是开源了所有的commits),逐渐被大家所熟悉,MariaDB 5.5系列和Percona Server 5.6的GA版本中,都以plugin的方式集成. 3位(Tokutek)创始人: Michael A. Bender , Martín Farach-Colton , Bradley C. Kuszmaul  2012年他们合发了一篇208页的pdf[Data Structures and Algorithms for Bi			

		

	

				

		

			

                MySQL内核月报 2014.11-MySQL·　5.7特性·在线Truncate undo log 表空间
			

		

		

									

				背景 Innodb使用undo log来实现MVCC,这意味着如果一个很老的事务长时间不提交,那么新产生的undo log都无法被及时清理掉.在MySQL 5.5及之前版本中,undo log是存储在ibdata中.从5.6开始可以使用独立的undo log表空间来存储undo.但是直到5.6,一旦undo log膨胀,依然没有任何办法为其 "减肥".因此我们经常看到ibdata被膨胀到几十上百G. 改进 在MySQL5.7.5版本中终于增加了这个众望所归的功能,实现了在线trunca			

		

	

				

		

			

                MySQL内核月报 2014.08-MariaDB·分支特性·FusionIO特性支持
			

		

		

									

				背景 随着存储设备越来越快,InnoDB许多原有的设计不再适合新的高速硬件,因此MariaDB 10.1 Alpha版本针对FusionIO PCI-E SSD做出了专门的优化,充分利用了Fio的硬件特性. MDEV-6246这个需求改造了MariaDB,以利用fio的Atomic writes和文件系统压缩特性. 为何Fio会更快呢,因为传统的存储设备读取,是左图的方式,要经过RAID控制器,来回的路径就长了.而Fio才有右图的方式,设备通过PCI槽直接与CPU交互,大大缩短了路径. Atom			

		

	

				

		

			

                MySQL内核月报 2014.09-TokuDB· HA方案·TokuDB热备
			

		

		

									

				TokuDB企业版提供热备功能(与社区版唯一的区别). 该功能以plugin方式提供,当backup plugin加载后,它会拦截所有的文件操作(比如文件读写/目录操作等),从而实现在备份的过程中增量同步,具体原理请看: http://www.tokutek.com/2013/09/tokudb-hot-backup-part-1/ http://www.tokutek.com/2013/09/tokudb-hot-backup-part-2/  社区版如何实现热备呢? 官方推荐的方式是mylv			

		

	

				

		

			

                MySQL内核月报 2014.08-MariaDB·分支特性·支持大于16K的InnoDB Page Size
			

		

		

									

				背景 最近发布的MariaDB 10.1 Alpha版本,提交了一个改动,放宽了InnoDB Page<=16K的限制,将上限提高到64K. 从MDEV-6075需求文档中可以看出,目前只支持COMPACT的结构,DYNAMIC结构能否支持还在研究,COMPRESSED结构则确定无法支持. 业务应用 什么情况下需要64K这么大的页面呢? 我们知道一个Page,不是所有的page_size都可以用来存数据,还有一些管理信息要存,例如页头和页尾(InnoDB Page). 此外,InnoDB Buf