不选择Database In-Memory的10大理由

甲骨文云技术 2022-11-04

532

在刚刚结束的2022 Oracle Cloud World 大会上，和Oracle 数据库Database In-Memory选件相关的会议如下：

Oracle Database In-Memory: Best Practices and Use Cases [LRN3515]
Oracle Database In-Memory: Your Enterprise at Warp Speed [LRN3516]
Database In-Memory—What's New and How Customers Are Using It [LRN1510]
Boost Analytics Performance with Oracle Database In-Memory [HOL4001]
Top 10 Reasons to Not Use Oracle Database In-Memory [LIT4014]

这几个会议的代号中，LRN表示Learning Session，HOL表示Hands-on Lab（动手实验），LIT表示Lightning Session(闪电会议），即时长较短的快速会议。

Database In-Memory自2014年诞生，技术体系已相对成熟稳定，小编粗略翻看了这三个LRN会议的内容，发现绝大部分的内容都已经在之前的公众号文章“加速度-走进Database In-Memory”中介绍过。正当小编想说Oracle这条Old dog can't play new tricks时，发现LRN1510中有介绍23c Database In-Memory新特性的内容，小编不得不感叹产品经理还是蛮有想象力的，Oracle这条Old dog不愧是Old dog。由于23c还未发布，小编只能透漏新特性重点是在自动化方向，其次是算法的进一步优化，等正式发布时我们再做详细介绍。

虽然您不能亲临Cloud World现场参加HOL4001动手实验，但此实验您也可以在Oracle LiveLabs网站上申请，实验的名称为：Boost Analytics Performance with Oracle Database In-Memory。目前此实验已更新到21c版本，内容比之前19c版更精细，覆盖的特性也更广。

言归正传，今天小编着重介绍的是会议LIT4014，虽然其中的观点对于小编并不新鲜，但其正话反说的构思，轻松诙谐的陈述，对于Oracle这个技术直男来说殊为不易，小编还是要不吝惜的给一个赞。

#10: I love making complicated changes to run analytics

莎剧《哈姆雷特》里有一名句：Brevity is the soul of wit，意为简洁是智慧的灵魂。使用Database In-Memory正如拨动旋钮般简单，只需3个步骤即可：

1.设置内存的大小

2.设定需要使用Database In-Memory 的对象

3.主动发布或在全表扫描时自动发布

如果使用Automatic In-Memory特性，则只需要第1步即可。如果是23c的话，您可以畅想一下，😉。

#9: I love playing “index roulette”

建立索引是提速分析型查询的常规手段，但建立正确的索引需要了解对应的工作负载，所以索引的设计对DBA是有挑战的。并且，索引无法应对即席查询，因为你不知道他会查哪些列。此时你只能像轮盘赌游戏一样，多押几个数字。不过这就带来了下面2个问题。

#8: I like the fact that indexes bloat databases

索引是需要空间的，而且可能比数据还要多。虽然存储的架构不再高昂，但大量数据的管理负担可能是一个问题。

#7: I like the fact that indexes slow down transactions

每一个索引都需要维护，过多的索引会明显减慢DML语句（更新、插入和删除）的速度，如果是数仓系统还则罢了，如果是混合交易系统（HTAP），则可能是一个不能忽视的问题。

#6 I prefer sector processing to vector processing

演讲者在这里玩了个小技巧，使用了sector和vector这两个近音词。sector processing其实并不是一个常用的说法，但vector processing（向量处理）则早已固化为现代CPU中的指令集，即我们常说的SIMD。SIMD和内存列式数据库简直是天作之合，可以极大提高列数据处理的速度。无论是Oracle的Database In-Memory，还是SAP的HANA，都可以看到SIMD的身影。

#5 I like creating cubes, summaries, materialized views

和第10点一样，这里说的其实还是简单。只不过前者指使用上的，这里则是架构上的。早期的数据分析系统，为提高分析速度，往往需要提前建立多维数据集，摘要和物化视图，但这种做法的副作用其实和索引是一样的，需要额外的设计，额外的空间和额外的维护（如数据一致性）。而Database In-Memory 可以在很大程度上减少对这些手段的使用，将架构简化。

#4 I prefer “row-by-row, slow-by-slow” processing

Row by row处理，即逐行处理，是数据库（不限于Oracle）性能的大敌，其导致的结果就是Slow by slow。虽然在Oracle文档，博客中，到处都在强调避免使用row by row处理，但“执迷不悟”的开发者还是时常会碰到（最近一例就在昨天）。在Oracle中，与row by row处理对应的是bulk processing或array processing，后者可以很好地与SIMD结合。