2.1 旧瓶颈和新问题

在过去的数据库管理系统的设计中，我们都把关注点放在优化硬件和有限的内存之间的性能的问题上。例如，当处理一个查询的时候，先最小化磁盘页的数量，然后将数据读入内存，但是磁盘的I/O依然是最主要的瓶颈。从磁盘读取数据到内存，以及CPU的各级缓存之间的速率差，这依旧是目前所有应用系统最主要的性能问题。

虽然目前磁盘I/O速度有所提升，或者使用SSD（Solid State Disk，固态硬盘）进行替代，也能提升磁盘I/O，但是总体还是以磁盘为主。因为SSD目前容量普遍较小，价格比较高，考虑到存储的稳定性，而且在存储层面进行RAID之后，容量减少较多，而且频繁的写操作会产生碎片，随着时间增长，操作的性能会不断下降，读写速度仅比传统磁盘快几倍左右，总体的性价比不高。从当前来看，SSD并不太适合做海量数据库的核心主存储介质，但是SSD倒是比较适合于以下两种情况：

❑提升数据提交的Redo/Undo响应时间。

❑作为内存和磁盘之间的缓存层，提升数据的读取速度。

以上原因导致SSD目前还无法取代传统磁盘作为主流存储层。目前很多PC服务器的自带磁盘中都使用SSD作为闪存缓存，以提升持久层的I/O速度，这在一定程度上可以缓解磁盘I/O的瓶颈问题，但是磁盘I/O依然是目前尚未解决的几大瓶颈之一。

另外，因为CPU主频速度的变快已经没有过去那么迅速，而传统软件架构大多依赖CPU处理速度来提升性能，加上现在的多核大内存的创新硬件架构发展得又如此迅速，所以迅速发展的多核CPU将取而代之，并且将成为未来增强计算机计算能力最主要的技术手段之一。这样的新技术背景下，传统的联机事务处理系统（OLTP）因架构设计问题而无法高效利用当前新硬件架构。

从很多权威的研究资料中都能看出一个明显的信号（例如，1999年，Ailamaki等人对于传统磁盘的数据库管理系统在CPU上的时间开销分析，以及传统数据库管理系统在CPU上的瓶颈），如果软件架构不发生革命性变化（例如，使用内存计算技术在软件层面调度、管理硬件运算资源的并行化、任务拆解、分发），即使在硬件上投入再多也依然无法解决性能瓶颈的问题。基于内存计算技术架构的软件可以高效解决数据吞吐的瓶颈问题，但是又带来了新的瓶颈，这些新的瓶颈限制了传统的内存计算技术的进一步发展。

首先，传统内存计算技术也是有瓶颈的，它的瓶颈就是CPU和内存之间的数据交换，当然这个瓶颈在过去基于磁盘的数据库管理系统中也是存在的，只是那个时候最主要的瓶颈是磁盘I/O，和磁盘I/O的瓶颈相比内存计算的瓶颈是忽略不计的。在内存数据库的体系下，即使不解决内存计算的瓶颈，内存数据库系统也能比传统的磁盘DBMS的执行效率高很多。图2-1展示了过去使用磁盘I/O的旧瓶颈和当前使用内存计算的新瓶颈。

问题就摆在这里，是无法回避的，接下来就了解一下SAP HANA作为新一代内存计算技术的内存数据库管理系统是如何利用创新的软件架构解决这个新瓶颈的。例如，利用多核架构的硬件系统、NUMA结构、列存储数据压缩和CPU预存储，以及减少数据传输等各种优化手段解决新瓶颈。

2.1.1 内存计算也有麻烦

过去，在计算机软件架构设计中创立了一种新的很有挑战的且早已实现的技术，那就是将所有的数据全放在主内存中进行计算，这样磁盘读写不再成为限制系统性能的瓶颈。而且不断增长的CPU内核数量，可以有能力在同一瞬间处理更多数据，这意味着性能的瓶颈不再是磁盘与内存、缓存之间的问题。

基于内存计算技术的数据库系统可以有效地解决磁盘I/O的瓶颈，于是各种开源或商用内存数据库都开始采用这项技术，内存缓存型数据库开始流行，但是由于早先硬件架构技术无法匹配内存计算技术的要求（例如，多核CPU价格极其昂贵，并且处理能力有限，以及DRAM价格居高不下无法更大程度地横向扩展等），所以内存数据库系统一直都没有得到广泛的应用。

内存计算技术解决了数据从磁盘到内存的瓶颈，但是从整体上来看，内存数据库系统的事务执行时间依然有一半花在数据延迟上。例如，对于等待数据从内存上载到CPU的缓存中的情况，虽然现在很多CPU的三级缓存能够达到几十兆的容量，但是对当前的信息处理需求来说依然不够多，这就是现在所有系统正在面临的新瓶颈和挑战（稍后我们将介绍SAP HANA如何有效改善这一状况）。为了充分利用现在的创新硬件架构，全新一代的高性能数据库系统必须具备以下典型特征。

（1）高性能内存数据库管理系统

将所有的数据都保存在内存中，处理数据的读取时不会有磁盘的I/O负担，磁盘仅作为数据的持久层存在，而且所需的数据写入操作也是在后台的异步操作中完成的，同时支持OLTP和OLAP。

（2）CPU缓存和内存之间的有效组织、优化和执行

必须最小化CPU缓存丢失次数，避免内存访问过程中的CPU处理上的延迟，实现这一目的的方式之一就是在内存中使用列式数据存储技术。列存储技术可以有效地组织数据访问序列，使数据的读取都在临近的内存地址中完成。

因此，对数据的操作可以全部在CPU的缓存中完全执行完毕，而不必对内存中的数据进行耗时的随机访问，何况这样容易造成延时。如果无法处理好内存和CPU之间的有序访问，即使是内存计算技术也会面临新瓶颈。

（3）支持大并发处理

从最近几年的发展趋势来看，主流CPU设计都从主频时代走向多核时代，因此软件架构的设计可以使用多核处理器带来的优势，例如并行处理可以利用多核架构来实现大数据的处理。

2.1.2 多核CPU时代

现在的计算机架构已经发生了变化，正在由主频变快转向多核，CPU主频的增长趋势不像过去那么迅速。最早的双核CPU是由像IBM、HP、Sun（现已被Oracle公司收购）这样的厂商设计并生产的，因为价格非常昂贵，而且只支持自身的RISC架构和高端服务器市场，所以没有得到大范围的普及和应用。

目前，广泛为人所知的双核或多核产品，主要是由Intel、AMD这两家厂商所生产的，已经普及到目前所有的CPU市场。从嵌入式系统、手持设备、笔记本电脑到企业服务器，目前几乎所有主流的服务器厂商都基于多核CPU推出了各自品牌的高、中、低端服务器。

从2005年开始，所有CPU的内核数量都在不断增加，并且能耗和体积不变，而且在今后几年将可以广泛使用包含16～32个内核的单颗CPU。随着CPU内核的数量不断增长，目前很多单台基于Intel x86架构的主流PC服务器的主板都可以搭载4～8颗CPU。和很多品牌的小型机、大型机的高昂价格相比，基于x86多核架构的硬件体系服务器能提供更强的计算能力和极好的投资回报比，无论是考虑短期的投资还是考虑长期的维护成本，这都是值得选择的。

2.1.3 打破FSB瓶颈

从上述内容我们可以了解两个最重要的因素：多核CPU的趋势已经开始，商用大内存越来越廉价。图2-2是一个普通的SAP HANA认证服务器，这个服务器搭载了4颗8核（32核×2=64线程，超线程技术）的Intel Nehalam CPU，提供8个内存扩展模块，一共可以支持1TB的内存，而且最新的单台SAP HANA服务器也已经拥有超过4TB内存容量。因为PC服务器的计算能力越来越强，所以还可以扩展更多节点和内存容量，这部分内容我们将第12章介绍。

FSB（Front Side Bus，前端总线，参考图2-3），可以理解成CPU和其他所有I/O的唯一接口，注意其带宽是有限的。在之前的CPU设计中，即使内核较少，也可以在软件设计上进行数据压缩，以缓解数据供应的瓶颈问题。随着CPU的处理速度越来越快，而且内核数量越来越多，前端总线受到技术的限制无法再提供更多的带宽，这其实使CPU性能发挥受到限制，因此FSB的带宽成为一个瓶颈，目前其带宽提高已经跟不上处理器计算能力的增长速度。

基于这种架构设计的服务器会存在争夺FSB资源的问题，而且随着处理器和芯片组性能的不断提升，在FSB上的通信流量也会上升，从而会导致FSB变得十分拥挤，这将成为系统性能的又一瓶颈。

后来Intel公司推出QPI（QuickPath InterConnect，快速通道互连）技术，用以取代过去的FSB架构。例如，Intel Nehalem EX系列单颗CPU，最多可以做到10个CPU内核，并且提供4个QPI通道，除了嵌入的一级、二级缓存之外，Nehalem系列还有一个三级缓存，大约30MB，可以被CPU中的所有内核所共享，并且内嵌了集成的内存控制器，CPU内核通过集成的内存控制器直接访问本地内存。

从早期开始，SAP公司就和Intel公司长期联合进行深入的技术合作，这使得HANA能够很好地利用多核、大缓存的硬件架构。基于新的QPI的点对点连接技术，使得CPU可以快速和其他的CPU或内存，以及I/O设备通信，HANA正是为了获得这种多核架构的并行化数据处理优势而专门设计的，其中一些优化的SIMD（单指令多数据流），比如SSE3、SSE4等指令集，在SAP HANA数据库底层的代码中被广泛使用。

Intel Nehalem EX架构的单个刀片服务器最多支持8颗CPU，每颗CPU多至10个内核。以一个4颗CPU的主板架构设计来举例（见图2-4），这里的每颗CPU都有4个QPI通道，其中1个通道用于连接I/O控制器，其他的3个QPI通道都用来连接其他的CPU，使得CPU之间可以有比FSB更快的数据通信速度，另外，使用超线程技术可以同时处理比内核数多一倍的线程，并且还可以使每个CPU使用多个多通道的内存控制器来访问对应这个CPU的本地内存（相邻的内存插槽）。在这样的硬件架构上，HANA可以很好地实现在内存计算中的高并发读写和本地内存访问机制。

2.1.4 高效利用NUMA

使用QPI替代了原先的FSB架构，使得各服务器上的各CPU都有对应的本地主内存，并且所有CPU缓存均共享可用内存的统一视图，这种基于“多核共享内存处理器设计架构”的访问称为非一致性内存访问（Non Uniform Memory Access，NUMA），而早先基于FSB架构的访问则可以称为“一致性内存访问”。

根据“非一致”这个字眼和前面两种架构图，我们可以很容易地了解到，访问内存的耗时和带宽取决于CPU内核的访问内存的相对位置。CPU内核访问自己的缓存和访问自己的本地内存、其他CPU的内核所对应的本地内存的速度都是不一样的。

为了有效利用NUMA这种创新的系统架构，需要我们在软件应用架构层面让CPU内核主要从本地内存中加载数据，而不是从其他CPU的本地内存来加载数据。简而言之，就是尽量让一个CPU去访问和计算这个CPU所对应的本地内存中的数据，而不是从其他CPU的本地内存中读取数据。这是需要从软件层面来实现的，而SAP HANA就很好地实现了这一点。

在分布式环境下，所有的数据查询请求都被拆分成一个个子任务，然后在所有服务器节点上执行，因为在执行并行任务时，为了避免本地CPU内核访问其他CPU内核或其他服务器上的CPU内核的本地内存中的数据，我们需要在将数据加载到内存的时候，做好数据的分区。如果不进行数据分区，那自然是CPU随机访问其他服务器的CPU对应的本地内存，如果是这样，NUMA的性能会很差，频繁进行CPU之间的数据传输会导致QPI的堵塞，或者因随机访问而造成数据延迟。图2-5是SAP HANA集群环境的示意图。

从单节点的NUMA架构服务器中得到灵感，现在我们也可以利用各种最新的技术，例如InfiniBand适配器、10GB～100GB以太网，或各种专有服务器之间互连的技术。将数百个多内核CPU服务器搭建成一个庞大的NUMA服务器集群，可以做到共享几百个TB的内存，这与目前我们看到的很多基于x86架构的一体机服务器是同一个原理，只需要解决NUMA时QPI阻塞的问题，从根本上来看，这个问题还是要依靠创新的软件架构来解决。

2.1.5 CAP的偏向性

根据早先CAP理论（见图2-6）中所描述的内容，数据库管理软件系统在某一个时间点对某个数据无法同时满足3个重要特性，即数据一致性、可用性、分区容错性。一开始，传统的关系型数据库主要遵循ACID原则和高可用性，所以在一定程度上牺牲了分布式和扩展性，适合对数据有着极高一致性要求的金融、电信等企业使用。

经过近几年的发展，采用BASE模型发展了新型分布式数据库系统（如No-SQL、Google Bigtable，以及开源实现的Hadoop-Hbase等）。采用BASE原则可以大大提升数据库的高可用性和扩展性，但却使用“最终一致性”的方式去保证数据的一致性，这虽然能够保证数据的一致性，但的确为了更多的P（分区容错性）而牺牲了一些C（一致性）。SAP HANA也是关系型数据库的一种，首先要遵循ACID原则，但是从其软件架构上可以看到，SAP HANA的设计原则是内存计算加并行运算，在架构上则是通过不断增加物理节点，从而实现对更大规模数据的并行运算。这意味着需要对数据库进行分区，换来系统的高扩展性，这其实又是借鉴了BASE原则的设计理念。这样来看，SAP HANA的目的就非常清楚了，基于ACID原则进行基础设计，但是却要提供BASE所能够带来的并行化和高可扩展性。如何在分布式计算的规则下保证数据库的一致性，从而突破CAP对系统架构设计的束缚，大概可以从以下几个方面来实现：

❑使用内存计算技术，最大化数据读写速度。

❑在数据并行访问中使用新的锁机制，从而提升数据访问的并发能力，消除串行数据加/解锁的系统开销。

❑数据库表智能自动分区，数据自行分布到不同的服务器节点，每个节点只可能处理自己节点上的数据。

❑多节点和多份数/日志实现分布下的高可用。

❑使用共享内存和无共享技术，在物理上采用多节点，共享所有内存+无共享的架构方式，最大化利用所有计算机的计算能力。

为了解决旧的问题而衍生出的新问题该如何解决呢？

前面我们了解了计算机技术和IT应用的主要性能瓶颈是磁盘I/O，为了解决这一瓶颈引入了内存计算技术，但是早期的内存计算技术因软件架构设计的滞后性而无法高效利用全新的创新硬件架构。然而新硬件架构的多核、大内存、NUMA架构又给软件设计带来了新的问题，例如，内存和CPU之间的带宽问题，即如何在有限的带宽下，让CPU处理更多的数据；在NUMA的架构中，如何让内存尽量访问本地内存，以及避免高速缓存失效等。综上所述，基于传统架构的软件在新硬件架构上运行大概有以下几个待解决的问题：

❑如何有效地利用CPU多核，同时避免高速缓存缺失。

❑如何提升CPU的吞吐量、优化数据读取。

❑CPU和内存之间速度差异。

❑采用更多内核，因为压缩数据造成CPU计算周期变长。

❑如何有效利用NUMA+QPI架构。

列举以上这些，只是想简要说明一个问题，即软件架构本身不做创新和改变是无法驾驭和充分利用新硬件架构所带来的优势的。关于以上这些技术点如何在SAP HANA上实现，以及SAP HANA进行了什么样的技术创新，将在后面的2.4节阐述。