酷应用

#测给你看#什么样的存储引擎让Oracle数据库性能100%增长？

百家作者：QingCloud 2018-08-27 14:03:59

数据正进一步凸显其价值，越来越多企业开始意识到数据对业务的强大驱动力，希望收集更多数据并利用新的数据分析技术释放其中的价值，这需要企业 IT 提供更好的支撑，但传统基于 IOE（即以 IBM 小机、Oracle 数据库和 EMC 存储为代表的关键业务系统架构）方式构建的企业数据中心已经很难适应数字化时代对 IT 的要求。

于是，在 2011 年前后，业界掀起“去 IOE ”风暴：用开放标准的 x86 硬件和开源软件去替代传统封闭的 IT 软硬件。从过去几年的实践来看，Oracle 数据库目前仍是企业用户的首选，但承载 Oracle 等关键业务数据库的基石已经逐渐被x86和基于闪存的新一代存储所替代。

去 I、E 背后：x86 与闪存的力量

经过十几年的发展，x86 平台的计算性能和 RAS 特性（Reliability, Availability and Serviceability，可靠性、可用性与可维护性）都获得极高的成就，已经不弱于甚至超过了以 IBM Power 为代表的小机。而经过最近几年的实践，x86 平台已经逐步取代了传统小机。

E 也正在被基于 x86+ 全闪存配置的 Server SAN 所替代。在 SATA/SAS SSD 盛行的时代，与高端 SAN 相比，Server SAN 可能性能还有不足之处。

但随着 NVMe SSD 和支持 RDMA 技术的 25GbE 技术的普及，Server SAN 全面替代传统 SAN 存储已经成为可能。

NVMe SSD 的普及能够给创新型 SDS 方案提供商带来弯道超车的机会，由于传统 SAN 的可靠性设计需要双端口存储介质来实现，尽管 NVMe SSD 也支持双端口配置，但这意味着牺牲性能。

而采用分布式架构、利用多副本数据保护机制的 Server SAN 则无此烦恼，也就是说利用 NVMe SSD，Server SAN 的性能将有可能超越传统 SAN 存储。

同时，传统 SAN 所擅长的纵向扩展（Scale up）方式在 NVMe SSD 时代几乎很难派上用场（只能提升容量），而其多个控制器之间需要专用物理通路的设计，意味着横向扩展（Scale out）能力有限，这也是为何大多数高端存储控制器通常最大支持 8 个的原因之一。

“去 IOE”中的核心是“O”，但 Oracle 去 I、E 的尝试比所谓的“去 IOE”更早。

Oracle 在 2008 年推出了基于 x86 服务器的数据库一体机 Exadata，并从第二代开始采用服务器内置的 PCIe SSD 替代 SAN 存储。在 NVMe 规范成熟之后，Oracle Exadata 率先更新为 NVMe SSD。

Oracle Exadata X7-2 硬件配置，最小 2 数据库服务器+3 存储服务器配置，存储服务器均支持混合及全闪两种配置，数据库服务器支持最新的 25GbE，存储网络依旧使用 InfiniBand

Oracle Exadata 使用 InfiniBand 的主要原因在于其 RDMA 技术能够带来极低的延迟，有助于发挥 NVMe SSD 的优势。

最新一代的 25Gb/s 以太网技术也将 RDMA（即 RoCE 或 iWARP）作为标配，这将极大地提升 Server SAN 的性能。并且，在 25GbE 性能不满足需求的情况下，其也可以很便捷地升级到 100Gb/s 以太网。

8K 尺寸数据块是数据库类应用最常见的块大小，在使用支持 RDMA 技术的 100GbE 网络下，相比于 10GbE iSCSI，其有 20 倍的性能提升

青云QingCloud 的分布式块存储 NeonSAN 正是利用 NVMe SSD+25GbE 的组合，提供了极高的性能，并有效控制 I/O 延迟，这在上一篇文章中已经介绍过，在本文中，E 企研究院将构建贴近真实的数据库环境，以此评估 NeonSAN 在关键应用环境中的性能表现。

支撑关键应用性能线性增长

E 企研究院根据企业关键应用的特点，使用 x86 服务器、Intel NVMe SSD 和 25GbE 构建了 Oracle RAC 数据库环境，用以评估青云 NeonSAN 在 OLTP 中的性能表现。

E 企研究院评估青云QingStor™ NeonSAN 性能所构建的 Oracle RAC 架构及组件

在此测试环境中，E 企研究院使用 2 台配备两颗 Intel Xeon E5-2698 v4 处理器的双路服务器构建 2 节点的 Oracle RAC 数据库应用环境，并安装 Oracle 12c 数据库软件（包括 Grid 和 Database）。

使用三台配备两颗 Intel Xeon SP Gold 6140 处理器的双路服务器作为 NeonSAN 存储节点，每节点上使用 4 片 8TB 容量的 Intel DC P4510 SSD 作为数据存储。

Intel DC P4510 SSD 是 Intel 最新发布的采用 3D NAND 技术的 SSD 和新一代的闪存控制器的 SSD 家族，其最大容量可到 8TB，结合企业数据中心优化的固件，能够给企业关键应用存储带来极高的性能和稳定性。

基准性能测试：摸底 NeonSAN

在进行正式测试之前，E 企研究院先对 QingStor™ NeonSAN 的基准性能进行测试，以检验其是否正确安装，获得的测试结果也为后续 Oracle RAC 数据库性能测试提供参考。

基准性能测试采用 4K 和 8K 两种尺寸的数据块进行随机读写测试，4K 的随机读写性能是业界用于评估存储性能的事实标准之一，8K 则是数据库类应用的常见数据块大小。

同时，分布式应用已经成为企业 IT 的主流架构，E 企研究院也考量了 NeonSAN 在分布式环境下的性能表现，如下图所示：

QingStor™ NeonSAN 在分布式环境下，4K、8K 随机读写 IOPS 与平均响应时间对比

QingStor™ NeonSAN 的 4K、8K 随机读写性能。从测试结果来看，在单台客户端下发压力情况下，4K 与 8K 随机读写性能都能接近或超过 10 万 IOPS，且平均响应时间在 0.5~0.8 ms 之间，具有不错的性能；

而在 2 台客户端并发压力下，其 4K 随机读写性能分别达到了 18.5 万和 13.6 万 IOPS，而 8K 随机读写性能也分达到了 18.6 万和 11.7 万 IOPS，相比单一客户端下，性能至少提升了 50%，而延迟增长却并不明显，仍保持较低水平。

同时，E 企研究院还评估了 NeonSAN 在多个存储卷下的性能增长情况，结果如下图：

在单个压力客户端（图上）和 2 个压力客户端（图下）测试环境中，QingStor™ NeonSAN 分别供应多个（1~4个）存储卷下的性能（IOPS）和响应时间（Latency，ms）表现

随着 NeonSAN 卷数量的增加，其性能线性增长，而平均响应时间的增长并不明显。

在单台客户端性能测试中，在配置 4 个 NeonSAN 卷时，4K 随机读写和 8K 随机读性能均在 30 万 IOPS 左右，8K 随机写性能则能超过 25 万 IOPS，平均响应时间则均控制在 1 ms 以内；
在 2 台客户端并发压力下，4K 随机读写性能分别达到了 62 万和 52 万 IOPS，8K 随机读写性能则分别超过了 47 万和 42 万 IOPS

Oracle RAC 测试，直面关键应用

基准性能测试只能反应存储系统的性能表现，上述测试结果表明 QingStor™ NeonSAN 已经安装正常，可以接入已经构建好的 Oracle RAC 数据库应用环境中。

但需要注意的是，在进行 Oracle RAC 数据库测试时，衡量的是包括 Oracle 数据库服务器、测试环境网络以及 NeonSAN 存储的综合性能表现，这三者任意子系统出现瓶颈，都会影响测试性能。

所以在正式测试之前，还需确认其中某些子系统的瓶颈，以明确可能影响 Oracle RAC 数据库性能的因素。E 企研究院利用 Oracle 数据库内嵌的一组命令来检验接入 Oracle RAC 环境后的 QingStor™ NeonSAN 性能。

与之前基准性能测试不同的是，这一项测试是基于 RDBMS 层的测试，其通过模拟 Oracle 数据库的数据访问特点来对后端 NeonSAN 存储进行评估。上图显示在配置 4 个 NeonSAN 存储卷后获得最大接近 35 万 IOPS，然后即使再添加 NeonSAN 存储，其性能几乎不变。而且顺序带宽则在 5 个 NeonSAN 卷时获得最高 3.3GB/s 吞吐量。

通过上述测试表现，在接入 2 节点的 Oracle RAC 环境之后，NeonSAN 在提供 4 个存储卷时获得最大随机读取性能。

因此，根据这一结果，E 企研究院为 Oracle RAC 数据库环境共分配 4 个 1TB 容量的存储卷，分别测试其在 1~4 个卷下的 Oracle 数据库性能表现，具体如下图：

在 Oracle RAC 数据库测试中，在配置 3 个卷作为 Oracle 数据库存储时，获得超过 165 万 TPM（TransactionsPer Minute，每分钟事务处理数），但再增加一个 NeonSAN 存储卷，数据库性能并没有增加，这意味着在 3 个 NeonSAN 卷时，Oracle RAC 应用的其他子系统已经出现瓶颈，导致尽管存储性能增加，但应用性能并没有增加。

结合上一个测试结果，此时瓶颈可能出现在计算方面，即 Oracle 数据库服务器的计算能力达到瓶颈。

通过监控画面可以看到，Oracle 服务器的 CPU 平均利用率已经超过 75%。结合以往 E 企研究院的测试经验来看，通常情况下，服务器 CPU 利用率超过 70% 就意味着已经达到最佳计算性能，即使再增加负载，CPU 占用率可能会进一步提升，但就应用来看，其性能并没有增加，反而延迟可能会出现不利影响。

因此，从测试结果来看，在配备 3 个 NeonSAN 卷做 Oracle 数据库存储时，整个 Oracle RAC 环境就已经达到最高性能，而在此环境中，Oracle 服务器配备的是 Intel Xeon E5-2698 v4 处理器，要提升计算性能就只能更换到最新一代 XeonSP 系列中的顶级处理器，或者使用配备更多 CPU 的四路及以上服务器。

即使受到 Oracle 数据库服务器计算性能的影响，在此 Oracle RAC 数据库环境中，也取得了超过 165 万 TPM 的性能，即每分钟能够完成超过 165 万笔事务处理，这之中包括新增商品的添加、用户的浏览、订单的处理、修改以及订单查询、追踪等等常见操作。

平均到每秒的事务处理量为 3 万笔，且每笔事务处理的响应时间不超过 15 ms。

对于企业核心数据库而言，NeonSAN 不仅具有超高的性能，同时还具备极低的延迟，能够为需求苛刻的关键业务应用提供强有力的支撑。

每分钟 165 万事务处理量意味着什么？E 企研究院收集了目前较为热门的相关行业或新秀公司，根据其公开资料/数据整理，以与 NeonSAN 的 Oracle RAC 数据库性能对比，具体如下图所示：

常见应用App平均日订单量一览

虽然上图列出的订单量与数据库性能之间并不能划等号，一笔订单背后可能会有包括用户登录、用户信息修改、产生订单以及查询等多个操作，但仍能提供部分参考建议。比如据国家邮政局的最新统计数据显示，今年（2018年）前 4 个月全国快递业务量累计完成 136.7 亿件，平均到每天的快递业务量约为 1.14 亿件，按 8 小时计算，相当于每分钟会产生 23.75 万件快递，相当于 23.75 万笔订单，每个订单背后按 5 个数据库操作计算（即 1 订单需要 5 数据库性能作为支撑），那么大约需要 120 万的数据库性能，即 120 万 TPM。

而通过 E 企研究院搜集的数据简单计算的话，三节点（全 NVMe SSD+25GbE）配置的 NeonSAN 存储集群能支撑 Oracle RAC 数据库达到 165 万 TPM 性能，均能支撑上述应用数据库所需的存储性能，并有富余，可应对更高的业务峰值。

尽管因为具体到应用可能有不同的流程，会对后端存储产生不同程度的性能需求。但 E 企研究院认为，QingStor™ NeonSAN 完全有能力满足绝大部分企业应用对块存储性能的需求。

经 E 企研究院的测试表明，QingStor™ NeonSAN 不仅是一款优秀的 Server SAN 产品，符合 SDS（Software Define Storage，软件定义存储）的软硬件解耦、高可用、高可靠、弹性以及无厂商锁定等特点，同时借助最新的 NVMe SSD+25GbE 网络技术，能够提供极高的性能和极低的 I/O 响应时间，完全有能力满足企业关键应用负载所需的 RAS 特性和苛刻性能需求，助力企业向混合云迈进，为数字化转型奠定坚实基础。

某保险企业借助 NeonSAN 打造核心业务存储引擎

区块链，人工智能，大数据等技术的迅猛发展给互联网保险带来消费场景、产品形态和营销方式三大维度的颠覆，推动互联网保险向新技术密集型经营模式转型。

在互联网保险业务中，IT 系统已经深入到产品开发、销售、服务等流程的各个环节，成为业务发展的核心驱动力，需要具备高效的业务支撑能力与高投资回报率。

某保险企业自开展互联网业务以来，在线保险业务年均增长 100% 以上，原有数据库一体机的物理硬件资源趋于饱和，不再支持扩容与升级。

为了匹配将来的业务发展，该保险企业决定采用数据库自 Oralce 一体机向 x86 平台迁移的方案：将 Oralce RAC 数据库迁移到物理机，使用 NeonSAN 集群作为后端存储，提供数据库支持服务，配置三副本的数据保护机制。

客户收益

经过业务场景实测，基于 NeonSAN 的复杂视图查询响应时间从 20 分钟以上缩小到 2 分钟，精算准备金复杂 SQL 执行效率从分钟级缩小到秒级，实现效率 100% 的提升，可确保所有类型的数据处理都能够实现卓越的性能。更快的查询速度和更快的报表运行速度，帮助企业推动业务决策的制定、提高准确度并获得高品质成果。