炼数成金 门户 大数据 Oracle 查看内容

Exadata性能加速相关软件特性的演进历史(一)

2019-9-9 10:15| 发布者: 炼数成金_小数| 查看: 38412| 评论: 0|原作者: 吴东昕|来自: 甲骨文云技术

摘要: 当Exadata的第一代V1首次出现在公众面前时,RAC节点间互联就不再使用大家熟悉的以太网而采用原来在HPC中使用的Infiniband。无疑这个硬件架构的改变足够吸引眼球,大家从直观的硬件改变就知道Inifiniband具备比以太网 ...

数据库 存储 Oracle 硬件 RAC

Exadata从最早的V1 现在的X8,已经经过了9代。随着每一代的发布,大家都会关注硬件上的变化,却容易忽略Exadata独有的软件能力上的变化。在这里,我们总结了部分关键软件特性的持续创新,从软件角度来看一看这个支撑Oracle数据库的较佳平台。

1、Exadata中的RAC互联
当Exadata的第一代V1首次出现在公众面前时,RAC节点间互联就不再使用大家熟悉的以太网而采用原来在HPC中使用的Infiniband。无疑这个硬件架构的改变足够吸引眼球,大家从直观的硬件改变就知道Inifiniband具备比以太网更高的带宽和更低的延迟。但事实上,如果没有软件层面的支持,单纯依靠硬件是无法真正实现高带宽、低延迟来保证实现分布式缓存一致性。Oracle在RAC互联上采用了专门为Infiniband而研发的RDS(Reliable Datagram Sockets)协议。

如上图所示,采用了RDS大大减少了不同节点实例进行Cache Fusion通信的协议栈层次,而且可以直接利用Inifiniband本身lossless特性。通过更高的MTU大大降低了进行Cache Fusion缓存一致性通信时传输Oracle数据块需要的通信次数。

RDS协议理论上在任何X86平台使用Infiniband硬件都能运行,但是RDS协议是对操作系统、硬件微码等都有较强依赖的协议。在非Exadata环境,我们看到很多运行Oracle RAC的硬件平台会使用Infiniband硬件,但是在生产中却不敢启用RDS,仍然使用UDP over IP over IB的方式,因此不能充分发挥Infiniband硬件互联的能力。

RDS虽然已经比UDP over IP over IB强了很多,但是仅仅做到这点仍然是不够的。采用RDS的通信方式,对于数据库实例来说,仍然是一种需要中断调用的方式,需要用户态到内核态的系统调用。大家都知道中断调用带来的上下文切换开销是非常大的,会严重增加延迟,因此需要一种更好更新的方式。在Oracle Exadata系统软件的12.1.2.1.0版本,引入了新的进行RAC互联的通信协议Exafusion Direct-to-Wire Protocol。这是只有在Exadata平台才能启用的特性。对数据库版本也有一定要求,需要12.1.0.2.13以上版本。在12.1.0.2这个大版本中,缺省是关闭的,需要在spfile中设置exafusion_enabled=true来启用这一特性。从12.2开始,这个参数在Exadata平台就是自动启用的,将采用这种新的RAC互联通信协议,官方也推荐在12.2或者更高版本使用它。下图是Exafusion和RDS在跨节点通信时的调用过程。

从图中可以看出,Exafusion Direct-to-Wire Protocol这种无中断调用的通信协议,大大加快了跨节点缓存同步的效率,真正利用到RDMA(远程内存直接访问),无需上下文切换。通过这一系列软件层面的增强,才让Exadata成为了运行Oracle数据库的较佳平台,也让15年前Oracle推出RAC架构愿景能成为了现实:在高并发高容量的生产环境中,数据库节点数量对应用透明,应用只需要连接RAC的SCAN即可自动实现负载均衡而不用关心应用分割,从而成为一个对应用透明的、横向可扩展的、基于缓存一致性的分布式数据库环境。

2、Smart Flash Cache的持续增强
Exadata最早的V1硬件版本,是没有Flashcache的硬件的,V2版本首次引入了Flash作为智能的Flashcache,同时这个特性是需要Exadata系统软件的11.2.1.2版本。在最初的版本里,Flash自动加速的功能仅仅是buffer cache读,也就是OLTP的随机读。对于全表扫描的读,需要手工将表、分区、索引通过一条alter talble/index … storage(cell_flash_cache keep)强制驻留到Flashcache中才会对大块读进行缓存。同时,早期的Flashcache仅仅做读缓存,所有的写都不能加速,不论是LGWR写还是DBWR写。这对于复杂和高压力的混合负载显然是不够的,因此,在后续的软件版本里不断地加强。

首先在11.2.2.4里引入了一个重要的Smart Flash Log功能,这不是简单地将redo log放到flash上实现加速。Flash有一个重要的特点就是不能直接写,必须先擦除,而且存在明显的写寿命,一旦直接把redo log放到flash上,随着时间的推移,达到写寿命后,重新分配数据块、擦除循环会导致redo log写明显的尖峰抖动。在Exadata里数据库和存储IO通信采用自己独特的iDB方式,存储能知道从数据库节点发出的IO写究竟是在写数据文件还是redo log,一旦发现是写redo log,会采用同时写flash和磁盘的方式,只要其中一个成功就返回给数据库redo log写成功,通过磁盘控制器的RAM Cache解决了Flash写的抖动问题。

这样的实现大大加速了前台DML在commit时的持久化过程,而且由于独有协议,存储节点能优先服务LGWR写,避免属于后台写的DBWR甚至写归档日志抢夺了应该先获得服务的LGWR写的带宽和IOPS,这点也是任何其他存储不可能具备的能力。

当然,仅仅加速LGWR也是不够的,如果DBWR的IOPS写很多,在没有Flash加速的情况下,可能会把Exadata磁盘的IOPS(相比传统盘阵,Exadata配置的磁盘数量并不大)耗尽,出现check point无法完成等情况导致性能下降。因此在11.2.3.2的Exadata系统软件版本,又增加了Write Back Flash Cache(WBFC)的功能,用来加速DBWR的随机写,避免过度消耗磁盘IOPS。这一功会加速DBWR的随机写,对于大块写,比如恢复数据库到Exadata,写归档日志,是不会进行缓存而占用Flashcache空间的。

随着新一代的Flash越来越大,DBA更加希望全表扫描的大块读也能实现自动智能,不需要DBA再参与管理哪些对象要放到Flashcache内。因此在11.2.3.3.0,引入了Automatic Flash Caching for Table Scan Workloads这个特性,对全表、分区、索引快速全扫描的加速。和很多人想象的不一样,这个特性看起来很简单,实际上在非Exadata环境是很难实现的。因为非Exadata环境的存储无法识别大块读究竟是业务需要的SQL在做全表扫描,还是在做备份,或者备份归档等等,如果无条件的缓存大块读,只会导致Flashcache被无谓的IO块占用反而影响了系统性能。

对于非Exadata,面对这样的工作负载,要保证性能,数据库的大小必须小于Flashcache的有效容量,或者在数据库容量小的情况下索性就用全闪存来保证性能。

对于Exadata,因为智能的iDB协议,能知道读取的数据块来自于什么表、分区、索引,Exadata系统软件不是用简单LRU算法,而是把部分数据块放到Flashcache,而且在嵌套扫描中优先选择将容量小的表放到Flashcache,避免了简单LRU的碰撞效应,从而自动实现大表扫描大块读的智能缓存能力。
前面提到了这么多Smart Flash Cache的特性,虽然在不断演进,但是都有一个共同的特点,就是缓存的数据和数据库存储的数据块是完全一致的。如果数据没有压缩,或者是基本压缩、OLTP压缩,那么缓存的就是数据块。如果数据是混合列压缩(HCC)压缩,缓存的就是HCC的Compress Unit(CU),对于很多应用场景这是足够了。

随着in-memory双格式的在数据库的引入,在Exadata系统软件的12.2.1.1.0版本,提供了针对分析加速的更加强大的Cache能力。在Exadata软件版本12.2.1.1.0中,针对已经进行了HCC压缩的表,会在Flash上根据查询针对特定列建立列式缓存(columnar flash cache),当查询只需要部分列时进一步减少IO的量,并充分地通过X86 CPU的SIMD指令加速查询匹配。

到Exdata系统软件版本18.1,针对所有的表格式(包括非压缩或OLTP压缩),都可在Flash上建立In-Memory Columnar Caching,采用和12.1.0.2数据库引入的In-Memory Columnar一样的格式进行扫描,不必担心数据库节点的物理内存大小不确定应该把哪些表放到SGA的In-Memory区的情况。只需要简单的在12.1.0.2以上的数据库设置spfile参数为INMEMORY_SIZE,即可在存储的Flash上自动使用In-Memory加速功能,提供数十甚至上百TB的压缩后容量。从某客户实际使用的效果来看,能比HCC进一步减少扫描IO量60%,并且加速查询速度100%以上。

有人会问,临时表空间的读写会不会被Flashcache加速呢?这其实也是一个演进的过程。临时表空间的读写,一般都是PGA的溢出,最明显的特点是很可能是一次写入然后一次读取。在早期V2、X2年代,采用的Flashcahce极小,所以那时候主要都是缓冲随机读IO。那时一个存储节点4张Flash卡在大块写入上并不比12块15K RPM的硬盘更快,所以完全没有考虑到采用Flashcache加速临时表空间读写。从X3开始,一个存储节点的Flash的大块写入速度已经不亚于12块15K RPM硬盘,但是由于容量的问题也没有考虑这个加速。到了X4,由于采用的不是NVME接口,在并发较多使用临时表空间的查询时,采用Flash加速效果并不明显。这种情况在X5引入了NVME接口的Flashcache才发生了彻底改变。在Exadata系统软件12.2.1.1.0中,引入了Faster Performance for Large Analytic Queries and Large Loads,能够加速临时表空间读写,同时对于直接路径的数据加载和Flashback log写,都可以通过Exadata Flashcache加速。当然,这个特性需要数据库软件版本的配合,详细的要求请参考官方文档。

声明:本文版权归原作者所有,文章收集于网络,为传播信息而发,如有侵权,请联系小编及时处理,谢谢!

欢迎加入本站公开兴趣群
软件开发技术群
兴趣范围包括:Java,C/C++,Python,PHP,Ruby,shell等各种语言开发经验交流,各种框架使用,外包项目机会,学习、培训、跳槽等交流
QQ群:26931708

Hadoop源代码研究群
兴趣范围包括:Hadoop源代码解读,改进,优化,分布式系统场景定制,与Hadoop有关的各种开源项目,总之就是玩转Hadoop
QQ群:288410967 

鲜花

握手

雷人

路过

鸡蛋

相关阅读

最新评论

热门频道

  • 大数据
  • 商业智能
  • 量化投资
  • 科学探索
  • 创业

即将开课

 

GMT+8, 2019-11-7 08:43 , Processed in 0.118236 second(s), 25 queries .

幸运飞艇三分钟 幸运飞艇难中 专业幸运飞艇 番幸运飞艇 幸运飞艇4点 幸运飞艇中奖 马尔幸运飞艇 幸运飞艇打和 高返水幸运飞艇 幸运飞艇如何打