不1ms不是好AFA，全闪存阵列XtremIO优化Oracle数据库性能
想了几天，第一篇解决方案的文章到底写什么？混合云，超融合，大数据都是时下热点。不过想来想去，EMC毕竟从存储发家的，所以，本篇解决方案连载我想也从存储开始。
总的来说，从存储实施的角度，绝大多数应用场景，或者说是用户考虑自身存储解决方案的时候，主要考虑的无非是以下个大类：
· 性能：重中之中，快！要快！还是要快！重要的事情说三遍。硬件更替在解决应用程序速度上可谓简单粗暴。
· 容量和成本：这两个可以是分开的指标，但是这里把它们放在一起，单位容量的成本是衡量一个存储阵列重要指标。
· 高可用：一年到头来总在线时间，可以用N个9来衡量。异地容灾，数据恢复，本地、远程复制等等都是高可用性的衡量指标。
而这几大类中人们最关心的还是性能！计算机的发展就是伴随的计算速度的提升，CPU和网络在过去十五年的前十年内发展迅速，而存储限于硬盘的机械构造一直有着拖后腿的味道，但是近几年来随着闪存技术的蓬勃发展，存储的速度看似慢慢追了上来了。
所以，连载的第一篇解决方案，我们就来看一下EMC的全闪存存储阵列XtremIO在Oracle事务数据库上的表现和特点。
白皮书在这里的附件里面已经呈上，这篇白皮书的主要内容是帮助DBA们理解Oracle数据库的性能瓶颈，以及XtremIO全闪存阵列是如何帮助他们解决这些性能问题的。其实就是，EMC XtremIO可以让DBA不用手工再去调整各种索引，查询算法，就能把数据库性能提高几个数量级！够简单粗暴吧！
具体看一下，首先，从Oracle的I/O特点来说，了解数据库CPU的Waite Time分布是判断是否要在存储端优化性能的标尺，有一类Oracle数据库性能分布如下：
可以看到，需要优化存储的性能指标是这样的，总CPU等待时间才17%（利用率低），剩下有42%的时间花在等待数据文件中的User I/O 。反过来，如果数据库慢，DB时间大部分花在CPU处理上，那么这个数据库的优化应该在服务器，而不是存储。好了，下面的实际案例来了:
案例一：压力测试
测试配置我这里就不提了，图中也有，关键两点：
· 这是一个单节点的XtremIO，
· 这个测试中的数据I/O都是1 milliseconds 级内完成的。（这个不得不提一下，以前阅读的数据库技术资料中，提到如果IO在5ms以内，就是很好的性能了，现在世界发展实在太快。）
第一个测试结果是这样的，两张图：
一个小时的压力测试下来，XtremIO每秒钟 7kTPS，2.9w SQL Query，16w Logical I/O，实际到XtremIO的物理I/O写近10万每秒（读8w3，写1w5），每秒处理了21MB的Redo Log。综合下来90%的IO在2ms内完成，80%在1ms内完成。
案例二，同样的测试扩展到两个XtremIO节点
这个案例中，工程师证明了XtremIO从单节点扩展到两个节点后，性能按照线性增长，基本上处理能都翻倍，看下图：
案例三：选另一个竞争对手的全闪存阵列进行比较
测试方法是8小时和2天的压力测试，当然结果很明显，XtremIO对于长时间的处理完胜，这里也不贴图了，感兴趣的直接下载下来看吧。
总结一下，以1ms Response Time为单位，现在已经是全闪存阵列（AFA）的黄金标准了，可以说，不能1ms就不是好AFA。楼主这里想再补充的是，1ms虽然是标准，但是在衡量一个好的AFA的时候，除了IOPS和Response Time需要重点关注之外，阵列在长时间运行下的表现也很重要，就像这篇解决方案中所看到的，XtremIO和某竞争对手的阵列相比，在长时间的运行压力下，还能保证高比例的小于1ms级的IO处理能力，以及能够线性的不影响总体性能的情况下进行横向扩展也是关键。
下一篇我们来看看VMAX3在处理Oracle数据库上的表现吧。
点击此处与文章作者Fenglin直接交流讨论
>>>未完待续>>>
来源：CSDN
作者：Cristinana
链接：https://blog.csdn.net/Cristinana/article/details/48546639