HANA性能浅析

没有

。。。

我有HANA

HANA性能

了解一下

SAP HANA作为一个内存计算平台，“全内存，没有I/O瓶颈，性能优异”，是一直让SAP引以为傲的卖点。作为数据库市场后起之秀，HANA面世以来，取得了不俗的成绩，屡获殊荣。然而，我们也看到了一些现象：HANA似乎在SAP的怀抱里停留太久，没能作为一个通用的数据库走向更开放的市场，特别是OLTP领域。即使在SAP内部，也有不同的声音。例如，Hybis on HANA，几乎是屡战屡败，性能是主要原因。为什么会出现这种两边倒的现象呢？本文尝试从HANA技术实现原理入手，分析其性能表现，为大家更合理的定位HANA提供一些借鉴。

内存存储、列式存储、并行计算，是HANA最核心的技术特性。以下，我们分别从这三个方面来探讨HANA的性能问题。

内存存储

从关系型数据库诞生的那一刻起，数十年来，人们一直致力于解决I/O瓶颈问题。在当时，内存是昂贵的，数据不可能完全存放在内存中。所以，传统的数据库以磁盘为主要存储（PrimaryStorage）,内存为缓存，起到加速的作用。HANA反其道而行之。现代服务器，内存足够大。HANA以内存为主要存储，磁盘仅仅是用来确保数据的持久性。内存的速度比起磁盘快若干数量级，理论上，HANA比起传统数据库，性能提升必然是显著的。不论在实际应用中，还是PoC测试中，HANA的表现相当惊艳。

由于所有数据都在内存中，HANA在数据的查询过程中可以做到零I/O。不过，所有内存数据库，都必须解决一个问题：数据的持久化。HANA也不例外。HANA是以固态盘（可选）+磁盘来确保掉电的情况下数据不丢失。HANA的持久层由两部分组成：Log Volume和Data Volume。执行DML（Data Manipulation Language）操作时，HANA在内存中写入新数据副本的同时，把数据的变更信息写入到LogVolume中。对于OLTP应用系统来说，这样的写入过程是离散的、高并发的，对IOPS有较高的要求。所以，HANA一体机往往使用PCIe SSD来作为Log Volume。相对而言，OLAP系统在写入数据方面，主要是处理大批量的数据import、以及数据库内的批量DML作业，写入操作是周期性、低并发的，IOPS的需求略低。

接下来，我们来看看Data Volume的IO情况。Log Volume只是记录了数据的变化，真正的数据主体是存放在DataVolume中的。HANA周期性地把变化的数据和存量数据合并（DeltaMerge），并压缩、优化存储结构，最终写入到Data Volume中。这个过程，是周期性的、批量的，系统根据资源状况自动控制并发，对I/O的需求主要是高带宽、大吞吐量。所以，通常Data Volume用SAS磁盘就可以应对。

也就是说，在数据的持久化存储层面，HANA还是有I/O操作。传统的数据库，也有类似的Log/Data概念，即两阶段的I/O。从这个层面上来说，HANA在处理DML的时候并没有减少I/O，只不过在数据查询的时候，无需任何I/O。所以我们可以初步得出这么一个推论：上层应用系统的查询比重越高，HANA的性能优势越明显。反之会怎么样呢？我们继续分析。

列式存储

HANA支持列式存储结构（也称为垂直存储）。最早的列式数据库，可以追溯到C-Store，而最早大规模商用的则是SAP IQ（Sybase IQ）。近几年，市场上涌现出众多新的数据库产品，绝大多数都采用了列式存储结构。即便是老牌的Oracle，也在其新版本中增加了这个特性。垂直存储的流行，源于它在处理大数据集的OLAP场景时有得天独厚的优势：只需要访问必需的列，极大减少不必要的数据访问。列存储带来的另一个附加好处是数据压缩。对HANA而言，列存储结构更易于在内存中实现，更方便使用SIMD（Single InstructionMultiple Data）指令集进行高速数据处理。列存储结构，使得全内存运行的HANA在OLAP方面如虎添翼，创造了诸多的性能奇迹。

然而，列存储是把双刃剑。大多数的列式数据库，都是面向OLAP市场的。这也反证了列库在OLTP领域存在不足。HANA也面临同样的问题。假设要写入的一张表有n个字段，对于行存储数据库来说，只需要一次写入操作，把这n个字段的值写入连续的磁盘物理块即可；而列存储数据库就麻烦多了，需要把这n个字段的值，分别写入到不同的磁盘物理块。实际的操作远比这个复杂，总体来说，我们可以认为列库在写入数据的时候，I/O量是传统行存储数据库的n倍，其中n是表的字段数。所以，大多数列库直接放弃了对OLTP应用的支持。Vertica采用了ROS（Read-OptimizedStore）+ WOS（Write-OptimizedStore）的混合结构，试图通过WOS来缓解这个问题。即便如此，Vertica还是局限在OLAP市场。SAP IQ 中也增加了In-MemoryRow-Level Versioning，试图来解决OLTP类型DML问题，但其表现差强人意。HANA是世面上唯一一个敢于以列存储结构来支撑OLTP应用的数据库引擎。勇气可嘉，但也困难重重。

在OLAP类型的DML操作，一般是大批量的数据处理。通过合并数据写入以及数据压缩等技术手段，列库反而比行库更有优势。

所以，列存储结构，使得OLTP场景的DML的I/O数量剧增，给HANA的性能表现造成很大的障碍。

并行计算

计算机程序最核心的两个部分：数据结构和算法。我们前面探讨了HANA的数据结构——列存储，接下来我们看看HANA在算法方面的特点——并行计算。HANA中的并行计算，涵盖了从微观到宏观的并行。

宏观层面，HANA支持MPP即大规模并行处理(Massively Parallel Processing )。MPP通过把数据拆分到不同节点、分而治之，实现系统的扩展、性能的提升。相对于单机系统，MPP架构的主要技术难点在于数据的分割策略。合理的数据分布，可以让计算过程尽可能本地化，减少节点间的数据交换，利用更多的计算资源，快马加鞭。错误的数据分布，则是一场灾难，数据乾坤大挪移，网络成为瓶颈，通讯成本高过计算成本。一般来说，对于OLTP场景，SMP (Symmetric Multi-Processing)系统结构效率要比采用MPP结构要快得多。而MPP系统在决策支持和数据挖掘方面显示了优势。SAP在OLTP系统中，基本不推荐MPP架构的HANA。在OLAP场景下，则需要有良好的系统设计和运维能力，才能发挥HANAMPP的优良性能。

往下一层来看，在单服务器内部，HANA能够充分挖掘SMP的潜力。不同列的数据，可以交给不同的CPU core并行处理；同一列的数据，也可以横向拆解给多个CPUcore并行处理。这与现代CPU技术多核化的发展趋势非常契合。在处理复杂的、大数据集的任务时，其它传统的数据库往往是大量的CPU资源闲置着等待I/O，而HANA却可以把一体机的CPU100%地利用起来，从资源监控器里看起来极其壮观。HANA利用列结构加上并行算法，无需借助索引等传统个数据库常用的加速手段，就可以在海量的数据集上，毫秒级地扫描、定位、分析数据。

最后，我们来看微观层的并行。前面已经提到SIMD这个技术，SIMD单指令流多数据流(Single Instruction Multiple Data)是一种采用一个控制器来控制多个处理器，同时对一组数据（又称“数据向量”）中的每一个单元分别执行相同的操作从而实现空间上的并行性的技术。利用SIMD向量计算指令，HANA可以用一条指令，同时处理多条数据（有点类似于现在广泛用于挖矿的GPU机制），速度又能够数十倍的提升。HANA的并行可以说是无处不在。这就需要内存到CPU需要有足够的传输带宽，把数据传给整个计算机系统中最快的处理单元CPU。事实上，HANA实行认证一体机体制的原因之一，就是从硬件上保证HANA的这些特性能够充分的发挥出来。系统的总线带宽、NUMA的布局、CPU一/二级cache的配比等等，都是HANA一体机认证要考核的要素。

为了保证全方位的并行化，HANA会尽可能调用可用的CPU资源，将处理任务分解，以缩短所需的时间。任务越复杂，需要的计算资源越多，获益越明显。反之，对于一些简单的任务，并行化所带来的速度提升就不明显。高度的并行化，也带来一定的副作用。多线程执行，造成线程之间通信的额外开销增加。当并发任务增多时，这种通信成本随之攀升。曾经的一个实际POC案例，在执行简单聚合查询（Group by，无join）的并发压力测试中，高端8 CPU的服务器效率甚至不及4 CPU的服务器。

总而言之，高并发对HANA而言，也是一个挑战。

HANA的性能表现

单纯从数据库的角度来看，HANA的性能表现可以用这个矩阵来简单说明。

在不考虑成本和容量因素的前提下，HANA的性能完全能够胜任常规的OLAP场景。

让我们聚焦HANA在OLTP方面的表现。HANA在OLTP应用中，当前市面上使用最广泛的OLTPon HANA，当属S/4。目前为止，市场反馈良好，并没有多少性能问题出现。为什么呢？首先，ERP作为商务管理软件，其并发用户并是有限的，并发的DML规模基本是在HANA所能应对的范围；其次，ERP对数据库的访问，查询的比重高于DML；再次，ERP中比较慢的业务处理，往往是大数据量的、复杂的分析，已经偏向于OLAP，而这正是HANA的强项。此外，ERP的代码实现比较规范，DML中update的数量比较少（update的I/O成本高于insert/delete）。当然，最重要的是：SAP针对HANA的特性，在设计S/4时，投入了大量的资源，扬长避短，彻底重写了整个ERP，创造了业界奇迹。数据结构精简到极致，必然减少了DML数量；充分利用计算下沉的架构，减少数据在HANA与应用服务器之间的交互，发挥HANA内存计算、并行计算的优势。那么，为什么hybrison HANA就不能复制这样的成功呢？首先，hybris面向的是互联网客户，其并发用户远高于ERP，并发的DML容易超越HANA的极限。其次，hybris对数据库的操作逻辑比较简单，发挥不了HANA的特性，也没有太多可以深入优化的空间。所以，对于这种高并发、DML为主的应用场景，HANA就显得力不从心了。

总结

I/O瓶颈，是数据库业界的魔咒。全内存化的HANA虽然从某种程度上缓解了这个问题，也仍然需要I/O来实现其数据持久化，由于列存储结构，在OLTP的DML操作中，还是存在较明显的软肋。S/4等SAP自身应用，并发DML规模不大，DML的比重相对较低，加上SAP从结构到算法层，对应用做了深度优化，所以总体来说，性能是提升的。但是类似于hybris这样的面向高并发用户的系统，DML为主，HANA无法胜任。

而对于OLAP类型的系统，HANA的性能优势，可以发挥的淋漓尽致。

以下，是我们根据实践经验得出的一些建议：

1. OLAP市场，是HANA的强项；

2. 对于OLTP系统，请尽量选择带有SSD卡作为Log Volume的HANA一体机；

3. 对于非SAP的OLTP系统，请慎重选择HANA作为底层数据库；

4. 对于高并发写入的系统，请不要直接使用HANA；

5. 能用单机（+HA）解决的，尽可能不要用MPP集群；

6. 虚拟建模不是绝对的。如果一个模型经常被使用到，并且逻辑复杂，请考虑将其物化，这样有助于减少CPU占用；

7. 请不要将HANA直接面向互联网用户，并发太高。

OLTP数据库的研发难度，远胜于OLAP数据库。HANA作为后来者，要打造全功能数据库平台，还有许多功课要做。只有彻底解决DML的并发性能问题，HANA才可能走出SAP的庇护，走向更广阔的通用数据库市场。未来路在何方？NVM（NonVolatile Memory）技术的日趋成熟，或许能够在不久的将来实现真正意义的零磁盘I/O。OminiPath等100Gbps互联方案的成熟，或许能够缓解MPP的困境。硬件的创新，促进软件的变革。HANA一直紧跟潮流，顺势而动，如果能再次把握这些机遇，也许会有质的飞跃。

让我们拭目以待。