SSD还分随机和顺序IO吗？Oracle的回复_唐僧_huangliang_新浪博客
SSD还分随机和顺序IO吗？Oracle的回复
上周，有位朋友提出一个问题：“在HDD中，顺序8KB写和离散（随机）8KB写的IOPS差别大，这是因为磁盘机械的原因。那么在SSD里面，顺序8KB和离散8KB写IOPS也还会有差别吗？”
这是一个好问题。因为硬盘每一次随机访问，都需要消耗磁头寻道和盘片旋转等待这两部分时间；而SSD使用的是半导体闪存介质，随机访问要快得多。
我在《》一文中，经过推算得出“Oracle&Exadata&X5弹性扩展与SSD性能计算Exadata公布的SQL闪存写IOPS可以是顺序操作，所以会超过IntelP3600标称的8KB随机写IOPS”的判断。当时也确实有点拍脑袋，印象中看过这方面的测试数字，但却一时拿不出证据了。
最简单的办法，就是用实际测试再验证一遍，这时我已经做好推翻自己的准备：）
上图引用了IDF关于SSD的演示文稿，“不管顺序还是随机写入，都没有寻址时间，因为它们都是被顺序地写到NAND里面去的。”
这里的说明不只代表Intel
SSD，所有以闪存为介质的固态盘都是如此，通过FTL“将新数据写入新的物理地址，将原来的LBA地址标明无效并不可用”，让我想起了NetApp
WAFL和ZFS文件系统。
以上是理论基础，下面看看测试环境和测试结果。
首先，我可没有Exadata那样高大上的东西，话说以我的Oracle水平也玩不动，现在拿给我玩也浪费了。
就拿自己用的SL500笔记本吧，正好系统盘已经换成SSD——被誉为渣渣的三星840
EVO（TLC），凑合着做个验证。
如上图，由于C盘上安装了操作系统，不能影响正经事儿，所以我在当初预留的11GB空间上创建了一个测试分区，并且用Iometer将其“填满”后开始测试。
这里说明2点：
1．&&我测试的不是整盘，但SSD有FTL来实现磨损平衡，因此实际写入的LBA范围很可能比较大并在物理上不连续，可以像WAFL/ZFS文件系统那样永远写到新的位置。
2．&&另外我是在NTFS文件系统上做的测试，与直接测试裸盘有些差别，每种文件系统/卷管理器通常都会有些缓存、元数据之类的，不过对本次测试影响不大。
操作系统是Windows7
64位，Iometer软件版本1.1.0-win64.x86_64，每次测试运行2分30秒（我的SSD已经过一段时间的“老化”）。我们看到C盘里的数据也不少，如果是机械硬盘这样测试Z盘的话，只要没有（对C盘操作）I/O争用就无所谓；而SSD则不同，整个盘的内充满数据的比例、以及碎片化程度都会影响到性能，特别是写入性能。
由于SSD的特点，不仅写入闪存页面速度没有读快，另外已经写入数据的页面（大小4KB/8KB）需要经过块（64KB以上）擦除才能再次写入，也就是通常所说的垃圾回收（GC）过程。相比之下机械硬盘不存在这些问题。
测试结果及分析
SSD随机/顺序写入性能对比（关闭写缓存）
为了避免写缓存的干扰，我首先在关闭写缓存的情况下运行了测试。根据以上图表，排除测试误差情况因素，差距确实比较小。SSD在队列深度为1时的500左右IOPS，也达到了我笔记本5400转机械硬盘的10倍。
结论初步有了，但是接下来我又面临一个问题——之前对Exadata
X5存储节点SQL flash read/write
IOPS的简单分析如何解释？
“ExtremeFlash全闪存节点为377,000，这里是SQL
IOPS已经考虑到ASM冗余带来的写惩罚，那么落到每个SSD（每节点8个）上应该就是94,250——好像这个数字明显超过了IntelP3600标称的8KB写IOPS
那么HighCapacity大容量混合存储节点的192,000，落到4块闪存卡上96,000写IOPS也是类似的情况？”
我们仍然以Oracle给出的最大性能指标是落在SSD上的真实IOPS为前提，如果顺序写不能比随机写更快的话，那这个数字是怎么测出来的？
有Oracle的朋友给出了回答：“F160（NVMe
SSD）的指标和P3600不完全一样，说用的是eMLC，8KB随机写入指标到42000”，“我们的卡不是标准产品，比标准的卡性能更好，寿命更长。”&
Oracle给出的F160性能确实比上表中的IntelP3600高，但距离我计算之后期望的数值还相差比较多。至于eMLC和寿命之说，感觉Intel又有点玩了数字游戏——我曾经写过P3600没有像P3700那样标明High
Endurance Technology
(HET)闪存，但新发布同样支持5年每天3次整盘写入，1.6TB型号最大写入数据量10.7PB的S3610（同容量的P3600为8.76PB），就标明了高耐久度MLC。
我们再看看还有啥提高性能的方法。
参考上图，不知Smart
Scan能否将8KB数据块整合成更大的I/O？如此则写入带宽将会增加。不过这违背了我们刚刚设定的前提。
增加队列深度对随机读改善比较明显，也就是发挥闪存的并发能力，其实看前面关闭写缓存情况下的随机/顺序写测试也是如此。
上面的文字重新解释了“随机度”对性能的影响，理由是顺序操作减少通道冲突，以及碎片回收的难度。右边柱状图中的差距是在什么条件下测得的呢？
还有过量冗余——Intel等厂商早就说过“减少LBA的访问范围可以提升性能、耐久性和服务质量”。右边的折线图最右端为100%随机写，当超量配置（OP）为0%时写I/O很容易触发垃圾回收；有了20%和40%空间冗余比例可以带来显著的写IOPS提升。
让我们再来看看Intel当年的SSD
320是公布了怎样的“作弊方法”——在8GB
LBA范围内测试，并打开写缓存。其实消费级SSD公布的IOPS，有几家不是这样测的呢，甚至于Fusion-io好像也这么干过。
那么Exadata
X5是不是也可以预留闪存容量呢——没有说测试数据集一定要多大吧？可惜我的笔记本SSD太搓，在11GB分区内测试也没快到哪里去，不过可以打开写缓存试试看。
SSD随机/顺序写入性能对比（打开写缓存）
如上图，4条不同颜色的实线表示IOPS，以左边的坐标轴为单位；4条对应颜色的虚线表示延时（单位毫秒），以右边的坐标轴位单位。从左到右的4个点，代表每项测试我都运行了4遍。我的Excel水平不高，大家凑合看看：）
首先，我在队列深度设为1的情况下对比了8KB随机写和顺序写，由于写缓存的因素，前2次测试的IOPS波动比较大，而到了第3次以后则趋于稳定并出现明显一些的差距。将队列深度改为32之后，随机写IOPS并没有明显的改善。
至于队列深度32的8KB顺序写，只是拿来做个参考数字，毕竟我都是在有限的时间内运行测试。8KB是Oracle
OLTP应用的典型IO尺寸；对于批量插入和redo
log这样的小数据块顺序写操作，我不确定多线程/进程能够发挥到什么程度。由于我在数据库方面并不专业，所以这里就不妄下判断了。
尝试给出一个结论：Intel在资料中提到过随机度对SSD写入性能的影响（原因前面解释过了）。除了过量冗余能够提高写入性能之外，根据测试，打开写缓存在一些情况下也可以改善SSD
8KB顺序写IOPS（长时间测试效果有待验证）。
极限测试和POC、读IOPS如何
许多消费级SSD大胆使用DRAM写缓存来提高IOPS性能，我在《》一文中提到有的企业级SSD也这么做，但要用电容来做保护；这样对性能的效果与控制器/RAID卡的写缓存，延时将数据持久化到硬盘/SSD的情况类似。
尽管可能会带来数据风险，但对于极限性能测试来说，快一些有什么不好呢？正如同行朋友所说，有多少POC会老老实实地使用write-through、SYNC这样的参数呢？
最后我还顺手做了个读测试，可以看到在并发足够（队列深度32）的情况下8KB随机读IOPS能够达到甚至超过8KB顺序读，这时我的笔记本CPU占用率已达80-90%（还有杀毒软件什么的，就算是个小小的生产环境吧），这个SSD可能还有潜力。
另一方面，如果队列深度只有1，那么顺序读还是比随机读要快不少，我理解这是预读的效果。&
本人的技术水平有限，欢迎大家批评指正！文中如有不够严谨的观点，权且当作给大家拓展思路吧：）
感谢您的阅读和支持！《企业存储技术》微信公众号：huangliang_storage
保存下面二维码用微信扫一扫即可关注
历史文章汇总：
鍞愬儳_huangliang
博客等级：
博客积分：0
博客访问：137,636
关注人气：0
荣誉徽章：Oracle性能调优：ssd可以用作redo盘吗 -学路网-学习路上 有我相伴
Oracle性能调优：ssd可以用作redo盘吗
来源：examw &责任编辑:小易 &
　　ssd可以用作redo盘吗
　　1.ssd有写磨损，而且ssd的写性能也不是非常好，ssd只是随机读特别好，因为不需要寻道吧。并且ssd比较容易损坏
　　2、做index表空间和临时表空间是个不错的选择
　　3、ssd硬盘可擦写的次数目前来说不是很理想
　　4、SSD的写寿命本来就短，再加上严重的写惩罚，事务繁忙的系统，不用多久SSD盘就废了。 redo的性才是第一位的考虑
　　5、写的话，没那么理想，因为阵列的话，首先是写到缓存里，就返回写成功，所以没那么高提升
　　6、 redo logs不要放到SSD磁盘上现在
　　The tips below will help you to reduce log file sync when writes are
　　Tune LGWR to get good throughput to disk . eg: Do not put redo logs
　　on RAID 5.
　　Do not put redo logs on Solid State Disk (SSD)
　　Although generally, Solid State Disks write performance is good
　　on average, they may endure write peaks which will highly increase
　　waits on 'log file sync'
　　from mos [ID ]
　　7、SSD“大忌”：什么时候不应该使用SSD？
　　SSD在数据中心领域已经树立起了自己的地位。几乎所有主流厂商都会在它们的最佳实践架构中指定Tier 0。端的SSD用于提升性能，而端的SSD则解决了启动风暴的瓶颈。就像大多数技术一样，了解什么时候使用它和什么时候不使用是很重要的。现在让我们来看看什么时候不使用SSD。
　　对于不是读密集型（read-intensive）的应用不要使用SSD。SSD可以显著提升读访问时间。相比传统HDD硬盘，读取效率可以提升10倍以上。但是天下没有免费的午餐，SSD在写性能上并无优势。写操作不但有延时，而且还会耗尽SSD的存储单元。存储单元有平均写寿命，超过这个寿命时，存储单元会逐渐损坏（具体要查看厂商对指定系统的提供的详细信息）。当存储单元损坏时，SSD总体性能会下降。最终，SSD必须被更换以保证其性能，我们都知道，SSD并不便宜。一些厂商更是提供昂贵的保修服务。
　　那么理想的读写比率是多少呢？这并没有一个固定的数字，但90/10是比较理想的。在这点上应用必须做出让步，这需要IT管理者做出合理的决定。如果读写比率低于50/50，那么很明显传统的HDD硬盘是更好的选择。在这种情况下，从应用的角度来看SSD对读性能的提升会被其糟糕的写性能抵消。所以如果你需要使用SSD来提升读性能，但写性能成为了问题，那么你可以考虑采用损耗平衡（wear-leveling）机制和能减少写入放大（write-amplification）的厂商，从而降低性能影响。SSD的大小也是一个因素，便宜的SSD会因为减少了递归读的几率而产生更重的负载。
　　当数据随机访问过大时不要使用SSD。SSD通常被认为是“缓存层”，这个名字很形象。从根本上说，SSD就是一种用来减少从传统硬盘取数据的缓存。随机访问需求很高的应用不会从SSD上获益―读操作会被阵列控制器定向到HDD，此时昂贵的SSD作用很小。
　　在高度虚拟化环境中不要使用普通SSD。好吧，这一点会带来一些争论，因为在虚拟机环境中已经有了一些SSD的成功案例，如启动风暴。然而，许多虚拟机访问同一块SSD时会导致很多随机数据指令，至少从存储的角度来看是这样。当上百个虚拟机对相同的存储进行读写时，一台机器会一直不断的重写其它机器的数据。因此，有专门为虚拟化环境设计的SSD解决方案，这就是之前为什么提到“普通”SSD。
　　不要在服务器端使用SSD用以解决存储IO瓶颈。服务器端SSD从根本上说就是服务器缓存，用于解决处理性能问题和网络带宽问题。将SSD分布到几百台物理服务器上，每台服务器都配置自身的SSD可能的确会对解决IO瓶颈有帮助，但是并没有将其放置在存储阵列端效率高。
　　不要使用Tier 0来解决网络瓶颈。如果数据传输被网络控制，在网络后端优化存储系统显然不会有好的效果。服务器端SSD可以减少访问存储系统的需求，因此可以减少网络流量。
　　不要为企业级应用部署消费品级SSD。SSD有三种等级：单层单元（SLC），多层单元（MLC）和企业级多层单元（eMLC）。MLC被认为是消费品级SSD，通常在打包的应用中使用。每个单元的生命周期是次写操作。SLC是企业级SSD，具有每个单元100000次以上写操作的生命周期。eMLC尝试在价格和性能之间到平衡点，提供每单元30000次写操作，但价格比SLC低。客户可以根据自身的购
本文相关：
- Copyright & 2018 www.xue63.com All Rights ReservedOracle&Exadata&X5弹性扩展与SSD性能计算_唐僧_huangliang_新浪博客
Oracle&Exadata&X5弹性扩展与SSD性能计算
在撰写本文之前，我先是阅读了Oracle Database Appliance
X5-2的产品资料，并发了一条微博：
“简单看了下Oracle Database Appliance
X5-2的硬件，2个1U服务器节点间用40Gb
InfiniBand互连，应该是直连没有交换机。24盘位JBOD（可扩展1台）每个驱动器共享给2个服务器由ASM管理。放redo
log的4个200GB
SSD采用3重镜像，我估计写好1-2个就返回；缓存热数据的4个400GB
SSD为双重镜像（共享还是各自独享？）”&
而当我继续查看Exadata
X5的资料时，发现ODA的架构显得太简单了。
伴随Oracle Exadata
X5的发布，人们注意到硬件性能的又一次提升，其中包括NVMe
SSD——PCIe插卡和SFF-8639驱动器的形式，具体是怎样使用的呢？
本次的新型号包括Oracle Exadata Database Machine
X5-2，以及Oracle Exadata Storage Expansion
X5-2两款，顾名思义，后者是个存储扩展机柜。此外，计算和存储节点数量的搭配，在原有Full
Rack（满配机架）、Half
Rack（半配）、Quarter
Rack（1/4配）和Eighth
Rack（1/8配）之外，还加入了更加灵活的弹性配置和扩展方式。
笔者不是DBA（一直很崇拜DBA），因此将站在系统工程师，或者说规格参数的角度谈谈对Exadata
X5的弹性扩展以及存储配置——特别是闪存性能方面的理解。
1U数据库服务器和40Gb
IB内部互连，就不多讲了。
X5-2的存储服务器节点分为两种：Extreme
Flash(EF) Storage，12.8TB
PCIe全闪存盘；High Capacity
(HC，高容量)
Storage，6.4TB
PCIe闪存卡+48TB
SAS硬盘混合存储。
如上图，SSD用了哪家大家也知道的差不多了。每个Extreme
Flash存储服务器上有8个1.6TB
SSD，2U机箱容纳2.5寸盘远不止这些，那么应该是考虑容量/成本的平衡，以及匹配单个节点计算和网络资源。
接着在性能表格中，也能看出Full
Rack——8个DB+14个存储服务器OLTP读/写IOPS
(8K)&都是414万。单从闪存介质的角度看写比读慢，而且ASM
Normal冗余（双副本）的写开销为读的两倍，High三副本就更大了。我初步理解是SQL处理的瓶颈。
Capacity大容量存储服务器是个混合的配置，其中1.6TBPCIe
SSD用了4块，4TB
SAS硬盘为12块。除了读IOPS之外，其余指标都比前面的Extreme
Flash有所降低。由于SSD在这里用于读写缓存，没有全闪存配置的数量多，所以写IOPS已经低于读（SSD开始成为瓶颈）。
上图就是X5 High
Capacity存储服务器节点使用的闪存卡，Oracle/Sun的型号为F160，顺便也帮Intel
P3600做广告了。（以前用LSI卡时图片上没有logo，参见我两年多以前写的《》）
如上表，Intel
P3600这块产品的性能表现在PCIe
SSD中算一般水平吧。一方面没有像P3700那样使用高耐久度的High
Endurance Technology
(HET)闪存，也就是普通MLC而非“eMLC”，写入性能和寿命都受到影响。如上图，尽管标称最大随机读/写IOPS（4KB）为450,000和56,000，但8KB时就下降到260,000和33,000。
Intel这款SSD的一大优势是较早地支持了NVMe，担心NVMe不够成熟的人可以看看，现在至少某些Linux版本（Oracle
Linux 6 Update 6 with the Unbreakable Enterprise Kernel
2）下已经可用了。
延伸阅读：《》
接下来我们看看“弹性配置”。上图左半边是Exadata
X3-2，支持数据库服务器2-8台、存储服务器3-14台，实际上就那4款具体配置，不能随便选；而到了Exadata
X5-2，支持数据库服务器2-19台、存储服务器3-18台。也就是说数据库服务器（1U）最少配1台，最多19台时还能容纳大约8台2U的存储服务器，这时的节点搭配比例与Exadata那4种固定配置不同，可以添加Storage
Rack扩展存储容量和性能。存储服务器为了高可用还是以3台起步，最多18台占满机柜。总的来说限制少了很多。
需要说明的是，上述性能指标应该是在理想状态下——执行最简单的SQL；性能随节点数完全线性扩展，也是在RAC集群基本没有跨节点Cache
Fusion操作的情况下。所以注释的第一行就说明了，真实环境中根据应用情况会有变化。
上表的标题为“弹性扩展”，最左边的多机架连接，以及最右边的1/8机架到1/4机架升级（实际上就是激活个License，硬件是相同的）都是Exadata
X3乃至更早就有的。而中间的“扩展计算能力”和“扩展存储能力”则是X5新增。
中间用蓝色圈出的那一段，是本文中核心计算规则：“弹性配置的性能计算，来自数据库服务器性能总和，以及存储服务器性能总和的最小值。举例，一个配置包含3台数据库服务器（3x518,000=1554K读IOPs）和4台HC存储服务器（4x400,000=1600K读IOPs），将拥有1554K
IOPs的性能。”
Exadata的SQL的处理既可以在数据库服务器上进行，也可以卸载数据密集型SQL操作到存储服务器，但二者的性能计算不可叠加。X5-2数据库服务器（2颗18核Intel
Xeon E5-2699
v3）的最大SQL读/写IOPS为518,000，存储服务器最大SQL读IOPS为400,000（它的CPU只有2颗8核），写IOPS就可以看出闪存的瓶颈了。Extreme
Flash全闪存节点为377,000，这里是SQL
IOPS已经考虑到ASM冗余带来的写惩罚，那么落到每个SSD（每节点8个）上应该就是94,250——好像这个数字明显超过了Intel
P3600标称的8KB写IOPS
Capacity大容量混合存储节点的192,000，落到4块闪存卡上96,000写IOPS也是类似的情况？转念一想，Intel给出的数字是随机写IOPS，而Exadata这里的SQL闪存写可以是顺序操作啊！是这个原因吗？
（扩展阅读：《》）
我想起@jametone&老师说过的一句话，大意是这样的：“实际应用中读IOPS容易离散，而写IOPS容易连续，再加上读/写比例的因素，存储的读性能成为瓶颈的情况更多一些。”这或许可以解释Exadata
X5使用相对便宜的PCIe
最后再看看更牛B的数字——Exadata存储扩展机柜的最大配置19台，仍然是用乘法来计算的。这种资料里的性能嘛，只是厂商给出参考的一个数字罢了。
今天我这个数据库外行写了这些东西，其中难免有纰漏之处，欢迎大家批评指正，也让我能有一个学习进步的机会：）
感谢您的阅读和支持！《企业存储技术》微信公众号：huangliang_storage
保存下面二维码用微信扫一扫即可关注
历史文章汇总：http://blog.sina.com.cn/firegl
鍞愬儳_huangliang
博客等级：
博客积分：0
博客访问：137,636
关注人气：0
荣誉徽章：再不用NVMe SSD，你的Oracle数据库就out了
数据库是当之无愧的关键业务应用，不管是互联网企业，还是非互联网的（传统）企业，最核心的数据，都放在数据库里面。
以Oracle为代表的关键业务数据库，首当其冲的要求就是高性能，当然高可靠与高可用是必备基础。正因为这些特性，面向关键业务应用的软硬件平台，一直都在寻找最好的技术和架构。要注意“最好”不能等同于“最贵”，“高端”二字一定要经得起实践检验。
当然，“最好”的定义要与时俱进，而不能刻舟求剑，躺在过去的功劳簿上睡大觉。时光倒退回十年前，有专门为数据库应用打造的王牌组合——IOE：I即是以IBM Power为代表的小型机平台；O即Oracle数据库软件；E则是以EMC（现已被Dell收购）为代表的高端SAN存储。大约从2000年开始，IOE可以算是关键业务数据库应用的最佳组合，或者竞品模仿的范式（小型机+商业数据库软件+集中式存储）。
但是，历史的车轮滚滚向前。在21世纪第一个十年即将过去的时候，三驾马车开始解体。在互联网和非互联网（企业）战线上，替代IOE成为一个热门话题，并在实践上获得成功，虽然两大市场需求不同，但都不约而同，大有齐头并进之势。
最广为人知的当属互联网巨头阿里巴巴掀起的“去IOE”：计算方面，用日渐成熟、价廉物美的x86取代Power小型机；存储方面，用PCIe SSD取代EMC的高端磁盘阵列。
甚至IOE阵营内部也在发生类似的变革： Oracle于2009年收购Sun之后，正式推出自己的数据库一体机Exadata，同样是用x86+PCIe SSD组合把“IE”踢出局。Exadata主要面向传统企业市场，但也有PayPal这样的标杆型互联网用户。
阿里与Oracle的最大区别是要不要去O。Oracle当然不会把自己的命革掉，阿里则出于大规模应用的成本、自主可控等考虑，先是用MySQL替代Oracle，后又在MySQL基础上发展出了OceanBase。这种做法非互联网企业难以效仿，很多企业连MySQL都玩不转，更别说自己打造数据库软件了。
OceanBase的跨数据中心分布式架构
阿里巴巴、亚马逊、Facebook等互联网巨头，由于体量够大，可以自成体系，技术上能形成足够的掌控力。只要能满足业务的需求，不仅在软件上可以发展出自己的分支，硬件上也可以先于市场引入新的技术，甚至是尚未形成工业标准的产品。譬如，Facebook和阿里都比较早的大规模应用PCIe SSD初创企业Fusion-IO的PCIe SSD，以获得数倍于SATA SSD的性能和容量。
Exadata导入PCIe SSD的时间也不晚， Oracle收购Sun之后推出的ExadataV2就使用了Sun品牌的PCIe SSD，作为数据库存储的Cache。之前基于HP服务器的初代Exadata（存储服务器）只有传统的硬盘，定位在OLAP（在线分析处理）应用。正是从V2这一代开始，Exadata在PCIe SSD的强力助推下，越来越能胜任OLTP（在线交易处理）应用了。
Oracle的Exadata数据库一体机市场占有率不能说有多高，但作为最懂数据库的厂商，其硬件的选配对Oracle数据库的用户无疑具有很强的借鉴意义。从V2开始，Exadata保持了很高的换代频率，包括X3、 X4 、X5乃至最新的X6，基本都紧跟闪存的发展潮流，来提高整个系统的性能。诚然，随着时代的进步，Exadata的软硬件技术都在不断提升，但是SSD方面的变化，比Exadata中CPU按部就班跟着Intel升级，要显著得多。
Exadata数据库一体机典型架构。以Exadata X5为例，最上为DB Server，可以是双路E5（比如X5-2），也可以是八路E7（比如X5-8），最小两节点组成RAC，保证高可用，上面运行ASM为数据库提供存储接口；而应用数据则是通过双冗余InfiniBand交换机连接存储在（最小）三台存储服务器上（Oracle称为Cell），存储服务器内使用两块或多块PCIe SSD作为缓存
与互联网巨头有所不同的是，Oracle在Exadata的PCIe SSD选择上，更为关注可替代性。以Exadata V2采用的Sun F20 PCIe SSD为例，这是一种基于（PCIe接口）SAS控制器+SATA SSD模块的桥接（Bridge）方案，架构上不如以Fusion-IO为代表的原生（Native）方案先进。但是，当时市场上可以选择的原生方案很少，而且技术路线不同，很难成为标准。反观桥接方案，虽然过渡性质明显，但其构建模块却分别基于已经标准化的SAS和SATA技术，不同提供商之间的产品也更容易互相替代。因此，一直到Exadata X4这代，都坚持采用桥接方案。
在2012年左右，采用桥接方案的PCIeSSD架构拓扑图（英特尔910系列SSD），实际上是PCIe转SAS。从技术角度来看，这跟使用SAS HBA卡连接驱动器形式的SSD并没有本质上的不同
谨慎不代表保守，事实证明Oracle一直在关注PCIe SSD的标准化进程。闪存的蓬勃发展必然会促进行业进一步整合，用户市场也会驱动其产生一个统一的标准，在Intel、Oracle等行业领导厂商的积极推动下，NVMe（Non-Volatile Memory Express）开始发展壮大，并且随着华为等数据中心供应商的加入，NVMe迅速成为行业标准。
PCIe SSD不仅可以获得比SATA/SAS SSD更高的带宽，还具有更短的I/O路径，随着NVMe进一步根据SSD的特点简化软件堆栈，在延迟上的优势愈发明显
上图为华为ES3600P V3产品架构图，即采用U.2接口的NVMe SSD架构图，这是NVMeSSD的典型架构，相比于原来的桥接方案，或者SATA SSD，其架构优势能够带来更短的I/O路径，理论上延迟更低
NVMe为PCIe SSD提供了标准化的原生逻辑接口，与桥接方案以及SATA的AHCI接口相比（虽然都是基于PCIe接口），I/O路径明显更短，对Oracle数据库应用意义重大。因此，也就不难理解，待到NVMe规范基本确定，有大厂推出基于NVMe标准的PCIe SSD，Oracle跟进的速度之快，堪称迅雷不及掩耳盗铃——2015年1月发布的Exadata X5-2，就转为采用PCIe NVMe SSD，彼时在互联网巨头中，NVMe的接受度也还不高呢。
华为同年（2015年）推出的ES3000 V3系列NVMe SSD。下方为1.6TB容量的传统插卡式PCIe NVMe SSD ES3600C V3，上方为3.2TB容量的U.2规格（2.5英寸驱动器形态）NVMe SSD ES3600P V3，除了形态不一样之外，其他特性基本一致，都可以达到明显大于SATA SSD的容量
在NVMe孕育期间，一种新的PCIe物理接口规范也逐渐成型，这就是SFF-8639。传统插卡式PCIe SSD在可维护性上不如驱动器形式的SAS/SATA SSD，SFF-8639在SAS连接器的基础上增加了PCIe x4的电气接口，在背板的支持下，可以像SAS/SATA SSD或硬盘一样安装在2.5英寸驱动器插槽中，便于从服务器前端维护。为了方便传播，大约在2015年，SFF-8639有了一个U.2的“俗名”。
华为ES3000中的ES3600P V3型号即为U.2接口的（PCIe）NVMe SSD，最大容量可到3.2TB，4k读I/O性能可达80万IOPS，延迟则在微秒级别，数倍于SAS/SATA接口SSD
从下往上依次为SAS接口、SATA接口，和U.2接口，U.2接口针脚最多，因为其在兼容SAS/SATA接口的基础之上，增加了对PCIe ×4的支持，理论带宽可到4GB/s（PCIe3.0）
从背面能更好地看出SAS、SATA与U.2接口的不同，结合上一张图，可以看出，U.2正反两面都布满了针脚，以支持PCIe ×4
Exadata X5-2对NVMe和U.2可谓照单全收：容量型Exadata Storage Server仍然采用插卡式PCIe SSD，新增的全闪存Exadata Storage Server则使用U.2 SSD，两者都是PCIe NVMe SSD，只是外形规格不同。由此可见，只要条件成熟，Oracle对新技术的采用是非常大胆、迅速的。
之所以等到（符合NVMe标准的）U.2 SSD才推出全闪存型号的Exadata存储服务器，而不选择早已成熟的SATA SSD，原因显而易见：SATA接口有限的带宽限制了SSD的性能发挥，而且到6Gb/s后已不再发展；而PCIe 3.0 x4的带宽接近SATA的七倍，NVMe又进一步缩短了延迟，性能上构成全方位的压倒性优势。
PCIe接口速率，即使2.0时代，PCIe x1也能到500MB/s，稍逊于SATA接口，但PCIe SSD通常是x4通道配置。而进化到PCIe 3.0，PCIe x4通道理论带宽可达4GB/s，优势十分明显
看起来很美，但是，在Oracle的实际应用中，U.2接口的NVMeSSD性能优势能有多大？企事录实验室拿到了来自华为的U.2 SSD——ES3600P V3，与2.5英寸SATASSD进行了一系列的性能对比测试，结果显示，U.2 SSD性能确实数倍于SATA SSD。下图为以Oracle数据库为代表的企业关键业务应用方面，U.2接口的ES3600P V3与SATASSD的性能表现：
在使用单块ES3600P V3时，其平均TPS就能接近3万，而同时使用4块SATA SSD，其TPS才接近2.8万，不足1块ES3600P V3 SSD的性能
企事录在这一测试中，Oracle数据库服务器采用的是双路E5服务器，配备2颗Intel Xeon E5-2699 v4处理器，这是Oracle Exadata X6-2中数据库服务器配置的同款处理器，同时使用128GB内存。从上述测试结果来看，SATA SSD随着数量的增加，其性能是线性增长的，并且，CPU占用率也近乎线性增长（分别为15%、29%、43%、62%）。
在TPM方面，单块ES3600P V3能实现近180万TPM，而同时使用4块SATA SSD的TPM刚超过160万，不足单块ES3600P V3的性能但值得注意的是，在本次测试中，为了减少变量，企事录实验室将CPU主频恒定在2.7 GHz运行，但由于TDP限制，整个平台的CPU占用率约在65%左右。也就是说，CPU占用率最高到65%，就达到了CPU瓶颈，计算能力无法再上升。从上图可以看到，在使用2块ES3600P V3 NVMe SSD时，CPU占用就达到了65%，即使再添加第三块SSD，无论增加多少负载，CPU占用都无法提升
而且，由于TDP“功耗墙”的影响，CPU性能无法提升，但负载又随SSD数量的增加而线性增加，这会导致响应时间的线性增加。
结合前文TPS/TPM的图可以看出，随着SATA SSD的增加，其TPS/TPM性能随之线性增长，但其平均响应时间基本保持不变（都在2ms左右），这是正常状态下，即CPU计算性能未达到瓶颈时，整个Oracle数据库的性能反应。也就是说，影响Oracle数据库性能的瓶颈仍在于SATA SSD，不但TPS表现不如，连响应时间也不如。从上图可以看到，SATA SSD的平均响应时间都在2ms左右，而（1块）NVMe SSD的响应时间则可以低至1ms，甚至在微秒(us)级别（测试工具所能监测到的最小单位为ms）
SATA SSD展现了正常状态下的Oracle数据库性能。而由于CPU瓶颈，2块或者更多NVMe SSD的Oracle数据库测试则为非正常状态。因为CPU占用率恒定在65%，负载随NVMe SSD数量的增加而（人为）增加，事务处理量随之增加，但计算能力出现瓶颈无法处理增长的事务数，从而导致响应时间大幅增加。
需要说明的是，上述是一个测试环境，即单实例Oracle数据库，且SSD位于Oracle数据库服务器内部，几乎没有高可用保护，主要验证NVMe SSD与SATA SSD的性能差异。而在实际应用中，其通常以2+3的配置来保证计算与存储的高可用，即2台Oracle数据库服务器做RAC，3台存储服务器做故障域。这样计算与存储的分离不仅能够有效保证整个数据库系统的高可用，而且还可实现计算与存储单元分别扩展。
2台Oracle数据库服务器仅为最小配置，其不但可以通过Scale out增加数据库服务器节点的方式来提升整体系统性能，同样也可以通过使用更高配置的四路/八路服务器来提升性能。比如，在另一个Oracle数据库性能测试中，采用2（RAC节点）+3（存储节点）配置中，Oracle服务器使用2台华为4路E7服务器，存储则使用3台双路服务器加NVMeSSD配置，轻松获得了300万峰值TPM，平均TPM也稳定在270万左右。
在华为FusionCube测试中，存储采用NVMe SSD配置，由两台4路服务器构建的Oracle RAC集群轻松突破了峰值300万TPM，这在磁盘时代几乎是不可想象的，即使使用SATA SSD也要大费周章，而使用NVMe SSD，则只使用了3个存储节点
理论上，传统插卡形式（Add-In Card，AIC）的PCIe SSD和U.2 SSD都使用PCIe 3.0 x4通道，性能其实没有区别，只是形态不一样。形态的不同就使得AIC更多用于互联网行业；而U.2 SSD则更适用于企业市场，因为其2.5英寸驱动器外形可以延续企业市场的前端插拔等运维体验。
除了形态不一样，U.2 SSD与传统插卡式PCIe SSD在性能上基本相差无几，从华为官网提供的性能数据可以进一步证明：
华为官网提供的ES3600C V3（传统插卡式）和ES3600P V3（U.2）的性能数据，相同容量下，包括IOPS、延时等读写性能都几乎一样，甚至连功耗都大致相当。不过U.2接口的SSD提供的容量选择要更多一些。另外，右边两款采用采用3D NAND技术的新产品，提供了翻倍的容量
出于各种考虑，Exadata数据库一体机并非大多数用户部署Oracle数据库时的首选平台，但是Exadata采用NVMe SSD的历史（X5和X6，预计今年会推出X7）足以证明，NVMe SSD经得起考验，而我们的测试也进一步验证了NVMe SSD全方位的性能优势。随着NVMe生态的迅速成熟，PCIe NVMe SSD（特别是U.2规格）的价格也逐渐逼近SATA SSD。考虑到NVMe SSD巨大的性能优势，Oracle数据库用户们应该加紧拥抱这种“性能倍增器”了。
责任编辑：
声明：该文观点仅代表作者本人，搜狐号系信息发布平台，搜狐仅提供信息存储空间服务。
今日搜狐热点