In-memory Computing with SAP HANA读书笔记 - 第一章：Basic concepts of in-memory

本文为In-memory Computing with SAP HANA on Lenovo X6 Systems第一章Basic concepts of in-memory computing的读书笔记。



作为基础概念，本章非常重要。此Redbook讲得浅显易懂，配图也容易理解。唯一需要深读是DL ACM的那篇论文，后续我会再补充。

“卑之,毋甚高论,令今可行也”, 本章正符合汉文帝对于张释之的要求。

Basic concepts of in-memory computing

In-memory computing is a technology that allows the processing of massive quantities of data in main memory to provide immediate results from analysis and transaction.

To achieve the preferred performance, in-memory computing adheres to the following basic concepts:

* Keep data in main memory to speed up data access.

* Minimize data movement by using the columnar storage concept, compression, and performing calculations at the database level.

* Divide and conquer. Use the multi-core architecture of modern processors and multi-processor servers (or even scale out into a distributed landscape) to grow beyond what can be supplied by a single server.

Keeping data in-memory

内存计算的兴起于以下两点有关：

1. increase in capacity

2. reduction in cost

一台x86主机的内存可以达到2个T

Using main memory as the data store

内存计算的最大好处是处理速度

CPU虽然速度比内存快，但其适用场景和容量有限，即使是SSD，内存也比它快数千倍。



Main memory is connected directly to the processors through a high-speed bus, and hard disks are connected through a chain of buses (QPI, PCIe, and SAN) and controllers (I/O hub, RAID controller or SAN adapter, and storage controller).

Data persistence

数据库交易的可靠性依赖ACID:

A transaction must be atomic. If part of a transaction fails, the entire transaction must fail and leave the database state unchanged.

The consistency of a database must be preserved by the transactions that it performs.

Isolation ensures that no transaction interferes with another transaction.

Durability means that after a transaction is committed, it remains committed.

对于内存而言，由于是易失性存储，最大的问题在于ACID中的D。因此内存中修改的数据和日志都必须依赖非易失性存储来实现持久化。

SAP HANA每隔一段时间将变化的数据异步的写入磁盘，这个时间点称为savepoint，和Redis的术语一样，而TimesTen称为checkpoint。

而日志则同步写盘，Redis和TimesTen的日志则是同步异步皆可。



如此，当掉电发生时，就可以利用savepoint加上log的roll forward实现数据库的恢复。

Minimizing data movement

第二个关键点是减少数据在数据库和应用之间的传输

Compression

虽然内存的容量不断增大，但压缩仍是有意义的，这不但可以增加内存可以容纳数据的容量，同时减少了内存到CPU间的数据传输，当然同时需要考虑加压带来的开销。

压缩的原理见下图，实际上HANA压缩和TimesTen，和Oracle原理都是一样的，其实都是重复数据删除，或称为Dictionary compression

虽然可以有更高压缩比的方法，但考虑解压的效率，Dictionary compression还是具有优势的。



对于重复值较多的数据，Dictionary compression比较适合，压缩比也较高。

Columnar storage

关系型数据库以表来组织数据记录，存储格式分为行式和列式。



行式更适合交易，列式更适合分析。他们的比较如下：



HANA同时实现了行式和列式存储，但它的使用场景更适合于列式即分析，插入和更新较少的场景。

Efficient query execution

下面的例子显示了dictionary compression 和 columnar storage 结合可进一步减少数据读取：



上部黄色的部分为字典，中间绿色的部分为列式存储，通过bitmap操作，得到第6条记录满足where条件。

Delta-merge and bulk inserts

为了缓解列式存储更新性能的不足，HANA实现了数据记录的生命周期管理，如下图：



L1存储为快速更新操作而优化，数据以行式组织

L2存储是中间存储，以列式组织，但字典的优化不如Main Store

Main Store为列式存储+列压缩，适合于读取和搜索，具有优化的字典

所有的写操作在L1中执行，批量插入跳过L1在L2执行，读取操作访问L1, L2和Main Store形成统一视图。

数据的生命周期是指，数据从L1到L2，通过异步的Delta Merge，最终存放于Main Store。

数据从L1到L2的操作，包括以列式组织和压缩，如果数据在字典中不存在，将追加新的记录到字典末尾。append比insert要快，但结果为未排序的字典，会影响读取性能。

最终数据存放于Main Store，L2到MainStore的合并时，L2存储必须锁定，新的L2存储用于数据的追加。锁定的L2和老的Main Store形成了新的Main Store。合并操作非常消耗资源，因此需要合理的规划。

推荐阅读：

Efficient Transaction Processing in SAP HANA Database - The End of a Column Store Myth, which is available at

this website

https://blogs.saphana.com/2012/06/05/row-itandit-column/

这篇论文是收费的，不过可以从此处下载：

https://www.researchgate.net/publication/232305662_Efficient_Transaction_Processing_in_SAP_HANA_Database_-The_End_of_a_Column_Store_Myth

Pushing application logic to the database

虽然列式存储加速了处理性能，但还有一个因素影响会使数据处理变慢，即数据在应用和数据库之间的交互。

网络带宽的限制，数据往返的延迟等因素，促使我们应尽量将数据就地（在数据库）处理。当然前提是数据库能够处理应用的逻辑，例如传统的存储过程, PL/SQL等。

Dividing and conquering

divide and conquer（分而治之）就是将大问题分解为小的易处理的问题，从而可以并行处理。

Parallelization on multi-core systems

表中的行数据之间没有关联，因此适合于并行处理，可以利用多处理器（最新的intel CPU每socket已经有22core）系统并行扫描，从而提高处理效率。

Data partitioning and scale-out

虽然目前的服务器能力很强，也可以存放大量的数据，但需要处理的数据可能在单台的存储中无法容纳，因此需要分布到多台服务器，我们称为scale-out。

单个机器无法容纳的表可以进行水平分区（每一分区存部分行）和垂直分区（每一分区存部分列），每分区存于不同机器。