SAP HANA是一个全新的数据库平台，它提供了全新的数据建模方式，使得传统关系型数据库管理系统（RDBMS）得到了进一步的扩展。但是新的东西往往都隐藏着新的挑战，要想让SAP HANA的性能达到最佳，你就需要比以往更加精细地处理数据。

　　虽然SAP HANA的数据仍然是存储在table中，但是它与传统数据库的数据存储模型是有所区别的。列存储的数据压缩性更好，且读取速度也更快，这一点毫无疑问。而要充分利用这一点，它的数据建模就要有别于传统基于行的RDBMS，这主要是基于两点原因：

　　其一，同行式数据库表相比，冗余数据在HANA中并不是大问题。列式数据库表通过提供指针来引用重复的数据，因此重复值仅会存储一次。此外，当数据不是扁平进入一个表当中，或者在HANA的多个表中未进行标准化的时候，表连接的消耗将是相当大的。HANA提供了基于行和基于列存储的两种数据库引擎，不同方式的处理会同时出现，而当数据需要物理地从一个引擎移动到另外一个进行处理的时候，表连接的消耗就会提升。所以，我们要尽量将数据处理过程保持在一个数据库引擎中，而且最好是HANA的列式数据库引擎。

　　表连接消耗对于传统数据库来说影响会比较小，主要因为索引和标准化，而在HANA中它是不容忽视的，你需要监控数据库查询是否违反了列存储结构的约束。如果处理过程在列式内存数据库引擎中不支持的话，那么结果就是它会物理地移动到行数据库引擎当中，这对于性能的破坏是可想而知的。因此，在SAP HANA的配置阶段，你仍然需要对数据进行建模。记住，它与传统数据库的数据建模设计会有很大的不同。

　　在数据建模和配置完成之后，你就需要马上着手处理元数据（metadata）。首先要对基于列式数据库表中的数据供应进行“属性”和“分析”视图的建模，这些视图的运转原理同传统数据库的视图很类似。属性视图设计用来给主数据（master data）设定上下文环境：它们提供有意义的数据值，比如ID列的描述或者实际ID值的名称等。

　　分析视图是运算与聚合发挥作用的地方。包括属性视图和分析视图在内，它们都将成为最终生成“计算”视图的基础。计算视图结合并扩展了分析视图与属性视图，这个以元数据驱动的内存运行时计算模型正是SAP HANA的最大价值所在，因为元数据层往往会免去将数据存储到分配表之外其他层级的操作。

　　尽管在SAP HANA中进行建模通常被认为就是玩转计算、分析或者属性视图，但同时需要强调的是要在内存中对数据进行合理的分配。数据必须符合其存储结构的需要，SAP HANA也不例外。虽然数据模型能够直接从传统RDBMS的个星形schema移植过来，但是精心测试并设计一个合适的基础模型，你将从SAP HANA中得到更多的回报。

　　SAP HANA如何处理数据？

　　在早期版本的RDBMS中，由于技术限制，数据只能首先被建模到物理的基于行的表中，并存储到磁盘上。后来我们普遍使用了索引，来通过SQL查询进行快速的数据访问。索引目前仍然是数据库当中非常重要的技术，因为它是围绕传统行式交易型数据库概念进行设计的。

　　在这个平台中，读数据不是主要的目的。它的结构是围绕如何将数据载入来设计的，而不是导出。再后来，联机分析处理（OLAP）数据库结构，有时我们直接指代cube，成为解决行式数据库报表性能瓶颈的新一代解决方案。OLAP也是将数据导出的首次尝试，它将主要精力放在了读取数据上。然而缺点是数据需要转换到额外的持久性存储之上，因此它的整个过程都是非常复杂并且成本颇高（存储与计算）。

　　然后，列式数据库的出现成为上面方法的替代品，它对于存储数据用来进行生成报表是非常高效的。列式数据库的数据存储效率非常高，因此免去了额外的数据层需求。读性能更好，但是写数据的速度势必会变慢变复杂。

　　再然后，就是SAP HANA的出现。可以说它是集合了所有上面所提到的数据库设计理念，唯独有一个差别：就是SAP HANA是将所有的数据集存储在内存之中的。

　　SAP HANA将数据尽可能地存储在离CPU最近的地方：内存。数据以行式与列式两种方式物理地存放在内存当中。它还能够通过特定类型的逻辑视图进行建模，来仿真基于cube的存储结构。