SAPHANA平台有各种各样的应用场景，这也意味着客户的实施方法有许多种选择，关键是如何挑选最适合他们需求的实施方案。

在《Implementing SAP HANA》这本书中，介绍了SAP平台在现实场景中的运作原理，并给出了实施建议和成功案例供参考。本系列文章节选自《Implementing SAP HANA》，介绍了行存储和列存储的各自特点，以及SAP HANA的数据存储方式如何提升空间压缩和性能。

在第三篇文章中，我们主要介绍了列式数据存储技术以及SAP HANA的应用。

列式数据存储技术

最后一种数据存储技术，也是与SAP HANA最相关的技术，就是列式数据库架构。列式数据库也在解决磁盘访问性能缓慢的问题，它修改了数据在磁盘上存储的方式。

列式数据库存在很长时间了，这个概念当然不是SAP HANA创造的。这是一种设计思想，SAP HANA设计独有特性和数据存储时整合了这种思想，拥有了列式数据库给数据存储带来的价值。列式数据库仍然把表作为逻辑组件来存储数据，但是数据在磁盘上分布的方式与标准的行式存储的表不同。数据值都是以列形式存储的，而不是行形式。举个简单的例子，有个颜色和产品描述的产品表，这是数据库中以行形式存储的逻辑表。

行式表中的数据存储。

在磁盘上物理存储的数据也是以行形式组织的。对于OLTP系统来说，这是一个非常好的设计，也是这个世界数据存储的事实标准。而列式表存储的数据在磁盘上的存储情况就差异很大了。下图展示了同样的数据列式存储时的形式。

列式表中的数据存储

需要注意的是列式存储中重复值只保存了一次，最小化了数据在磁盘上的物理空间占用。

列式存储表仍然可以是关系型表和数据。差异在于数据在磁盘上的安排方式。

基于这些原因，我们应该考虑把现有结构迁移到列式结构，虽然这不是不可完成的任务，但是要把数据迁移到不同的平台肯定有许多因素要考虑。如前所述，SAP HANA缓解了这些问题，因为其内存存储性能非常快。但是如果你要对非常巨量的数据仓库结构做迁移，你仍然应该考虑这些问题。这种迁移需要做许多ETL处理，更多的是针对非SAP数据。

插入基于磁盘的列式存储表

我们最近为一个数据仓库OLAP结构数据做了迁移，从SQL Server到SAP（Sybase） IQ，利用了列式SAP（Sybase）IQ表中的高级压缩和读操作技术。然而，我们也注意到有一些因素在操作过程中应该加以考虑。这些考虑因素在SAP HANA中大概可以通过内存存储得到一定缓解，但是它们仍然值得考虑，因为它们毕竟是列式数据库技术的范畴：

• 查询语句或者读操作比传统基于行存储的数据库速度更快。数据会加载到临时数据库，在那里做多种转换。
• 使用批量插入上传数据相当快，应尽可能使用，尤其是在数据量大的情况下。
• 更新和合并目标操作比传统基于行存储的数据库较慢。
• 需要更新时删除插入操作更快。

主要结论是，对于这样的报表“SELECT”SQL语句或者数据读操作不需要修改太多，但是需要插入、更新和删除操作的ETL处理需要做修改，尤其是delta或者基于变更的数据加载。

使用SAP HANA的解决方案

我们讨论了OLTP、OLAP和列式数据存储方法，以及它们产生的原因，从这个意义上讲SAP HANA是独一无二的，像变色龙一样可以适应各种情况。SAP HANA可以像所有这些平台一样，首先实现行式或列式物理存储；然而更重要的是，它还可以用过OLAP结构甚至通过解释多维表达式（MDX查询语言）来处理数据。它还提供了通用的传统SQL接口。

本质上，SAP利用了所有这些平台天生的优势。这种适应性是SAP的巨大优势，因为它可以快速无缝地与许多传统应用程序对接。如果有多维的基于数据立方的应用（比如SAP BW或者SAP业务计划和整合SAP BPC），都需要MDX对接数据，那也没有问题。大多数针对数据库的应用接口都是通过SQL实现，SAP HANA对SQL的接口方式一样也是顺畅的。

需要注意的是，这些技术的发明大多数是为了与基于磁盘的数据访问缓慢做斗争的。但是SAP HANA则不同，即便我们把它用成这些传统技术的处理方式，它也能直接解决一些性能问题。SAP HANA不是基于平台的问题进行处理，而是直接一起改变了平台。它略过了磁盘，数据直接存储在内存中，CPU操作起来性能更优。SAP HANA本身兼容其它这些技术，只是与产品有关的策略，为了推进SAP HANA作为一个平台替换现有传统数据库技术的采纳率，同时给开发者提供对数据访问和建模的令人兴奋的新方式。

SAP HANA在开发者平台方面做了进一步反思，把各种数据处理层转入到应用中，这样开发者必须重新认识他们在实现的内容。这是真正革命性的平台。