数据库
首页 > 数据库> > MySQL 王者晋级之路

MySQL 王者晋级之路

作者:互联网

 

3.2 Query Cache:

 

 

 

3.3 存储引擎 

 

 

 

 

 

 

 

一、TokuDB的特点:

– 插入性能加快20到80倍
– 压缩数据减少存储空间
– 数据量可扩展到几个TB
– 不会产生索引碎片
– 支持Hot Column Addition, Hot Indexing和MVCC

 

具有高扩展性的存储引擎:TokuDB

posted on 2013 年 4 月 29 日 · 5 comments · 1,429 次浏览

TokuDB是什么?TokuDB是一个应用在MySQL和MariaDB中的存储引擎,它使用索引来加快查询速度,具有高扩展性并支持Hot Schema Modification。如果你的记录数量过亿、存储旧的记录或想要缩小数据占用的存储空间,很适合使用TokuDB。本文内容摘自淘宝核心系统团队博客分享的文档,最下面有原文地址及文档下载。

 

一、TokuDB的特点:

– 插入性能加快20到80倍
– 压缩数据减少存储空间
– 数据量可扩展到几个TB
– 不会产生索引碎片
– 支持Hot Column Addition, Hot Indexing和MVCC

二、TokuDB的安装和使用:

tokudb-install

三、Fractal Tree:

Fractal Tree是TokuDB中使用的索引结构,是TokuDB安身立命的根本,插入性能可以匹配B树最好的情况,高于B树最差情况两个数量级。

Fractal Tree

1、Fractal Tree结构特点
– 由多个有序的数组构成,大小呈指数级增长
– 数组要么全空,要么全满
– 数据插入到最小的数组,如果空间不够就将数据进行Merge

2、Fractal Tree的建立

Fractal Tree的建立

3、Fractal Tree的建立 (cont.)

Fractal Tree的建立 (cont.)

Fractal Tree的建立 (cont.)

4、Fractal Tree上的查询

Fractal Tree上的查询

四、TokuDB提供的特殊支持:

Hot Index Creation,TokuDB允许在已有table上创建索引,同时在索引创建的过程中可以进行insert和query操作。
– 需要设定服务器变量set tokudb_create_index_online=on
– 只能使用create index命令

Hot Column Addition and Deletion(HCAD),TokuDB允许在已有table上添加或者删除属性列,同时只在很短的时间内阻塞update和query操作。
– HCAD会获取一个表锁,用于将脏页刷到外存,所以会暂时阻塞其他操作

五、TokuDB占用的存储空间:

TokuDB占用的存储空间

TokuDB占用的存储空间

六、如何使用TokuDB?

如果你要存储blob,不要使用TokuDB,因为它限制记录不能太大;
如果你的记录数量过亿,使用TokuDB;
如果你注重update的性能,不要使用TokuDB,它没有Innodb快;
如果你要存储旧的记录,使用TokuDB;
如果你想要缩小数据占用的存储空间,使用TokuDB;

附上以上相关内容的ppt文档百度网盘下载地址:RethinkDBTokuDB调研测试报告.pptx

以上内容来源于:淘宝核心系统团队博客

 
        
http://mysql.taobao.org/monthly/2017/07/04/  
   

你需要知道的MySQL开源存储引擎TokuDB

 

在四月份的Percona Live MySQL会议上, TokuDB庆祝自己成为开源存储引擎整一周年。我现在仍能记得一年前它刚创建时的官方声明与对它的期望。当时的情况非常有意思,因为它拥有帮助MySQL管理大数据的潜力,而这是InnoDB无法做到的。TokuDB还有一些有意思的特性,比如”热模式转换(hot schema changes)”,可以使我们昂贵的闪存能够持续更长时间。

 

尽管在过去这一年里,我一直在关注TokuDB的发展,但我一直认为我不会去尝试使用它。直到最近,Percona Server发布了支持TokuDB插件的beta版本,我才觉得值得一试。

如果你还没有尝试过TokuDB,现在就是一个机会。首先我将介绍TokuDB是如何与MySQL协同工作的。

大家都知道,MySQL的核心在于存储引擎。InnoDB已经完全改变了MySQL,不仅让MySQL支持事务处理,并让整个系统变得更加成熟和稳定。即使是那些并不是事务特性的应用使用InnoDB也自得其乐。但是你是否记得不久之前InnoDB也是第三方专有插件呢?首先你需要将它与MySQL进行编译。然后将能够很容易的将该插件安装或者下载到已存在的服务器中。但是当InnoDB开源之后,一切就变得繁荣昌盛起来:人们越来越能接受它,而且慢慢地,它走上了正轨,得到了人们的推广。任何一个人都能阅读、修复、扩展它的编码,很多公司提交自己的修改融入其中,让InnoDB变得更好,直到它成为MySQL的首屈一指的存储引擎。

平衡大数据与存储成本

目前来看,与类似的MyISAM表相比,数据存(即使是压缩存储)到一个InnoDB表中需要的磁盘空间的确要更大,但是没有人会认为在一项新技术发展过程中不会出现缺点和不足。同时,磁盘的存储能力也在增强,这也有助于平衡每字节的价格,而且也能补偿InnoDB的空间需求。

但是磁盘容量的增加也对“什么值得存储”的界限进行了扩展。曾经的GB级磁盘既是近乎无限的存储空间,到如今已经成为有限,而TB级的磁盘成为了标配和基本需求。同时,尽管有大量有意思的东西可以浏览和探索,人们的注意力开始涣散,之前能够牢牢抓住现在却常常难以吸引眼球。如今,如果一个网站需要数秒才能进入,那么有些人就可能会失去兴趣。

SSD磁盘开始进行挽救这种情况,只需普通机械磁盘耗时的一小部分便能访问到数据。然而SSD在容量的扩展性却不太好:每字节成本的增加是跟与数据获取速度成比例的,而且SSD的寿命(或称持久性)不是很好,这是一笔昂贵的支出。需要明智地使用SSD。

基于这个原因,现在人们逐渐开始采用混合使用的方式,用快速、昂贵的SSD磁盘存储“热”的数据,将更慢一些、便宜一些的机械磁盘存储其他所有的数据。当然,这只是一种短期内可使用的方案,因为这难以维护,并要求大量专业人才去决定每一种磁盘存储哪种数据。长期来看作为一种较为便宜的存储,可以预测基于SSD的方案将发展的更好。但是,在此之前,还是很有必要在大数据与硬件投资之间做出权衡,做合乎两方的选择。

TokuDB的前提

解决这个问题还有一个办法,就是转变逻辑。如果能够在同样大小的磁盘容量中储存更多数据,而且能够存储、读取的更快,那么我们就可能得到更好的结果(从性能方面来讲)并获得存储投资带来的更好回报。这就是在TokuDB存储引擎发展过程中,Tokutek要达到的目标。它架构的核心基于一个不同的、现代的检索方法,名为分形树索引(FTI,Fractal Tree Indexes)。我所说的“不同”在于,大部分流行的存储引擎,比如MyISAM 、 InnoDB,都是基于B树索引。在过去至少30年内,该索引都保持着,作为某种无法挑战的标准。我所说的“现代”,是因为FTI的设计考虑到了写-密集型操作(这种操作在现在的数据系统中出现的越来越频繁)以及最新存储设备易损耗的特性。

两种数据结构都是基于树的,类似地在叶节点中存数数据,并且利用索引Key值加速排序。但是它们通过树来管理与存储数据的方法是不同的。TokuDB以及它的分形树索引与基于B树的InnoDB相比,使用的块大小更大(更大的叶子节点),进而数据能够得到更好的压缩(使用更小磁盘空间的关键技术),也提高了范围查询的性能。同样重要的是,TokuDB称能够通过一个消息传递系统与“优化的”缓存机制来更好的利用I/O。

尽管在基于传统B树的系统中,对表的一个改变会触发索引的相应更新,TokuDB最初会将每一个改变都当做一条消息。有意思的是,在消息到达相应的叶子节点并作出修改之前,它所带来的改变就已经存在于数据库中了。于是,数据库的内容则是叶子节点中存储的数据加上消息循环中的数据。这使存储引擎更加敏捷,举例来说,这会在热模式转换(Hot Schema Changes)中发挥重要的作用。

对于优化的I/O缓存系统的读操作,与更大的叶子节点的使用有关。或者如果你愿意的话,也有另外的方法:更有效的方法来使用缓存,使得更大的叶子节点的使用成为可能。这里提到的有效主要指的是带宽使用程度。需谨记,从消耗的时间来看,对磁盘的I/O远大于对内存的I/O;这就是使用缓存的原因——更频繁的将数据储存于缓冲中(低消耗),就可以减少将缓存“刷到”磁盘的频率(高消耗)。刷到磁盘的缓冲区越满,可以达到的带宽利用率越高。TokuDB试图最大限度的利用缓存,即“对单个I/O进行成千上万次操作”。B树的问题是因为设计的原因,它很难实现一个有效的缓存系统,而人们经常习惯将不太满的缓存刷到磁盘。因此,对于B树来说,更好的方法是在B树中维持小一些的叶子节点,这样产生的副作用是使压缩变差。Tokutek的工程负责人Tim Callaghan 11月份时在Percona Live London解释了对比的各种不同,比我解释的要好得多,

优化使用I/O,使得写操作密集型应用受益良多。目前在我们的Percona Cloud Tools (PCT)中使用TokuDB,用来存储和分析来自MySQL服务器的查询日志。选择TokuDB作为PCT存储设备的另一个好处是压缩性能更好,如果没有这个的话,在PCT服务beta阶段,我们会在支持的用户数上受到很多限制。压缩的影响究竟有多大?就像MySQL中的其他事情一样,这取决于你的模式。据Shlomi Noach报导,他能够把未压缩的InnoDB引擎的4TB数据(或者是使用KEY_BLOCK_SIZE=8压缩的InnoDB引擎的2TB数据)压缩到200GB。这样能够给大家一个感性的认识。

压缩本身就是TokuDB一个很吸引人的特性,但是对于存储空间的大小不是问题的应用场景,这个存储引擎也做的不错。对于写(INSERT)性能而并非网络是性能瓶颈的场景来说,对I/O的优化能够延迟副本操作。如果你需要对一个大表添加一列或者添加第二索引,“热模式转换”功能将助力不少。对于闪存磁盘的持久性也有不少重要影响。Mark Callaghan对于之前的文章做过以下评论:“与InnoDB相比,全磁盘服务器使用TokuDB支持更大的负载压力,全闪存的服务器使用TokuDB是通用的——2倍以上的压缩率(与InnoDB的压缩相比)以及批量的写操作(更多是顺序写)意味着你你可以买更少的闪存、这些闪存可以用更久、买更为廉价的缓存也能够用”。另外,不要忘了TokuDB中让Vadim最赏心悦目的一个特性:支持使用SHOW PROCESSLIST跟踪查询的实时进展。

展望

Tokutek擅长打破传统,并从其他角度出发找到了TokuDB发展中的问题。它受益于MySQL的开放性,使用它的引擎API实现了一个完全不同的方案,该方案脱胎于对现实的深思熟虑——更快的多核CPU、现代却又“脆弱”的存储设备以及对“大数据”的渴望。当然,它也受益于对基于B树的存储引擎的观察,该引擎在过去数十年内处理了不断进化的数据,伴随着新方法和新算法到来,一直让事情变得更加简单。与InnoDB相比,TokuDB更容易进行调优:我统计过共有40个“tokudb_”变量,而“innodb_”有超过100个。但是这还需要时间的考验。尽管我们并不是在讨论一个崭新的引擎(Vadim在5年前就记录过他对该引擎的使用经历),但该引擎最近变成了开源的、公共的,并处于初始阶段。尽管在稳步发展,我们也还是能看到很多未解决的bug。

令人担忧的是目前并没有支持TokuDB的开源热备份软件。尽管有一个“可插拔备份工具标准”在GitHub上提供有HotBackup的API,而目前唯一一个可能存在的热备份方案存在于TokuDB的企业版本中。TokuDB的设计并不适用于“拷贝数据库文件、然后在把存有数据库变化的日志应用到文件上”这样的备份方案,而这正是MySQL Enterprise Backup及Xtrabackup的工作方式,所以现在仍然没有希望,简单扩展一个已存在的开源软件来就可以支持TokuDB,如Percona XtraBackup 之类的软件。

我们将充满希望的看到一个新的开源备份软件到来,它将在不久的未来使用对外的API来实现,但是现在看来多数软件还是基于快照的工具,停留在文件系统水平,如mylvmbackup和 xfs_freeze,它们可以暂时作为未来新方法的替代方案。

 
   

https://dbaplus.cn/news-149-418-1.html

腾讯互娱 DBA

排坑集锦

 

 
   

 

 

 

 

<style></style>

标签:存储,TokuDB,晋级,王者,引擎,InnoDB,MySQL,磁盘
来源: https://www.cnblogs.com/cx2016/p/12010965.html