数据库是当之无愧的关键业务应用，不管是互联网企业，还是非互联网的（传统）企业，最核心的数据，都放在数据库里面。
以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数据库用户们应该加紧拥抱这种“性能倍增器”了。
