注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

风轻扬

活着就是为了追求幸福

 
 
 

日志

 
 
关于我

关注互联网应用架构、分布式与海量数据处理技术、云计算、数据库技术

网易考拉推荐

InnoDB发布新版存储引擎插件  

2008-04-20 21:15:36|  分类: MySQL |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
众多周知InnoDB是MySQL中使用的最多的存储引擎,并且迄今为止也还是MySQL中唯一的一个成熟的支持事务的通用存储引擎。不过InnoDB确不是MySQL本公司开发,而是由一家名为Innobase Oy的独立公司开发,并且在05被数据库市场的老大Oracle所收购。从那之后,InnoDB的似乎就停止开发了,两年多以来,除了修修bug,改进了一点点在多CPU机器上的可伸缩性之外,就没推出新版本。因此,业界就有人怀疑Oracle是不是怕MySQL壮大起来之后抢它的饭碗,就把MySQL最重要的存储引擎买过来然后停止开发,来个釜底抽薪。不过在前几天刚刚结束的MySQL年度用户大会上,Oracle的InnoDB开发团队发布了新版的InnoDB,包含了快速索引创建与删除、数据压缩等众多新特性。因此,我想暂时关于Oracle是否会扼杀InnoDB的疑虑可以打消了。关注MySQL的人应该都知道,MySQL存储引擎界现在已经进入百家争鸣的阶段,Falcon和Maria都明确提出要争当InnoDB之后存储引擎的老大。一个更好的InnoDB将促使Falcon和Maria的开发团队更加努力,创造出比InnoDB更好的产品。对于用户来说,能够免费享受到更好的数据库技术真是有福。好了,现在来仔细看看这个InnoDB的新版本有什么新功能吧,需要注意的是目前还只是的测试版。

首先是快速索引创建与删除。可能很多人都知道,MySQL执行创建或删除索引的流程是先创建一张临时表,其中包含要创建的索引或已经删除要删除的索引,然后将原表中的数据一行一行的插入到临时表中,完成后再后临时表来代替原来的表。使用这一技术,MySQL可以实现几乎万能的ALTER TABLE,用户使用非常方便。但由于插入的时候数据不是按索引的顺序排序的,会导致大量的索引访问随机IO和B+树的分裂,创建与删除索引的性能很低,如果内存太小装不下所有索引时的性能根本就无法接受。数据库界创建索引的标准方式是先将数据按索引键排好序,然后按顺序填到各个索引节点里,这时的性能将远远高于上述随机插入的方法。新版InnoDB即是使用这一方法。这一方法的优点除速度快之外,由于没有随机插入导致的B+树分裂,创建出的索引空间利用率也会比较好。另外删除索引时只需要找到索引占用的页面,把它们释放掉即可,新版InnoDB中删除索引将是非常的快。关于这一功能的一些其它要点如下:
1. 使用一条ALTER TABLE语句同时创建多个索引时由于只需要扫描主索引一次,速度仍然比用多条ALTER TABLE语句快;
2. 上述功能只用于创建/删除二级索引,修改主索引(通常是主键)时仍然是用原来的拷贝表的方式;
3. 新算法并不改变创建所得索引的数据格式,因此使用新版InnoDB创建出的索引老的InnoDB也可用,因此理论上可以在创建索引时暂时用一下新版InnoDB,完成后马上切回老版。不过测试版还是要小心点。

第二个重要的新功能是数据压缩,这个在InnoDB以前的发展计划中就已经提到过。虽然早在多年前就有很多数据库研究人员号称内存容量越来越大,将来数据库基本上都可以完成装在内存里,因此发展内存数据库技术才是正经。或许一些传统OLTP应用是这样吧,Web 2.0一来,用户产生内容,那个数据量马上不是一般的大,比如我们博客的数据库都有好几T了,因此看来内存总是不够用,磁盘IO在很长一段时间内将还是数据库应用的主要瓶颈,或许要等SSD这种技术成熟之后才可能改变。算法优先时常用无非时间换空间或空间换时间两招,新InnoDB的数据压缩就是用(CPU)时间来换(磁盘)空间。

首先管理员需要对每张表指定压缩后的目标页大小KEY_BLOCK_SIZE,可以是1至16K。未压缩的InnoDB页是16K,系统会尝试将每个页用zlib压缩,简单的来说就是把整页内容拿来用zip压缩一把,如果大小不超过KEY_BLOCK_SIZE,则该页就可以以压缩形式存储成KEY_BLOCK_SIZE大小的页。如果超过就要进行B+树分裂。为了减少压缩解压的开销,B+树中的一些系统信息不压缩,如记录是否被删除标记位等。另外并不是每次更新都要把整页解压出来,更新后再压缩回去,而是新缓存一些未压缩的操作,等页满了之后再重新压缩。专用于存储TEXT、BLOB类型的页面也使用zlib压缩,而且效果通常也会更明显。另外老版本的InnoDB中,如果TEXT等类型的数据在B+树页中存储不下仍然会存储768字节的前缀,现在只会存储一个20字节的指针(如果在B+树中能放下时仍然内联存储)。需要注意的是要使用压缩必须使用innodb_file_per_table选项,因为第一个表空间,即名字如ibdata*的表空间中存储了InnoDB内部的系统表,不会被压缩。

启动压缩后,数据在磁盘上基本上以压缩后的格式存储,在缓冲区中则可能存储压缩前或压缩后的数据,或两者都有。一个B+树页被用来搜索之前需要进行解压,因此如果一个页经常会访问,缓冲区中一般会缓存未压缩的页,压缩后的页由于访问频率低会被替换出去。反之,如果一个页不太经常被访问,缓冲区中一般会缓存压缩后的页,这时同样大小的缓冲区就可以缓存更多的页,减少IO次数。

不过我对InnoDB的这套数据压缩技术持保留意见。首先是KEY_BLOCK_SIZE的设置就给管理员带来很大负担,太大会浪费空间,太小则更新操作导致压缩解压操作会增加影响性能。另外对于B+树来说最方便实现,性价比最好的应该是前缀压缩,不过实现要麻烦些。InnoDB选用zlib来进行页级的压缩总感觉是一种投机取巧的方法,易于实现但很难保证效率的稳定。估计只有那些包含很多长字符串,且更新很少的表用这个压缩比较好。
  评论这张
 
阅读(927)| 评论(1)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017