一文带你看懂SAP-HANA的基本架构与原理

注：本篇主要对SAP HANA做了总结与论述，如有错误欢迎读者提出并补充

创作不易,希望大家一键三连支持!!!♥♥♥

创作不易,希望大家一键三连支持!!!♥♥♥

创作不易,希望大家一键三连支持!!!♥♥♥

一. 背景引入

1.1 硬件与数据库系统

传统数据库系统将数据存储在磁盘(Disk)中,磁盘I/O次数多，效率低。

随着多核处理器的出现，现代数据库系统将数据存储在了内存(Memory)中,降低了磁盘I/O，但同时引入了处理器缓存的新问题。

现代化硬件上的理想数据库系统：
(1)内存式数据库，减少I/O.
(2)缓存优化的内存结构，连续访问数据临近存储.(CPU在未命中和等待状态下的优化)
(3)支持并行执行，利用多处理器的优势。

1.2 行业现状

①企业资源计划系统(ERP)需要处理混合工作量
·OLAP:创建销售订单、进货出货凭证、发票等 →写优化
·OLTP:运营月度报告、可承诺量、库存量分析等 →读优化

②OLAP+OLTP系统因性能的顾虑而分离
·不便：
(1)OLAP数据并非最新数据，只是数据预先处理后的子集.
(2)需要ETL工具来同步两个系统，系统冗余，程序复杂.

③开发愿景
·使用现代硬件和数据库系统将OLTP和OLAP数据结合在一起，创建一个单一数据源，实现实时分析，并简化应用程序和数据库结构。

二. SAP HANA应用架构

2.1 HANA架构图

SAP HANA是一个包括了硬件、数据库和解决方案的结合体。

2.2 行式存储与列式存储-内存地址

行式存储：每一行为一个基本存储单位。

列式存储：每一列为一个基本存储单位。

列式存储的优点：压缩

基于企业数据特点：
(1)列的使用相对集中
(2)列中的值基数不高；
列式存储的结构支持高效的数据压缩：
(1)节省空间
(2)提升速度：内存←传输→CPU缓存；字典编码，整数值比较快于字符值比较；加快扫描和聚合数据库中真正存储的是：数字+字典+对应关系。

2.2.1 列式存储数据字典压缩—案例

HANA列式存储通过字典压缩的流程：

(1)HANA基于原数据表对主键列进行排序并计算唯一值，由此提取出一个数据字典。

(2)对每一行的数据生成行ID与其对应值ID的对应表(验证了前述所说：数据库中真正存储的是数字、字典、对应关系)

(3)同时，HANA还会对原数据表的主键建立倒排索引，该索引是对(2)中对应表的一次再次索引，可以找到每个值ID所出现在的行数。

对查询语句使用倒排索引优化前后的对比:

在找到所有行号之后，基于流派字典(值ID和值的对应表)即找到所要查询的行记录。

2.2.2 行式存储与列式存储的对比

常见问题：
1.HANA只是一个列式数据库么？
不是的，HANA中既有行存储，也有列存储。

2.HANA中的列存储是否还可以使用索引？
是的，HANA的列式存储对所有主键自动建立索引(倒排索引)，对于经常访问到的非主键列也是可以建立索引的。
3.内存式数据库是否仍然依赖于硬盘？
是的，依旧需要硬盘支持备份与恢复。

2.3 HANA列式存储的特点

2.3.1 加载状态

(1)未加载: 数据仍在磁盘中

(2)部分加载:由于查询条件而载入内存

(3)全部加载:数据全部在内存中

注:可以通过对表的加载状态设置来控制哪些表置于内存中(全部加载)、哪些表置于磁盘中(未加载)

2.3.2 主存储(Main)+增量存储(Delta)

(1)数据并不直接修改而是插入新数据：并行化，减少锁，多版本控制

(2)主存储对值ID进一步压缩，对读取、计算性能优化

(3)增量存储不排序、不对值ID进一步压缩，占空间较大

2.3.3 增量融合(Delta Merge)

(1)额外的CPU、内存消耗

(2)可选优化方案：内存内融合、分区

增量融合过程:

(1)融合前：

Read：主存储Main1、增量存储Delta1

Write：增量存储Delta1

(2)融合中：

拷贝出新的主存储，将主存储Main1中的数据解压缩并和增量存储Delta1中已经提交的事务来进行重新解压、排序、编码、压缩来生成新的主存储Main2，同时在增量融合过程中，所有Write操作会连同增量存储Delta1中未提交的事务一起融合到增量存储Delta2中.

Read：主存储Main1、增量存储Delta1、增量存储Delta2

Write：增量存储Delta2

(3)融合后：

增量融合后，原有的主存储Main1和增量存储Delta1会被舍弃，留下最新的主存储Main2和增量存储Delta2.

Read：主存储Main2、增量存储Delta2

Write：增量存储Delta2

三. HANA持久层与HANA重启

3.1 HANA持久层

HANA持久层和传统数据库持久层类似。

3.2 HANA重启

每5min写一个Savepoint，将更改后的数据和日志冲刷到磁盘中，并且对已提交的事务，HANA会通过SSD硬盘读写的方式在Log Volume记录Redo日志，一旦发生断电，系统就会自动读取最近的一个Savepoint，之后再通过Redo日志即可使断电恢复后系统回到一个稳定的状态.