本文主要是介绍内存为王：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架构的挑战和解决方案的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
