如何在数据库应用中发挥SSD的优势
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了如何在数据库应用中发挥SSD的优势相关的知识,希望对你有一定的参考价值。
利用固态硬盘(SSD)技术的优势设计数据库应用架构是非常有吸引力的一件事。特别值得注意的是,固态硬盘并行访问数据的能力已经有了很大的提升。这些提升使得固态硬盘对于许多类型的数据库应用几乎能达到了随机访问内存存储的性能,而成本只是其八分之一。在过去的几年里,固态硬盘的性能得到了突飞猛进的增长,同时相比于传统硬盘和RAM,其成本却在持续降低。但是要利用好这些改进的优势,需要掌握存储特性选择合适的AWS实例大小,理解应用特性并利用合适的编程语言。
掌握AWS选项
AWS IaaS EC2实例可以配置不同级别的存储:
A)内存。对应于传统物理计算机的RAM。
B)实例存储。也称为临时存储。它对应于传统物理计算机的磁盘大小。
C)灵活的持久化补充存储(比如EBS和S3)。基本上可以把它视为物理PC的网络存储。
Amazon现在把SSD作为部署临时存储和通用存储的默认配置,也是EBS的默认配置(早期的实例类型默认不是SSD)。EBS的其它好处是存储系统可以在数据库服务器本身退役以后仍然继续可用。
此外,AWS还提供SSD存储作为Amazon DynamoDB的默认选项。SSD同时也是Amazon RDS和Amazon
Redshift的可选配置。这个配置非常好,它可以降低数据库应用需要的开发代价。但是,如果企业需要部署其它数据库,也有很多其它可配置项可以帮助他
们利用到SSD的并行特性。
并行存储的物理原理
物理计算机通常设置有三种主要存储类型。RAM安装在主板上,紧挨着CPU,它提供最高的性能,成本代价也最高,计算机关闭以后内容不会保存。
SSD和传统硬盘是连接到计算机上的补充存储,通过PCI-e,SCSI和SATA线缆连接,或者在网络上通过eSATA或者光纤通道连接。
传统硬盘包含有一个物理读写头,一次可以跨多个物理盘片读取数据流。如果数据可以顺序读取(比如读取较大的多媒体视频音频文件),或者对于一些
数据库分析应用(比如Hadoop应用),这种模式都非常合适。然而,如果读取数据要搜索盘片的多个扇区,那么传统硬盘读写头的性能会急剧下降。
与此相反,闪存驱动的物理构成就是成百上千个可以随机访问的块,是由分散的许多芯片组成的,读取哪一块的数据不会影响访问性能。闪存盘有两个瓶颈:第一就是计算机处理器和个体芯片储存区之间的存储控制器;第二是不能从单个芯片上的不同块区同时读取随机数据。
当今时代的大部分数据库引擎都没有利用闪存盘访问数据随机位的功能优势。其结果是,数据库都比较慢,或者虽然其访问模式可以被缓存,但需要更多
RAM才能实现同样的性能效果。而RAM存储肯定比闪存盘速度快,不过对于相同数量的存储空间,RAM的成本是闪存盘的十倍。在物理层面上,RAM比
SSD有更好的IO处理能力,但是成本也是其大约三到四倍。这些相对成本也被反映到了Amazon Web服务上可用的不同计算机实例相对成本上。
写入队列
利用跨多个芯片并行访问数据能力优势的关键在于编写程序时要考虑到队列深度这一特性。在数据库应用中增加队列深度可以使应用从SSD不同个体芯片中并行读写数据,这对提高数据库性能有直接的效果。
如果队列深度设置过大,访问同一芯片中不同数据位的可能性就增大了,这也会破坏性能。因此,大部分应用的最佳队列深度是每驱动器32到64个并
发请求,尽管驱动器本身支持更多并发请求。通过优化数据库应用访问SSD的队列深度,应用程序可以花更少的代价就能达到用更昂贵RAM才能实现的更佳性能
状态。
在应用层面,开发者需要考虑如何实现应用对存储系统的请求队列化,以实现并行处理。但是,软件方面要获得较好的并行有许多陷阱。要用像
JavaScript、Ruby和Python这样的编程语言实现并行是很困难的,因为这些语言对实现多线程支持的不太好,Java和C#相对更容易一
些。
C和C++是实现高并发系统代码最合适的编程语言,因为它们直接操作操作系统核心功能。例如,互斥扩展(也叫互斥量)就是简化编程生成低级系统并行调用的语言特性。另一种选择是使用自带SSD存储优化方案的商业数据库,比如Aerospike。
为应用选择合适的架构
不是所有的数据库应用都需要闪存存储功能来并行访问随机数据。处理大量并发用户Web请求的数据库很容易看到闪存存储的最大优势。
与此相反,像Hadoop这种分析应用在某种意义上是并行的,但是通常这些应用最后都需要访问存储驱动器上的大量数据流来完成数据访问。例如,
处理一个月的用户日志来分析其行为或者分析用户,本质上都要按顺序提取数据,因此迁移到SSD并不能带来太多益处。在这两种极端场景之间,还有一些实时分
析类型的应用,它们既需要一定的随机搜索和也需要数据流处理。
专家建议,充分利用各种层次成本差异的一种方式是,配置数据库利用临时存储读取数据以获得最佳性能。这一点可以通过存储在EBS持久化数据层的数据进行备份。这种方案提供了AWS上价格和性能的最佳平衡组合。
后台进程也需要考虑
数据库应用架构师还应该考虑其它细微特征。要理解数据库软件如何利用RAM,如何把数据刷到磁盘,这些对于优化SSD应用配置非常重要。这对于
评估数据库与文件系统交互的各种方式也非常重要。最明显的读负载繁重会有大量后台IO竞争。而其他进程像报表系统、日志文件生成是需要后台维护的。
要想找到合适的平衡点,专家建议以真实世界部署的强大指标为基准进行参考。这样可以帮助企业判断部署和优化SSD系统有多大益处。不过,在RAM和SSD之间选择,最重要的考虑因素是深刻掌握要处理的数据集大小。
配置合适的SSD和RAM容量有许多种组合,会增加数据库更高的复杂度。更多的是传统数据库系统,它们会部署一台主服务器和许多备用服务器用于
故障恢复,除了在磁盘级别的情况它们的配置都很简单。另一方面,分布式数据库系统根据节点数量不同,RAM数量和网络设置的不同会有更多的变化。
尽管在大多数情况下,如果你关注技术的力量和数据库系统的可操作性作为选择硬件驱动器的考虑因素,那么你需要比较评估的系统应该相对不会很多。 参考技术A 利用固态硬盘(SSD)技术的优势设计数据库应用架构是非常有吸引力的一件事。特别值得注意的是,固态硬盘并行访问数据的能力已经有了很大的提升。这些提升使得固态硬盘对于许多类型的数据库应用几乎能达到了随机访问内存存储的性能,而成本只是其八分之一。
在过去的几年里,固态硬盘的性能得到了突飞猛进的增长,同时相比于传统硬盘和RAM,其成本却在持续降低。但是要利用好这些改进的优势,需要掌握存储特性选择合适的AWS实例大小,理解应用特性并利用合适的编程语言。
掌握AWS选项
AWS IaaS EC2实例可以配置不同级别的存储:
A)内存。对应于传统物理计算机的RAM。
B)实例存储。也称为临时存储。它对应于传统物理计算机的磁盘大小。
C)灵活的持久化补充存储(比如EBS和S3)。基本上可以把它视为物理PC的网络存储。
Amazon现在把SSD作为部署临时存储和通用存储的默认配置,也是EBS的默认配置(早期的实例类型默认不是SSD)。EBS的其它好处是存储系统可以在数据库服务器本身退役以后仍然继续可用。
此外,AWS还提供SSD存储作为Amazon DynamoDB的默认选项。SSD同时也是Amazon RDS和Amazon
Redshift的可选配置。这个配置非常好,它可以降低数据库应用需要的开发代价。但是,如果企业需要部署其它数据库,也有很多其它可配置项可以帮助他
们利用到SSD的并行特性。
并行存储的物理原理
物理计算机通常设置有三种主要存储类型。RAM安装在主板上,紧挨着CPU,它提供最高的性能,成本代价也最高,计算机关闭以后内容不会保存。
SSD和传统硬盘是连接到计算机上的补充存储,通过PCI-e,SCSI和SATA线缆连接,或者在网络上通过eSATA或者光纤通道连接。
传统硬盘包含有一个物理读写头,一次可以跨多个物理盘片读取数据流。如果数据可以顺序读取(比如读取较大的多媒体视频音频文件),或者对于一些
数据库分析应用(比如Hadoop应用),这种模式都非常合适。然而,如果读取数据要搜索盘片的多个扇区,那么传统硬盘读写头的性能会急剧下降。
与此相反,闪存驱动的物理构成就是成百上千个可以随机访问的块,是由分散的许多芯片组成的,读取哪一块的数据不会影响访问性能。闪存盘有两个瓶颈:第一就是计算机处理器和个体芯片储存区之间的存储控制器;第二是不能从单个芯片上的不同块区同时读取随机数据。
当今时代的大部分数据库引擎都没有利用闪存盘访问数据随机位的功能优势。其结果是,数据库都比较慢,或者虽然其访问模式可以被缓存,但需要更多
RAM才能实现同样的性能效果。而RAM存储肯定比闪存盘速度快,不过对于相同数量的存储空间,RAM的成本是闪存盘的十倍。在物理层面上,RAM比
SSD有更好的IO处理能力,但是成本也是其大约三到四倍。这些相对成本也被反映到了Amazon Web服务上可用的不同计算机实例相对成本上。
写入队列
利用跨多个芯片并行访问数据能力优势的关键在于编写程序时要考虑到队列深度这一特性。在数据库应用中增加队列深度可以使应用从SSD不同个体芯片中并行读写数据,这对提高数据库性能有直接的效果。
如果队列深度设置过大,访问同一芯片中不同数据位的可能性就增大了,这也会破坏性能。因此,大部分应用的最佳队列深度是每驱动器32到64个并
发请求,尽管驱动器本身支持更多并发请求。通过优化数据库应用访问SSD的队列深度,应用程序可以花更少的代价就能达到用更昂贵RAM才能实现的更佳性能
状态。
在应用层面,开发者需要考虑如何实现应用对存储系统的请求队列化,以实现并行处理。但是,软件方面要获得较好的并行有许多陷阱。要用像
JavaScript、Ruby和Python这样的编程语言实现并行是很困难的,因为这些语言对实现多线程支持的不太好,Java和C#相对更容易一
些。
C和C++是实现高并发系统代码最合适的编程语言,因为它们直接操作操作系统核心功能。例如,互斥扩展(也叫互斥量)就是简化编程生成低级系统并行调用的语言特性。另一种选择是使用自带SSD存储优化方案的商业数据库,比如Aerospike。
为应用选择合适的架构
不是所有的数据库应用都需要闪存存储功能来并行访问随机数据。处理大量并发用户Web请求的数据库很容易看到闪存存储的最大优势。
与此相反,像Hadoop这种分析应用在某种意义上是并行的,但是通常这些应用最后都需要访问存储驱动器上的大量数据流来完成数据访问。例如,
处理一个月的用户日志来分析其行为或者分析用户,本质上都要按顺序提取数据,因此迁移到SSD并不能带来太多益处。在这两种极端场景之间,还有一些实时分
析类型的应用,它们既需要一定的随机搜索和也需要数据流处理。
专家建议,充分利用各种层次成本差异的一种方式是,配置数据库利用临时存储读取数据以获得最佳性能。这一点可以通过存储在EBS持久化数据层的数据进行备份。这种方案提供了AWS上价格和性能的最佳平衡组合。
后台进程也需要考虑
数据库应用架构师还应该考虑其它细微特征。要理解数据库软件如何利用RAM,如何把数据刷到磁盘,这些对于优化SSD应用配置非常重要。这对于
评估数据库与文件系统交互的各种方式也非常重要。最明显的读负载繁重会有大量后台IO竞争。而其他进程像报表系统、日志文件生成是需要后台维护的。
要想找到合适的平衡点,专家建议以真实世界部署的强大指标为基准进行参考。这样可以帮助企业判断部署和优化SSD系统有多大益处。不过,在RAM和SSD之间选择,最重要的考虑因素是深刻掌握要处理的数据集大小。
配置合适的SSD和RAM容量有许多种组合,会增加数据库更高的复杂度。更多的是传统数据库系统,它们会部署一台主服务器和许多备用服务器用于
故障恢复,除了在磁盘级别的情况它们的配置都很简单。另一方面,分布式数据库系统根据节点数量不同,RAM数量和网络设置的不同会有更多的变化。
尽管在大多数情况下,如果你关注技术的力量和数据库系统的可操作性作为选择硬件驱动器的考虑因素,那么你需要比较评估的系统应该相对不会很多。本回答被提问者采纳
NVDIMM在闪存存储中的应用探讨
SSD作为新型存储介质对外暴露成一种通用块设备,传统应用似乎无需任何改变就可以在SSD上运行。在实际应用过程中,传统业务的确可以在SSD上直接运行,但问题是SSD并没有被充分利用,优势没有被充分发挥;更糟糕的是业务的IO特性会导致SSD出现新的问题。例如,在有些应用现场,用户发现SSD的使用寿命被很快耗尽,写放大系统变得很大,使用寿命与预期不同。厂商的写放大系统是在特定的IO Pattern下测算出来的,实际应用由于存在大量的512字节小写问题,数据分布不够“完美”,从而导致SSD内部的写放大系数比预期要大,从而影响SSD的使用寿命。一句话,SSD的使用不是那么简单的,其与业务的IO Pattern息息相关。如果想在企业级SSD上获取足够的性能、一致性以及使用寿命,那么需要面向SSD对存储软件栈进行重构。重构过程的一个思路是通过优化输入SSD的IO Pattern,来获取SSD的最佳工作状态,发挥SSD的性能、避免SSD的问题。
在IO Pattern的优化方法中,正在蓬勃发展的NVDIMM需要尤其关注。可以这么讲,在技术上NVDIMM和SSD是天生一对,他俩可以特性互补,短期内共存发展。NVDIMM其实并非一个革命性、全新的东西,很多磁盘存储系统早就采用NVRAM技术来实现掉电非易失的缓存。这种NVRAM基于PCIe总线,通过电池保证系统在断电情况下的数据可靠性。NVRAM在存储系统中通常会作为数据缓存。为了保证数据可靠性,一个系统中会设计两块NVRAM,通过Mirror的方式冗余数据。NVDIMM与NVRAM相比,最大的差别是将接口从PCIe转移到了DIMM(内存接口),其次在掉电数据保护方面通过NAND Flash和超级电容相结合的方式保证数据不丢,或者直接采用新型存储介质,例如Xpoint、ReRAM等。
在层次化存储系统中,NVDIMM的性能基本和DDR内存的性能是相同的。在性能上远远超过了SSD,其IO访问延迟在几十至几百纳秒左右,而SSD的访问延迟则达到了百微妙以上。但是,SSD在容量上要远远高于NVDIMM。因此,在现有的分层存储体系架构中,引入NVDIMM可以很好的对SSD、磁盘存储进行优化,尤其是IO Pattern方面的优化。
在设计闪存存储系统的时候,2014年第一次开始使用NVDIMM,那时关于NVDIMM的标准刚刚开始由SNIA组织制定。那时的NVDIMM基本都是SLC NAND + SDRAM + SuperCap的设计方式,工作原理也基本相同,这种NVDIMM就是我们现在标准中的NVDIMM-N。随后在2015年以及2016延伸出另外两个NVDIMM产品标准,分别为NVDIMM-F和NVDIMM-P,这些产品的工作原理、形态都会有所不同。从下图可以看出NVDIMM产品标准的演进方向。不同的NVDIMM产品具有不同的应用场景。在存储系统中常用来替代NVRAM的产品形态为NVDIMM-N。
在现有的标准体系中,主要的产品形态有NVDIMM-N、NVDIMM-F以及NVDIMM-P,各自特性如下图所示。其中NVDIMM-N是最早的产品形态,在存储中用来替代NVRAM之类的应用,在系统中通过访存的方式对其进行访问。在性能上NVDIMM-N和普通的DDR内存是相同的,所不同的是在系统掉电的情况下,NVDIMM-N中的数据会被同步写入到内存条上的SLC NAND Flash中。整个掉电过程由超级电容来进行供电。NVDIMM-F是将Flash做成DIMM接口的块设备,通过块设备接口对其进行访问。有一些存储公司在做这样的产品,通过这种方式可以进一步避免由于PCIe总线引入的SSD访问延迟。由于直接通过DIMM接口访问NAND Flash,所以,NVDIMM-F的性能没有办法与NVDIMM-N相对比。通过采用NVDIMM-F形态的SSD,可以构建高密闪存存储系统,但是缺点是需要定制化服务器平台。最新提出的NVDIMM-P是一种综合NVDIMM-N和NVDIMM-F的产品形态,其技术架构于上述两种都有所不同,最大想法是混合内存与NAND Flash,并且提供块设备以及内存的访问接口,在性能上也介于NVDIMM-N和NVDIMM-F之间,容量要远大于NVDIMM-N,可以做到和NVDIMM-F相同的存储容量。
NVDIMM-N是最早提出的产品形态,默认所说的NVDIMM就是这种产品形态。NVDIMM-N的原理如下图所示:
从上图可以看出,内存总线通过Buffer开关可以直接访问DRAM,所以,没有引入额外的IO延迟。在正常使用过程中,NVDIMM-N在系统中就是一片普通内存。在该子系统中我们可以发现有一个称之为Cntlr的控制器,早期产品该控制器都是采用FPGA来实现,通过该控制器可以实现内存数据的持久化与加载操作。当控制器接收到SAVE命令信号后,将DRAM中的数据保存到NAND;在系统重新上电之后,从NAND中加载数据至DRAM中。正因为这个控制器的作用,才保证了在系统异常断电情况下的DRAM数据不丢失。和NVDIMM-P相比,操作系统无法直接访问NAND中的数据。对于NVDIMM-N而言,其一个很重要的技术点是如何在掉电的情况下触发内存数据的持久化操作。在早期的NVDIMM-N设计中,通常需要特殊主板的支持。在该类主板中存在一个硬件单元,例如采用CPLD对电源进行监测,当发现系统电源低于预期时,开始触发处理器进行掉电保护。在该类设计中,操作系统会存在一个驱动程序,该驱动程序负责系统掉电情况下的CPU数据刷新操作。通过该驱动将处理器Cache中的内容刷新到NVDIMM,然后再向NVDIMM硬件发送数据保存信号。NVDIMM接收到SAVE信号之后,将SDRAM中的数据进行持久化。整个过程可以描述如下图所示:
这种操作方式最大的一个问题是不通用,需要硬件平台的定制,并且也需要大电容的续航能力,要保证处理器Cache中的数据全部刷新到内存。另一种更加通用的方法是采用Intel标准的ADR技术,通过该技术,在Intel处理器检测到断电情况时,处理器会向NVDIMM发送SAVE信号,并且让NVDIMM处于自刷新的工作模式。这种方式最大的问题是如何保证处理器缓存数据的掉电非易失。前两年和NVDIMM标准组织讨论过这个问题,目前还没有标准来支持这个特性。也就是说,在系统异常掉电的情况下,处理器Cache中的数据是不能保证非易失的。对于存储应用来讲这是一个严重的缺陷,很有可能在系统掉电的情况下出现数据丢失的问题。所以,在应用NVDIMM的时候一定要解决该问题,这才是NVDIMM在存储应用中的设计重点。
近两年NVDIMM-N已经被相关组织标准化,并且ADR技术已经成为主流技术手段。在DIMM接口方面也定义了新的接口信号。JEDEC JC45.6标准中对12V供电、SAVE_n信号、EVENT#信号以及I2C的电气特性进行了标准化,具体定义如上图所示。
在NVDIMM-N掉电保护过程中的一大功臣是超级电容,这种电容具有很高的电容密度,具备快速充电的特性,在系统掉电情况可以为NVDIMM提供足够的能量,保证将SDRAM中的数据刷新至NAND Flash中。看起来这个部件没有什么特殊之处,似乎在存储系统中不需要对其进行过多考虑。其实不然,任何元件都可能发生故障,如果超级电容发生故障,那么在系统掉电情况下将会发生数据丢失的灾难。超级电容的使用寿命和工作温度息息相关,温度越高,超级电容的使用年限越短,如下图所示:
通过该图可以看出,在不同电容输出电压的情况下,随着环境工作温度的提升,超级电容的使用寿命在下降。在55度工作环境下,很多超级电容的使用寿命居然不到5年。在SSD存储系统中,55度环境工作温度是比较正常的,所以,超级电容的使用寿命成了NVDIMM在存储应用中使用的一个问题。为了解决这个问题,在存储系统设计过程中,需要对超级电容的使用寿命、状态进行监测,一旦出现风吹草动,需要提前进行预警,否则将会导致数据灾难。所以,在存储系统中引入NVDIMM之后,我们发现,NVDIMM解决了存储系统中的很多问题,并且可以和SSD进行配合,优化IO Pattern,但是与此同时也引入了很多棘手的现实问题。
个人觉得对NVDIMM-N冲击比较的大的产品是新型存储介质,例如Xpoint为代表的半导体存储介质。Xpoint构成的Memory最大的好处是不需要超级电容之类的故障部件,虽然在性能上不如NVDIMM-N,但是在存储应用中,需要解决处理器Cache的问题,所以,综合下来的性能Xpoint未必有多大的差距。Xpoint从2015年发布以来,还没有出产品,但是采用Xpoint构建的PCIe SSD已经有测试结果了,性能远远超过采用NAND Flash构建的SSD。如下图所示,在队列深度为1的情况下,采用Xpoint构建的SSD可以运行到将近8万IOPS,是目前PCIe P3700 SSD的7.32倍。未来比较看好这种新型存储介质可以在NVDIMM产品形态上进行创新,与基于NAND Flash的SSD进行配合,通力打造高性能、高效、可靠数据存储系统。
NVDIMM-F是一种比较直接的产品形态,其直接通过控制器将NAND Flash连接到内存总线上。具体原理如下图所示。在系统中,通过块设备的方式对NAND中的数据进行访问。和基于PCIe总线的SSD相比,数据访问总线发生了变化,具有更高的总线带宽。在控制NAND的控制器中,需要实现类似于SSD中的FTL,将NAND包装成块设备供系统使用。
在存储系统中,有些厂商采用这种设计思路。通过自定义硬件平台的方式在内存总线上集成大量的NVDIMM-F模块,从而在较小的物理空间内构建高密存储。早年有一家Skyra存储公司就是采用这种设计思路,想在1U的物理空间内打造PB级存储,这个想法在那个年代还是比较疯狂的。随着NAND Flash颗粒存储密度的提升,在1U空间实现PB级存储已经并非难事,并且也不需要采用NVDIMM-F这样的物理形态。
和NVDIMM-N相比,NVDIMM-F的访问性能相对比较低,其主要限制于NAND Flash的性能。如果将NAND Flash替换成Xpoint之类的介质,那么访问性能将会大大提升。为了均衡内存和NAND之间的性能与容量,诞生了NVDIMM-P产品形态,该产品的原理结构和前两种都有所不同,其通过控制器的方式连接DRAM与NAND,并且可以将NAND和DRAM空间都暴露给系统。这种方式可以理解成一种混合存储的架构,在系统突然掉电的情况下,通过SAVE信号将DRAM中的数据刷新至NAND中。
与NVDIMM-N相比,这种形态可以做到很大的存储容量。但是,由于在DRAM和内存控制器之间介入了额外的控制器单元,因此,DRAM的IO访问性能会有所影响,性能也是介于NVDIMM-N和NVDIMM-F之间。由于是混合存储的模式,所以比较担心性能的抖动性。
为了充分优化SSD闪存存储系统,NVDIMM是一种非常好的存储介质,通过NVDIMM可以实现对SSD IO Pattern的优化处理。但是任何东西都不会是完美的,在存储系统中使用NVDIMM并非找到了救命稻草,而在使用NVDIMM优良特性的同时会遇到很多新的问题。新型存储架构设计过程一方面需要利用新型介质带来的福利,更为重要的是需要解决新型介质引入的问题。期待NVDIMM技术进一步发展与完善,在未来高性能闪存存储系统中发挥更加重要的角色。
(存储之道)
本文出自 “存储之道” 博客,请务必保留此出处http://alanwu.blog.51cto.com/3652632/1884497
以上是关于如何在数据库应用中发挥SSD的优势的主要内容,如果未能解决你的问题,请参考以下文章
墨天轮专访第四期华为云GaussDB苏光牛:发挥生态优势,培养应用型DBA