本章为SAP HANA的概述,
了解SAP Simple Finance背后的关键思想和概念,
在随后的章节中我们将从SAP HANA的概要图开始
介绍SAP HANA的一些基本概念,包括内存
数据存储,字典编码和数据压缩,并行处理能力
,以及使用增量存储来优化写入操作。我们将会
总结SAP HANA作为单一统一平台的整体愿景,
混合企业工作负载 - 即事务和分析数据处理。
SAP HANA的核心是一个大规模并行数据库管理系统
(DBMS),
完全
在内存中运行。与传统的
在有限内存硬件上优化性能的数据库管理系统不同,
SAP HANA数据库的设计根本是有充裕的内存
可以存储所有业务数据,并且不约束硬盘的输入/
输出(I/O)访问。传统的数据库
注重优化硬盘I/O,SAP HANA注重
优化CPU高速缓存和存储器之间的访问。
图2.1说明了SAP HANA的基本概念,
包括将DBMS集成到标准的SQL接口,事务隔离
和恢复,以及高可用性。 DBMS能够处理行
存储,列存储和图形存储,它
通过专用引擎和自带的集成
服务,如搜索和应用程序扩展,
有助于大规模并行化
的多
线程
数据库
访问,
它与
SQL,MDX等
标准
接口
兼容。
在这里,我们将重点放在
SAP HANA的DBMS方面。
为了在存储器中处理大量数据并
即时
提供
分析和事务的结果,SAP HANA采用了
以下基本概念:
>将数据保存在内存中(第2.1节)
虽然仍然需要使用磁盘存储器来确保写入操作的持久性,但是读取操作相关的所有数据永久地驻留在主存储器中,因此可以在没有磁盘I/O的情况下被执行数据读取。
>优化内存中数据访问(第2.2节和第2.3节)
由于所有数据都存储在内存中,
CPU缓存和主内存成为数据移动性能的新瓶颈。SAP
HANA通过使用列式存储和有效的数据压缩技术来解决此问题,
有效地减少了内存中数据的整体大小和
CPU缓存数据的高命中率。
图2.1 SAP HANA基本概念
>支持大规模并行数据处理(第2.4节)
现代计算机系统具有不断增加的处理器数量,
为了本质上利用多核处理器,SAP
HANA将SQL指令放到优化的模型中,以更好的利用多处理器的并发处理能力。
优化的模型包括将数据进行分割并对
各
分割部分并行执行计算。
>数据
写入
优化(第2.5节)
拥有快速读取性能的
列式存储也有其代价
。写入操作,特别是对列存储的插入和更新将变得
更复杂和
低
效。为了克服这个缺点,SAP
HANA引入了增量存储的概念,写入的数据在写入优化的增量分区中累积,该分区在适当的时间合并到主分区中。
以下部分更详细地介绍上述SAP HANA的基本概念。
2.1将数据保存在内存中
计算机架构在过去几十年中发生了变化,伴随着单台计算机上的内存容量前所未有的增长和价格的戏剧性下降。
今天,一台企业级服务器可以在内存中存储
TB级别的数据。 主内存是最快的存储
介质可以保存大量的数据,使其成为可以
永久性存储企业业务数据的
可行方法
。
如果查看计算机系统的存储结构,就能发现将数据保存在主内存中的好处是显而易见的。 图2.2显示了典型计算机系统中存储结构的概念图,从存储介质访问数据时有两个因素影响其性能, 一是存储介质本身的物理速度,另一个是延迟,即系统从存储介质加载数据到CPU寄存器中所经历的时间。最后,每个操作发生在CPU内部,并且数据必须在CPU的寄存器中以便被处理。
硬盘位于存储结构的最底层。 因为它们便宜,可以负担得起大容量的存储,但代价是性能的降低,它不仅是最慢的介质,而且具有最高的延迟。
图2.2存储层次
主内存是CPU高速缓存下面的第一级存储,它是可直接访问的。与
访问
硬盘上的数据相比,访问主存储器中的数据性能可以提高100,000倍。与将磁盘作为主要存储器并将内存用作数据处理缓冲的常规DBMS相比,将数据存储在内存中,仅访问时间的提升就可以大幅提高数据库性能。
2.1.1确保持久性
将数据保存在内存中会产生一些问题。 首先,如果发生宕机会发生什么? 内存是易失性存储器,电脑断电会导致内存数据丢失。 在这种背景下,我们引用数据库技术中的基本属性包括原子性,一致性,隔离性和持久性(ACID),以确保数据库事务的可靠处理,并且不易受到外部中断的影响。
SAP HANA的持久层确保数据写入的持久性,并且数据库可以在重新启动后恢复到最近的已提交状态。 为了实现这个目标,持久层使用预写日志,影子分页和数据保存点的组合,使用磁盘存储日志和保存点。 在电源故障后重新启动时,数据库可以像基于磁盘的数据库那样进行恢复,首先从最近的保存点恢复数据库页面,然后向前滚动数据库日志以重做在保存点中未捕获的任何更改,最终使数据库处于与电源故障之前一致的状态。
2.1.2新性能瓶颈
由于
所有数据都保存在
内存中,磁盘访问不再是性能的限制因素。 随着内核数量的增加,CPU能够在单位时间处理越来越多的数据。 将数据从内存加载到CPU高速缓存的时间成为了内存数据库的性能瓶颈。
传统的数据库系统无法很好地解决这一挑战。 如果所有数据都缓存在传统DBMS中的内存中,则CPU会在花费一半的执行时间等待数据从内存加载到CPU高速缓存中。
为了实现期望的性能,关键是处理最小的数据集并且最小化内存和处理器之间传送的数据量。 在接下来的两节中,我们将讨论SAP HANA如何通过列式存储、编码和压缩格式来实现此目标。
2.2列数据组织
关系数据库的概念是指将数据存储在二维结构的表中。 表是按照垂直列和水平行存储的一组数据元素。 然而,存储器是单维空间,提供从零开始的存储器地址,并且线性地增加存储地址直到最大可用位置。 为了将数据存储在存储器中,数据库存储层必须决定如何将二维表结构映射到线性存储器的地址空间。
有两种基本方式,行式存储将表中的数据行按顺序进行存储,数据行的元素被存储在连续的存储地址中。 列式存储将表中的数据列按顺序进行存储,数据列的元素被存储在连续的存储地址中。
请看一个简单的例子,如图2.3所示,一个存储人员信息的表,包含四个字段:ID,名字,国家和城市。
图2.3人员表
在行式存储中,数据行的所有字段都连续地存储在内存中,如图2.4上部所示。 相反,在列式存储中,各列的字段被连续地一起存储,如图2.4下部所示。
图2.4不同的存储方式
两种存储模型都有其优点。可以从对行式数据和列式数据进行操作时使用的不同读取模式中进行分析,图2.4也展示了这些差异。
行式存储适用于行操作,
如下案例:
>应用程序
只
需一次处理一条记录(针对单行数据的多次选择或更新操作)。
>应用程序通常需要访问完整的记录。
>列数据包含不同的值,因此数据压缩率会很低。
>不需要聚合和快速搜索。
>该表具有少量的行,例如配置表。
列式存储对列操作有优势,如下案例:
>计算通常针对单列或少数列执行。
>基于列数据的值搜索数据表。
>数据表有大量的列。
>数据表具有大量记录,并且需要大量列操作如聚合、扫描等。
>大多数列包含几个不同的值(与行数相比)。
SAP HANA支持行存式存储和列式存储。 列式存储实现了高性能,这表明企业数据库上的工作负载大多是面向读取的。在大多数情况下,对于大量行数据的处理,只相当于少量列数据的处理。 这些因素有利于在企业场景中使用列式存储。
列式存储通过仅访问相关列来实现有效的映射,从而减少存储器访问的次数。 对单个列的操作(例如搜索或聚合)可以循环访问存储器中位置连续的数据。 可以高效利用存储空间和CPU高速缓存。 对于行式存储,相同的操作会更慢,因为同一列的数据分散在存储器的不同位置中,导致CPU高速缓存未命中,从而使CPU执行停滞。
列式数据存储允许高效压缩。 特别是当列被排序时,在连续存储器位置中将存在相同的值,因此可以更有效地使用诸如行程长度编码或群集编码的压缩方法。 尽管硬件技术发展非常迅速并且可用存储器的容量不断增长,但是有效的压缩技术在内存计算中起到了关键作用,第一,保持尽可能多的数据在内存中,并且最小化内存与处理器间的数据传输,以及
在磁盘和内存之间查询和传输数据。 我们将在下一节进一步讨论这个问题。
2.3数据编码和压缩
数据压缩是一组用于减少内存中数据存储位数的技术。 它降低了将业务数据完全保存在主内存中的内存容量要求(因此降低了成本)。 此外,由于内存和CPU之间的数据移动被最小化,所以可以更有效地对压缩数据执行读取操作。
2.3.1字典编码
字典编码是许多数据压缩技术的基础。 字典编码的主要效果是将较长的值如文本用较短的代码(通常为整数值)表示。
图2.5展示了将原始值转换到整数代码。
图2.5字典编码示例
字典编码按列编制,它为每个列构造一个字典,将列的每个不同值转换为不同的整数代码。 代码可以显式或隐式地存储在字典中(例如,通过字典中的值条目的位置)。 在我们的示例中,列fname的字典列出所有不同的值,字典中该值的位置(例如,Mary)表示该值的代码。 在这种情况下,数字24表示玛丽。 然后,在实际列存储中,它将列fname中的所有Mary实例替换为数字24。
字典编码用较短的数字替换较长的文本值。 当列包含许多相同的值(例如,在同一列表中的多个约翰,如图2.5所示)时,可以在存储器中有效地减小数据大小。 列中出现的相同值越频繁,字典编码的好处就越大。 在SAP业务应用程序中,与行数相比,许多列(例如,国家代码,状态代码或外键)只包含几个不同的值,使用字典编码将非常有效地压缩列数据。
2.3.2数据压缩
在字典编码之上,SAP HANA应用了许多轻量级压缩技术,例如前缀编码,行程长度编码,集群编码,间接编码和增量编码。 这些技术在更高的数据压缩率和编码解码所需的附加CPU周期之间提供了良好的平衡。
这些技术的更详细解释可以在Hasso Plattner的“内存数据管理课程”中找到。 我们注意到字典编码的基本思想也适用于行式存储。 然而,在行式存储,连续的存储器位置包含不同列的数据。诸如行程长度编码的许多压缩方法不能应用于行式存储。 与传统的面向行的数据库系统相比,在列式存储中可以实现高达10的压缩系数。
2.3.3
数据
压缩操作
通过使用字典来将文本表示为整数,字典编码不仅减少了存储器空间空间占用,而且增加了对编码数据的操作速度。 对整数编码压缩数据的操作与对未压缩数据的操作进行比较时,已经报告了在100和1000之间的性能提升。这种结果的原因有很多:
@压缩数据可以更快地加载到CPU缓存中。 因为新的限制因素是内存和CPU高速缓存之间的数据传输,性能增益超过了解码所需的额外计算时间。
@使用字典编码,列存储为整数数组。 许多谓词 - 例如,连接条件中的等于检查,将直接对整数代码求值。 这通常比比较字符串值快得多。
@编码可以加速诸如扫描和聚合的操作。如果对列使用行程长度编码,则合计列中的值将快得多,并且相同值的累加可以由乘法代替。
@某些操作(例如COUNT或NOT NULL)可以直接使用编码数据操作,而不必从字典中检索实际值。
@如果字典本身被排序,则读取操作可以进一步从字典编码中受益。 排序的字典就像索引,可以使用二分搜索法检索字典中的值。
与通过字典的全扫描相比,这具有大大降低的时间复杂度。 当然,这种增强的成本是必须在添加新值时维持字典的排序顺序。
2.4并行执行
SAP HANA的另一个关键方面是其在内存中处理数据时最佳并行能力。 这对于利用现代多核CPU是非常重要的。 它也是
实现
多节点横向扩展和确保这种分布式系统可扩展性的关键。
SAP HANA专为并行数据处理而设计,可以根据核心数量进行扩展,甚至可以在分布式系统中跨多个计算节点。 特别是对于DBMS,针对多核平台主要优化了以下几点:
@将数据分区并对各个分区并行执行操作
@避免顺序处理,尽可能确保可扩展性
2.4.1列式存储中的并行执行
基于列的存储通过使用多个处理器核简化并行处理。 在列存储中数据已经被垂直分区, 这意味着可以在不同级别上实现并行处理。
首先,可以容易地并行处理不同列上的操作。 如果需要搜索或聚合多个列,则可以将这些操作中的每一列分配给不同的处理器核心。
此外,通过将列划分为由不同处理器核心处理的多个数据段,可以并行执行单列数据的操作,如图2.6所示。
图2.6列存储中的并行处理
2.4.2并行聚合
诸如COUNT,SUM,AVERAGE,MAXIMUM和MIMINUM的聚合函数是并行执行的完美示例。 如图2.7所示,SAP HANA通过产生并行的多个线程来执行聚合操作,每个线程对存储器中的单独数据段进行操作。 每个线程以循环方式执行聚合函数,如下所示:
1.在内存中获取输入数据的分区。
2.计算该分区上的聚合值。
3.重复步骤1和2,直到处理完成全部的输入数据。
每个线程都有一个私有缓存区,在其中存储本地聚合结果。
当所有线程完成时,合并所有私有缓存区中的聚合值以产生总体结果。
图2.7并行聚合示例
2.5增量存储与合并
这是SAP HANA最后一个
关键
概念:使用增量存储来解决
数据插入与合并操作中列存储中的潜在性能问题。 我们将从插入操作面临的问题开始,然后说明增量存储与合并如何帮助我们
解决这些问题。
2.5.1插入
让我们先看看当一个新的记录插入一个列式存储的表时会发生什么。 在列存储中添加新记录意味着向表的每个列添加一个新条目。 因为表的每个列由字典和属性向量组成,所以向列添加新条目包括以下步骤:
1.查找新条目的字典,如果找不到条目,则添加新值。
2.将相应的值添加到列的属性向量。
如果字典被排序,处理将更复杂, 向字典添加新条目可能需要对字典
再次
进行排序。 另外,属性向量也必须被更新以反映字典的新序列,之后可能需要重新计算压缩,这可能会对插入性能产生重大影响。 SAP HANA通过增量存储解决此问题。
2.5.2增量存储
正如我们刚才看到的,直接插入数据到压缩列可能很慢。 为了解决这个问题,SAP HANA引入了增量存储的概念,其中列式存储表包括主存储和增量存储,如图2.8所示。
所有写操作(插入,更新和删除)只发生在增量存储中,这是一个单独的缓冲区。 任何写操作都不涉及主存储。 与主存储相同,增量存储也是面向列的,这意味着表的每个列都有一个增量存储并使用字典编码。 为了优化写入性能,不对存储的字典进行排序。 当添加一个新条目时,它只是附加到字典的结尾。 此外,除了字典编码之外,不应用进一步的压缩技术。 增量存储仅存储在内存中,不包括在保存点中。 只有日志被写入磁盘,以确保增量存储的持久性。
图2.8增量存储的概念
主存储被高度压缩和优化以优化内存消耗和读取性能。 尽管写操作只影响增量部分,但是读操作必须在主存储和增量存储上执行,因为表的当前状态是主存储和增量存储的集合。 在查询执行时,查询被逻辑地转换为主存储和增量存储的查询,然后组合两个部分的返回结果以构建总体结果。
2.5.3增量合并
增量存储随数据表的条目变更次数增加而增长。 过大的增量存储对系统整体效率和读取性能具有负面影响。
首先,增量存储不是压缩的,这意味着它消耗更多的内存。
其次,增量存储中的字典没有排序,这使得插入新条目
更容易
,但是查找条目的成本更高。 为了优化系统的查询性能并确保最佳压缩,增量存储需要保持尽可能小。 为此,SAP HANA使用在线重组进程,该进程定期将数据从增量存储传输到主存储。 这个过程称为增量合并。
增量合并过程可能需要高昂的代价,因为它涉及重排序字典和重新计算压缩。 SAP HANA使用双缓冲机制来最小化增量合并进程对系统的整体可用性的影响。 图2.9说明了合并过程的三个阶段:
@在合并操作之前
所有写操作都进入增量存储1,读操作从主存储区1和增量1读取。
@在合并操作期间
当合并操作正在运行时,所有更改都进入第二个增量存储,即增量存储2。 读操作从主存储器1和两个增量存储器进行读取。 增量1中未提交的更改将复制到增量2。 主存储1的内容和增量1中的已提交条目被合并到新的主存储器2中。
@合并操作后
在合并过程完成后,主存储1和增量存储1被删除。 通过这种双缓冲方式,在开始合并、未提交的事务被移动到增量2,以及在处理结束存储器被“切换”时,表仅需要被短时间
锁定
。使得合并过程可以高度并行化,而不会锁定数据而导致读取或写入失败
图2.9合并过程
SAP HANA引入了一种在企业中构建业务应用(例如财务应用)的新方法。 使用列式存储的内存数据库现在被视为
企业
的
骨干
系统,在同一个系统中进行分析和事务处理,
诸如并行化,字典编码,数据压缩,数据插入和增量存储等技术讲述了一个令人信服的故事,使SAP Simple Finance等应用成为现实。