[转]基于SSD的数据库性能优化

标签: 数据库性能优化磁盘loggingbuffercache
2744人阅读 评论(0) 收藏 举报
分类:

NOR和NAND

NOR和NAND都是闪存技术的一种,NOR是Intel公司开发的,它有点类似于内存,允许通过地址直接访问任何一个内存单元,缺点是:密度低(容量小),写入和擦除的速度很慢。NAND是东芝公司开发的,它密度高(容量大),写入和擦除的速度都很快,但是必须通过特定的IO接口经过地址转换之后才可以访问,有些类似于磁盘。

我们现在广泛使用的U盘,SD卡,SSD都属于NAND类型,厂商将flash memory封装成为不同的接口,比如Intel的SSD就是采用了SATA的接口,访问与普通SATA磁盘一样,还有一些企业级的闪存卡,比如FusionIO,则封装为PCIe接口。

SLC和MLC

SLC是单极单元,MLC是多级单元,两者的差异在于每单元存储的数据量(密度),SLC每单元只存储一位,只包含0和1两个电压符,MLC每单元可以存储两位,包含四个电压符(00,01,10,11)。显然,MLC的存储容量比SLC大,但是SLC更简单可靠,SLC读取和写入的速度都比MLC更快,而且SLC比MLC更耐用,MLC每单元可擦除1w次,而SLC可擦除10w次,所以,企业级的闪存产品一般都选用SLC,这也是为什么企业级产品比家用产品贵很多的原因。

SSD的技术特点

SSD与传统磁盘相比,第一是没有机械装置,第二是由磁介质改为了电介质。在SSD内部有一个FTL(Flash Transalation Layer),它相当于磁盘中的控制器,主要功能就是作地址映射,将flash memory的物理地址映射为磁盘的LBA逻辑地址,并提供给OS作透明访问。

SSD没有传统磁盘的寻道时间和延迟时间,所以SSD可以提供非常高的随机读取能力,这是它的最大优势,SLC类型的SSD通常可以提供超过35000的IOPS,传统15k的SAS磁盘,最多也只能达到160个IOPS,这对于传统磁盘来说几乎就是个天文数字。SSD连续读的能力相比普通磁盘优势并不明显,因为连续读对于传统磁盘来说,并不需要寻道时间,15k的SAS磁盘,连续读的吞吐能力可以达到130MB,而SLC类型的SSD可以达到170-200MB,我们看到在吞吐量方面,SSD虽然比传统磁盘高一些,但优势虽然并不明显。

SSD的写操作比较特殊,SSD的最小写入单元为4KB,称为页(page),当写入空白位置时可以按照4KB的单位写入,但是如果需要改写某个单元时,则需要一个额外的擦除(erase)动作,擦除的单位一般是128个page(512KB),每个擦除单元称为块(block)。如果向一个空白的page写入信息时,可以直接写入而无需擦除,但是如果需要改写某个存储单元(page)的数据,必须首先将整个block读入缓存,然后修改数据,并擦除整个block的数据,最后将整个block写入,很显然,SSD改写数据的代价很高,SSD的这个特性,我们称之为erase-before-write。

经过测试,SLC SSD的随即写性能可以达到3000个左右的IOPS,连续写的吞吐量可以达到170-200MB,这个数据还是比传统磁盘高出不少。但是,随着SSD的不断写入,当越来越多的数据需要被改写时,写的性能就会逐步下降。经过我们的测试,SLC在这个方面要明显好于MLC,在长时间写入后,MLC随机写IO下降得非常厉害,而SLC表现则比较稳定。为了解决这个问题,各个厂商都有很多策略来防止写性能下降的问题。

wear leveling

因为SSD存在“写磨损”的问题,当某个单元长时间被反复擦写时(比如Oracle redo),不仅会造成写入的性能问题,而且会大大缩短SSD的使用寿命,所以必须设计一个均衡负载的算法来保证SSD的每个单元能够被均衡的使用,这就是wear leveling,称为损耗均衡算法。

Wear leveling也是SSD内部的FTL实现的,它通过数据迁移来达到均衡损耗的目的。Wear leveling依赖于SSD中的一部分保留空间,基本原理是在SSD中设置了两个block pool,一个是free block pool(空闲池),一个是数据池(data block pool),当需要改写某个page时(如果写入原有位置,必须先擦除整个block,然后才能写入数据),并不写入原有位置(不需要擦除的动作),而是从空闲池中取出新的block,将现有的数据和需要改写的数据合并为新的block,一起写入新的空白block,原有的block被标识为invalid状态(等待被擦除回收),新的block则进入数据池。后台任务会定时从data block中取出无效数据的block,擦除后回收到空闲池中。这样做的好处在于,一是不会反复擦写同一个block,二是写入的速度会比较快(省略了擦除的动作)。

Wear leveling分为两种:动态损耗均衡和静态损耗均衡,两者的原理一致,区别在于动态算法只会处理动态数据,比如数据改写时才会触发数据迁移的动作,对静态数据不起作用,而静态算法可以均衡静态数据,当后台任务发现损耗很低的静态数据块时,将其迁移到其他数据库块上,将这些块放入空闲池中使用。从均衡的效果来看,静态算法要好于动态算法,因为几乎所有的block都可以被均衡的使用,SSD的寿命会大大延长,但是静态算法的缺点是当数据迁移时,可能会导致写性能下降。

写入放大

因为SSD的erase-before-write的特性,所以就出现了一个写入放大的概念,比如你想改写4K的数据,必须首先将整个擦除块(512KB)中的数据读出到缓存中,改写后,将整个块一起写入,这时你实际写入了512KB的数据,写入放大系数是128。写入放大最好的情况是1,就是不存在放大的情况。

Wear leveling算法可以有效缓解写入放大的问题,但是不合理的算法依然会导致写入放大,比如用户需要写入4k数据时,发现free block pool中没有空白的block,这时就必须在data block pool中选择一个包含无效数据的block,先读入缓存中,改写后,将整个块一起写入,采用wear leveling算法依然会存在写入放大的问题。

通过为SSD预留更多空间,可以显著缓解写入放大导致的性能问题。根据我们的测试结果,MLC SSD在长时间的随机写入后,性能下降很明显(随机写IOPS甚至降低到300)。如果为wear leveling预留更多空间,就可以显著改善MLC SSD在长时间写操作之后的性能下降问题,而且保留的空间越多,性能提升就越明显。相比较而言,SLC SSD的性能要稳定很多(IOPS在长时间随机写后,随机写可以稳定在3000 IOPS),我想应该是SLC SSD的容量通常比较小(32G和64G),而用于wear leveling的空间又比较大的原因。

数据库IO特点分析

IO有四种类型:连续读,随机读,随机写和连续写,连续读写的IO size通常比较大(128KB-1MB),主要衡量吞吐量,而随机读写的IO size比较小(小于8KB),主要衡量IOPS和响应时间。数据库中的全表扫描是连续读IO,索引访问则是典型的随机读IO,日志文件是连续写IO,而数据文件则是随机写IO。

数据库系统基于传统磁盘访问特性来设计,最大特点是日志文件采用sequential logging,数据库中的日志文件,要求必须在事务提交时写入到磁盘,对响应时间的要求很高,所以设计为顺序写入的方式,可以有效降低磁盘寻道花费的时间,减少延迟时间。日志文件的顺序写入,虽然是物理位置是连续的,但是并不同于传统的连续写类型,日志文件的IO size很小(通常小于4K),每个IO之间是独立的(磁头必须抬起来重新寻道,并等待磁盘转动到相应的位置),而且间隔很短,数据库通过log buffer(缓存)和group commit的方式(批量提交)来达到提高IO size的大小,并减少IO的次数,从而得到更小的响应延迟,所以日志文件的顺序写入可以被认为是“连续位置的随机写入”,瓶颈还是在IOPS,而不是吞吐量。

数据文件采用in place update的方式,意思是数据文件的修改都是写入到原来的位置,数据文件不同于日志文件,并不会在事务commit时写入数据文件,只有当数据库发现dirty buffer过多或者需要做checkpoint动作时,才会刷新这些dirty buffer到相应的位置,这是一个异步的过程,通常情况下,数据文件的随机写入对IO的要求并不是特别高,只要满足checkpoint和dirty buffer的要求就可以了。

SSD的IO特点分析

1.随机读能力非常好,连续读性能一般,但比普通SAS磁盘好。

2.不存在磁盘寻道的延迟时间,随机写和连续写的响应延迟差异不大。

3.erase-before-write特性,造成写入放大,影响写入的性能。

4.写磨损特性,采用wear leveling算法延长寿命,但同时会影响读的性能。

5.读和写的IO响应延迟不对等(读要大大好于写),而普通磁盘读和写的IO响应延迟差异很小。

6.连续写比随机写性能好,比如1M顺序写比128个8K的随即写要好很多,因为随即写会带来大量的擦除。

基于SSD的上述特性,如果将数据库全部放在SSD上,可能会有以下的问题:

1.日志文件sequential logging会反复擦写同一位置,虽然有损耗均衡算法,但是长时间写入依然会导致性能下降。

2.数据文件in place update会产生大量的随机写入,erase-before-write会产生写入放大。

3.数据库读写混合型应用,存在大量的随机写入,同时会影响读的性能,产生大量的IO延迟。

基于SSD的数据库优化法则

基于SSD的优化就是解决erase-before-write产生的写入放大的问题,不同类型的IO分离,减少写操作带来的性能影响。

1.将sequential logging修改为In-page logging,避免对相同位置的反复擦写。

2.通过缓存写入的方式将大量的in-place update随机写入合并为少量顺序写入。

3.利用SSD随机读写能力高的特点,减少写增加读,从而达到整体性能的提升。

In-page logging

In-page logging是基于SSD对数据库sequential logging的一种优化方法,数据库中的sequential logging对传统磁盘是非常有利的,可以大大提高响应时间,但是对于SSD就是噩梦,因为需要对同一位置反复擦写,而wear leveling算法虽然可以平衡负载,但是依然会影响性能,并产生大量的IO延迟。所以In-page logging将日志和数据合并,将日志顺序写入改为随机写入,基于SSD对随机写和连续写IO响应延迟差异不大的特性,避免对同一位置反复擦写,提高整体性能。

In-page logging基本原理:在data buffer中,有一个in-memory log sector的结构,类似于log buffer,每个log sector是与data block对应的。在data buffer中,data和log并不合并,只是在data block和log sector之间建立了对应关系,可以将某个data block的log分离出来。但是,在SSD底层的flash memory中,数据和日志是存放在同一个block(擦除单元),每个block都包含data page和log page。

当日志信息需要写入的时候(log buffer空间不足或者事务提交),日志信息会写入到flash memory对应的block中,也就是说日志信息是分布在很多不同的block中的,而每个block内的日志信息是append write,所以不需要擦除的动作。当某个block中的log sector写满的时候,这时会发生一个动作,将整个block中的信息读出,然后应用block中的log sector,就可以得到最新的数据,然后整个block写入,这时,block中的log sector是空白的。

在in-page logging方法中,data buffer中的dirty block是不需要写入到flash memory中的,就算dirty buffer需要被交换出去,也不需要将它们写入flash memory中。当需要读取最新的数据,只要将block中的数据和日志信息合并,就可以得到最新的数据。

In-page logging方法,将日志和数据放在同一个擦除单元内,减少了对flash相同位置的反复擦写,而且不需要将dirty block写入到flash中,大量减少了in-place update的随机写入和擦除的动作。虽然在读取时,需要做一个merge的操作,但是因为数据和日志存放在一起,而且SSD的随机读取能力很高,in-page logging可以提高整体的性能。

SSD作为写cache—append write

SSD可以作为磁盘的写cache,因为SSD连续写比随机写性能好,比如:1M顺序写比128个8K的随机写要好很多,我们可以将大量随机写合并成为少量顺序写,增加IO的大小,减少IO(擦除)的次数,提高写入性能。这个方法与很多NoSQL产品的append write类似,即不改写数据,只追加数据,需要时做合并处理。

基本原理:当dirty block需要写入到数据文件时,并不直接更新原来的数据文件,而是首先进行IO合并,将很多个8K的dirty block合并为一个512KB的写入单元,并采用append write的方式写入到一个cache file中(保存在SSD上),避免了擦除的动作,提高了写入性能。cache file中的数据采用循环的方式顺序写入,当cache file空间不足够时,后台进程会将cache file中的数据写入到真正的数据文件中(保存在磁盘上),这时进行第二次IO合并,将cache file内的数据进行合并,整合成为少量的顺序写入,对于磁盘来说,最终的IO是1M的顺序写入,顺序写入只会影响吞吐量,而磁盘的吞吐量不会成为瓶颈,将IOPS的瓶颈转化为吞吐量的瓶颈,从而提升了整体系统能力。

读取数据时,必须首先读取cache file,而cache file中的数据是无序存放的,为了快速检索cache file中的数据,一般会在内存中为cache file建立一个索引,读取数据时会先查询这个索引,如果命中查询cache file,如果没有命中,再读取data file(普通磁盘),所以,这种方法实际不仅仅是写cache,同时也起到了读cache的作用。

SSD并不适合放数据库的日志文件,虽然日志文件也是append write,但是因为日志文件的IO size比较小,而且必须同步写入,无法做合并处理,对SSD来说,需要大量的擦除动作。我们也曾经尝试把redo log放在SSD上,考虑到SSD的随机写入也可以达到3000 IOPS,而且响应延时比磁盘低很多,但是这依赖于SSD本身的wear leveling算法是否优秀,而且日志文件必须是独立存放的,如果日志文件的写入是瓶颈,也算是一种解决方案吧。通常情况下,我还是建议日志文件放在普通磁盘上,而不是SSD。

SSD作为读cache—flashcache

因为大部分数据库都是读多写少的类型,所以SSD作为数据库flashcache是优化方案中最简单的一种,它可以充分利用SSD读性能的优势,又避免了SSD写入的性能问题。实现的方法有很多种,可以在读取数据时,将数据同时写入SSD,也可以在数据被刷出buffer时,写入到SSD。读取数据时,首先在buffer中查询,然后在flashcache中查询,最后读取datafile。

SSD作为flashcache与memcache作为数据库外部cache的最大区别在于,SSD掉电后数据是不丢失的,这也引起了另外一个思考,当数据库发生故障重启后,flashcache中的数据是有效还是无效?如果是有效的,那么就必须时刻保证flashcache中数据的一致性,如果是无效的,那么flashcache同样面临一个预热的问题(这与memcache掉电后的问题一样)。目前,据我所知,基本上都认为是无效的,因为要保持flashcache中数据的一致性,非常困难。

flashcache作为内存和磁盘之间的二级cache,除了性能的提升以外,从成本的角度看,SSD的价格介于memory和disk之间,作为两者之间的一层cache,可以在性能和价格之间找到平衡。

总结

随着SSD价格不断降低,容量和性能不断提升,SSD取代磁盘只是个时间问题。

Tape is Dead,Disk is Tape,Flash is Disk,RAM Locality is King.        Jim Gray

–EOF–

后续,我还会整理一个PPT,并提供一个技术分享。

 

来源:http://www.hellodba.net/2010/10/ssd-database-2.html

 

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:3913372次
    • 积分:42336
    • 等级:
    • 排名:第86名
    • 原创:331篇
    • 转载:511篇
    • 译文:5篇
    • 评论:1256条
    文章存档
    最新评论