SAP 新产品内存数据库 HANA 的前景如何?

要回答这个问题，首先得弄清楚HANA是怎么产生的，它又具体是个什么东西。HANA的产生背景有下面几点：

1. 硬件发展趋势。CPU多核成为趋势，并且核越来越多，内存容量越来越大也越来越便宜。
   
2. 行业趋势。列式数据库、分布式数据库、数据仓库、数据挖据等等都已经发展的越来越成熟，大数据也正在蓬勃发展。
3. SAP对于企业级管理软件和数据库软件的反思。SAP无疑是企业级管理软件这个领域的执牛耳者，从R/3时代开始SAP所开发的基于C/S结构和关系型数据库的企业管理软件获得了极大的成功。即使SAP近些年更多的在开发基于浏览器的应用，但R/3时代开始的后端架构并没有发生根本的变化。但这种架构现在显然碰到了不少问题，企业的数据越来越多，企业希望更及时更智能的分析数据，这些需求在老的架构上都碰到挑战。

在这些背景下诞生的HANA具有不少特色：

1. HANA是个share nothing架构的分布式数据库，并且原生支持并行优化。这样的架构使得HANA能够充分利用多核、分布式集群处理大数据问题。这是HANA跟现有主流商业数据库架构上的不同之处，像Oracle、Microsoft SQL Server都不是这样的架构。长远来讲，这将是HANA击败竞争对手的核心能力之一。大数据是行业发展的必然方向，数据本地化和数据级并行是大数据处理技术上的必然选择，而share nothing的分布式架构恰恰就是数据本地化和数据级并行的设计。不过，目前这个阶段，这还不足以成为HANA的杀器，因为share everything架构的数据库也可以处理现在企业面临的数据量。
   
2. HANA是个内存数据库。HANA的数据基本上都放在内存里，数据操作都不需要访问磁盘。内存的访问速度跟磁盘完全不是一个数量级的，这使得HANA可以更快的处理数据。当然HANA也有优化，一些不热的数据也会扔到磁盘上去。现在HANA宣传的时候内存数据库这点着墨比较多，但在我看来这不是最大的特色和能力。
3. HANA同时具有行式数据库和列式数据库引擎。列式数据库本身并没有太多新颖之处，在业内也存在多年。但HANA却颠覆了列式数据库的用途，因为HANA想用列式数据库来处理OLTP的问题。在我看来，这是现阶段HANA的最大杀器，也是HANA在很多场合体现出的高性能的基础。
4. HANA内置了一些数据建模和数据分析的功能，甚至于把R深度集成了。
5. SAP推荐在HANA上同时处理OLTP和OLAP的问题，并且也把HANA这么设计。这一点是颠覆过去几十年企业级管理软件领域的思维的。
6. SAP推荐在HANA上直接处理商业逻辑。这一点是完全反R/3的架构的，因为R/3架构里数据库只处理数据。但是，在大数据时代，要想数据处理的快，商业逻辑就得跟数据在一起。所以这个想法长远来看是对的。

以上这些点看下来，从技术上来讲HANA并没有哪一点是完全独创的。但HANA的独特之处在于把这些东西揉合在一起，并定义一套新的企业级管理软件和数据库的架构模式。这使得HANA目前在行业内是相当独特的。Oracle最近发布的12c In-Memory Database多少也有向HANA看齐的意思，这其实是Oracle的被动选择。

好了，终于可以回到问题本身了。从上面的分析可以看出，HANA是一个新颖的东西，对SAP而言是个下一代的产品。我们可以从下面几点分析看看HANA的发展前景：

1. 通用的关系型数据库。这是个发展了三十多年的市场，比较稳定，现在是寡头竞争，基本是Oracle、DB2、Microsoft SQL Server的天下。我不觉得HANA短期内在这个领域有多么强的竞争力，首先HANA的软硬件价格不菲，而且HANA的生态圈还没有建设起来。长期的话就要看HANA的持续发展了。
   
2. 数据仓库和数据分析。HANA其实具有一部分数据仓库的功能和数据分析的功能，HANA的优势在于比较快，而且跟SAP ERP的集成又好，可以实实在在的帮企业解决一些问题，所以在这个市场我认为会发展的还不错。
3. SAP商务套件的基础数据库和基础平台。现在SAP商务套件已经完全支持HANA了，而SAP也力推这个组合并且在这个组合上推出一些特色的功能。这自然会带动HANA的销售。但短期内我不觉得会有大批的SAP客户会把ERP这样的关键业务系统迁移到HANA上来。
4. SAP下一代发展的基础平台。事实上HANA现在应该也是SAP发展的最高战略。SAP的云平台和下一代的企业级应用显然都将以HANA为基础展开。在这一点上单独谈HANA的销售或者前景也没有太大必要，HANA已经跟SAP的未来发展绑在一起。

综上所述，单独讲HANA的发展前景意义不大，HANA已经和SAP的命运绑定在一起。HANA并不只是SAP的一款数据库产品，而是SAP将来发展的战略平台。所以只要SAP还在而且SAP的战略没有大的变化，那么HANA肯定就会持续发展。而这种持续的发展到一个临界点的时候，可能会帮助HANA在通用的关系型数据库领域开疆拓土，进而成为一个新的寡头。

===========

SAP HANA内存数据库与oracle数据库的性能比较

1.传统磁盘数据库的基本访问模式。为了提高性能在产品和应用之间会加入缓存的内存区域。传统数据库性能瓶颈主要出现在一个是内存不够，一个IO读写效率太低。oracle 体系结构中，数据库实例的系统全局区SGA（System global area） 是核心的组成部分，它是一组共享的内存结构，里面存储了oracle数据库实例（instance）的数据和控制文件信息。SGA主要包括以下几部分：共享池，数据缓冲区，大型池，Java池，日志缓冲区。如果每次执行一个操作时，Oracle都必须从磁盘读取所有数据块并在改变它之后又必须把每一块写入磁盘，显然效率会非常低。数据缓冲区存放需要经常访问的数据，供所有用户使用。修改数据时，首先从数据文件中取出数据，存储在数据缓冲区中，修改/插入数据也存储在缓冲区中，commit或DBWR进程的其他条件引发时，数据被写入数据文件。而SGA的内存是极其有限的，所以SGA是影响Oracle数据库性能的重要因素.

而SAP HAN内存数据库，拥有大量的内存，在数据库启动过程中把数据从磁盘上加载到内存中，而对数据进行操作也是数据是先不存储到磁盘上(Disk)(数据操作会有相应的日志保存)，存储在内存中，MVCC:(Multi Version Concurrency Control)用来控制内存数据的一致性，而后台savepoint定时的把内存中数据的修改从内存中写入磁盘。内存数据库并不是实时的把数据更新到磁盘上，这样就减少很多磁盘的IO操作，而数据有加载到内存中，内存存储读取的性能远高于磁盘存储。读写操作都针对内存进行，不再直接与磁盘数据库交互，相当于是一种异步操作，显然，异步操作使得前端的写操作显得更快。虽然oracle的读写操作也有针对内存进行，但由于SGA的内存有限，遇到大数据量时，性能相比内存数据库就相差很远。