数据库为什么需要闪存卡?

发布时间:2016-05-31

2008年的时候,一套数据库可能还不到200GB,觉得已经是一个非常大的容量,因为当时Oracle的安装文件才1GB多。2015年,Oracle12c的安装文件全部加起来,已经快10G。当然,数据库容量也是翻了很多倍,很多核心的系统,数据库容量都在3TB-5TB 之间。
Oracle 软件功能的不断增加,数据库的大小也在不断增加,业务对数据库的要求也越来越高。第一要保证系统的高可用,第二还要保证系统的高性能。高可用我们可以通过Oracle Data Guard,RAC 的架构来实现。但是高性能,就是一个非常头痛的问题。
在日常的运维过程中,经常会出现业务系统突然卡住,或者系统响应时间变慢的问题。做为一名运维DBA需要花很多时间来解决这些故障,所以DBA的另外一个称呼,叫救火队员。
从Oracle 数据库的角度考虑,Oracle 提供了很多方法,让DBA 来分析问题,比如AWR 报告,收集统计信息,分析执行计划,收集对象的碎片,在服务器资源够用的情况下,还可以使用并行,亦或者在内存资源足够的情况,可以把一些经常访问的对象keep到buffer cache中。这些方法现在已经成为DBA的必备的几把斧头,在数据库出现性能问题的时候,一般都是先用这几把斧头,但随着数据量的成倍增长,这种方法效果越来越不明显。
这是2010年某系统的AWR 报告截图:

这是2015年某系统AWR报告的截图:

因为是不同的系统,不能直接进行对比,但有些指标还是可以做参考。 2010年的系统,是3个小时的快照分析。2015年的是半个小时的快照分析。
这里对比2个参数:
每秒生成的Redo大小:2015年是9M,2010年是134K。
每秒执行事务数量:2015年是5156次,2010年是345次。
这个就是一个侧面的对比。说明随着近几年信息化的快速发展,业务系统对数据库的处理数据量、并发请求、吞吐量要求越来越高。
现在回到我们之前说的问题,在数据量越来越大的情况下,传统存储的机械磁盘寻道,已经成为一个非常明显的瓶颈,IOPS低,延时高,不能满足数据库高性能要求。
而闪存卡,正好可以弥补这个短板。我们看一组性能数据。

利用闪存卡,完美解决了存储IO对数据库高性能的影响,在结合高性能CPU,和大内存,可以在X86的架构下,让数据库提供更高的性能。
我们继续看一组X86 架构下基于闪存卡的Oracle数据库性能数据:


这个测试使用使用的是X86的八路服务器,CPUIntel E7-8870v2 * 8, 内存 1T。测试出来的效果非常明显。
1.TPM:4044739(400w)
2.NOPM:1344006(134w)
3.Redo size:340M/s
4.执行SQL: 139w/s
5.事务:6.7w/s


这组性能数据,可以说明,这种架构完全可以支撑现在的所有业务,相对与传统的IBM小机和 EMC存储来说,这种架构是最佳的替代方案,也是未来的发展方向。而其中最后一个短板,也被PCIe 闪存卡完美解决,所以数据库必须依靠闪存卡,才能发挥出最大的性能。