本文主要是介绍内存为王:DBIM RAC Share Nothing架构的挑战和解决方案,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
最近看了一篇Oracle RWP写的文章: 内存为王:DBIM RAC Share Nothing架构的挑战和解决方案
感觉写的比较深入,需要原文的可以关注Oracle官方微信: OraNews
文章要点如下:
* Database In-Memory (DBIM) 是 Oracle 在 12.1.0.2 中引入的新特性,旨在加速分析型 SQL 的速度。
* In-Memory Columnar Store(IM列式存储)是位于 SGA 中独立于 Buffer Cache 的内存区域,是列式存储
* 数据可以同时存在于 buffer cache 和 IM 列式存储,传统数据按行组织,以数据块为单位存于 buffer cache 和磁盘上,数据在 IM 列式存储中按照列式组织的。
* 传统的 OLTP 应用依然通过 buffer cache 修改数据,Oracle 通过内部机制保证行式存储和列式存储的事务一致性。分析性的 SQL 从 IM 列式存储中扫描数据,避免物理读成为性能瓶颈。
* 默认的IMCU大小为512k
* 硬件方面的提升包括CPU的SIMD和内存计算避免物理扫描
* 软件方面的提升包括压缩,Storage Index,Bloom Filter,In-memory Aggregation( Vector group by transformation,Bloom Filter的增强版)
* DBIM RAC是share nothing架构,而传统的RAC是share everything架构。传统的RAC通过内部私网传递数据实现共享,而DBIM RAC只能通过并行计算实现跨节点计算。
* DBIM RAC在进行数据分布时,应尽量保证分布均匀以充分利用并行计算的性能,否则会出现短板效应。
* 数据分布后,如果一个实例宕机,数据会分布到其它实例,但不是马上。
* DBIM对于非Exadata硬件平台的加速作为适合;对于Exadata平台,smart scan的性能有时会比in-memory更好
这篇关于内存为王:DBIM RAC Share Nothing架构的挑战和解决方案的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!