架构解密从分布式到微服务：深入浅析内存，内存计算产品分析

内存计算产品分析

本节对几个经典的内存计算产品进行研究和分析，以了解和掌握分布式内存计算领域的设计思想、设计原则、核心技术等相关知识和技能。

 SAP HANA

SAP HANA（简称HANA）的第1个特点是把数据全部放入内存中存储，由于内存存储的数据有易失性，系统掉电或者重启时内存中的数据会丢失，所以针对这个问题，HANA有一个后台的异步进程savepoint (Data persistence)，定时把内存数据写回磁盘。

HANA的第2个特点是充分并行编程，利用NUMA架构与并行编程技术，把大数据量和计算量分散到不同的处理器中并行计算。

HANA 的第3个特点是最小化数据传输，这对于大数据实时计算有至关重要的影响，具体的做法如下。

首先，采用合适的数据压缩技术，尽可能地压缩数据的存储空间，这样一来，当数据从内存中加载到CPU Cache中时，一个Cache Line会加载更多的数据，如果也需要I/O传输，则传输量会小很多。HANA采用了数据字典的方式来压缩数据，用整数来表示相应的文本字符串，其原理如下图所示，将Customer 与 Material两个字段抽出来，在数据库记录里就可以用两个数值型字段来表示它们,仅此一种方式就节省了很多存储空间。有限的内存可以加载更多的数据，因此数据压缩技术基本上是大数据系统的标配技术之一。

 

其次，下推计算逻辑到数据存储层（数据库端)，即把应用逻辑和计算由应用层转移到数据库层，这非常类似于我们很少使用的存储过程所做的事情。我们在处理数据时，通常的逻辑是先把数据从数据库中读出来，再进行相应的计算处理，最后把处理后的数据写回数据库。由于在数据库和应用程序之间要通过网络传输大量的数据包，所以网络资源的开销、延时、传输速率及网络带宽都导致了数据计算性能的下降。移动计算，而不是移动数据，这也是分布式计算中重要的指导思想之一。

如下所示为HANA的架构图。

 

我们看到有几个与众不同的亮点，如下所述。

首先，HANA将传统的在线交易数据库（OLTP）与数据仓库分析系统（OLAP)整合到一起，其中的MDX及 Calculation Engine模块用于实现数据仓库的分析功能，这是一种创新设计理念。

其次，下层的关系型数据库引擎层(Relational Engines）同时提供了传统的基于行的数据存储模块(RowStore）与新型的基于列的数据存储模块(Column Store)，这是因为两种存储模式有各自的优缺点:基于行的数据存储模块主要用于传统的关系型数据库;基于列的数据存储模块在数据分析方面有一些独特的性能优势,同时支持这两种存储方式,而且是在内存中存储的，可以让HANA的适应能力更强，适合更多的应用场景。

最后，HANA采用了分布式集群的设计思路,可以水平扩展到很大的一个规模,这给Oracle这种传统数据库带来了很大的压力。

硬件方面，SAP HANA并没有走Oracle一体机的全封闭路线，而是和多个硬件厂商合作生产支持HANA 的高性能一体机。其中，IBM推出了基于 Power芯片架构的HANA;惠普推出了单节点达12TB内存的HANA系统;VMware也宣布和 SAP结盟，HANA可以在VMware的 vSphere 5.5平台上虚拟化。除此之外，SAP分别认证了IBM、惠普、戴尔、思科、富士通、日立、NEC和华为等8家公司的多款HANA服务器，全球已经有数千家企业在使用HANA系统。

Hazelcast

前面说过，Hazelcast是 IMDG/IMCG领域的佼佼者，它与同类软件相比有如下优势。

• 使用和集成简单，只有一个Jar文件。
• 功能众多，但都集中于自己专注的领域。
• 开发人员友好,提供了很多方便使用的分布式数据,支持 MapReduce操作及简单的SQL查询API，同时提供了常见框架的集成，例如Tomcat、Spring、Hibernate等。

简单来说，我们在需要一个分布式的超大Map(或Set、Queue等)时可以用Hazelcast。另外，在 Tomcat组成集群时，Hazelcast可以用来实现分布式的Session管理。此外，Hazelcast 的分布式计算框架极其强大，它也提供了分布式并发的常用编程工具:锁、信号量、队列等。如下所示是其功能架构图。

 

Hazelcast集群采用的是去中心化的设计思想，首先启动的节点是Master节点，其他加入的节点是Worker节点，Hazelcast在设计方面的优点如下所述。

• Partition:即内存数据分区存储，Hazelcast 默认有271个partition，这271个partition平均分布在集群里的节点中，因此集群里的数据被分散在每个节点中，get/set操作时先计算得到key所在的partition，再与相关的节点通信，完成数据的操作过程。
• Near cache:即一个本地的二级缓存，在get时先到本地的nearcache里查找，如果没有找到，则到对应的节点中取数据，再放到nearcache 里。
• Distributed Backups:即分布式备份节点主数据，在可扩展的动态分区存储系统中，无论是NoSQL数据库、文件系统还是内存数据网格，在集群更改或者重新平衡时可能导致网络中的大数据传输，例如一个节点挂了，该节点的数据必须被重新分配给其他在线的节点，在此期间大量的网络传输和CPU消耗都可能导致严重的操作延时。Hazelcast则采取了另外一种思路，一个节点的主数据被均匀地备份到其他节点（ DistributedBackups)，每个节点都负责备份其他节点的主数据，这样的备份机制在节点挂了之后是不需要立刻重新均衡的，假设添加了额外的1个节点，在集群中也不会立即进行均衡，因为存在的节点已经在最佳状态，在随后的操作过程中，Hazelcast 会自动、平滑地迁移一些数据到这些新的节点，最终数据均匀存储。
• Elastic Memory:即弹性存储，简单地说，就是JVM在超大内存堆的情况下，可能由于GC的原因，导致JVM 暂停工作几秒甚至十几秒，从而影响程序的响应时间。弹性内存是Hazelcast使用堆外存储（off-heap）进行存储以避免GC时造成的暂停服务，在堆外存储的情况下,每个节点的主数据与备份数据及可用的Near cache对象都被存储在堆外，即使频繁更新TB级别的内存数据，在GC时也几乎不会造成影响，从而使应用有可预见的延时和吞吐量。但遗憾的是弹性存储的特性仅限于企业版，这是由于在堆外存储时进行编程的难度很大，有一定的技术壁垒。

Hazelcast堆外存储的工作原理为:假设指定每个JVM都使用40GB的堆外存储,则Hazelcast会创建40个 DirectBuffer，每个 DirectBuffer 都有1GB的容量，每个DirectBuffer的内部都被分成默认大小为1KB的Chunck，例如3KB将被存储为3个Chunck，在存储的对象被移除后，这些Chunck被归还以便下次使用，但实际上实现的过程很复杂，在堆外存储里还包括必要的索引数据。Hazelcast的堆外存储技术采用了JDK 的Unsafe API，我们可以将Hazelcast视作Java界分布式内存编程方面的一个典范。

Hazelcast与 Redis 分属不同的开发语言，本来井水不犯河水，但是两个产品在使用场景上有一定的重合性，因此也有一定的竞争。

VoltDB

VoltDB是一种开源的高性能的内存关系型数据库,提供社区版本和商业版本,它是由Ingres和 Postgres联合创始人Mike Stonebraker 带领开发的一种 NewSQL产品。VoltDB采用Shard-nothing架构，由此既获得了NoSQL的良好可扩展性及高吞吐量数据处理能力，又没有放弃传统关系型数据库的事务支持特性（ACID)。

VoltDB采用分区表结合副本表(Replicated Table，类似于Mycat 的全局表概念）的方式来处理数据库的水平扩展问题，其中每张表都指定一个字段作为分区字段，对分区字段做哈希算法以确定某条记录被存储在哪个节点上;副本表则是在每个节点上都存储相同的全部表记录，副本表通常用于解决多表JOIN问题或者提升单表查询的性能。下图给出了VoltDB的3节点集群及分区表示例，其中A、B及C三个分区表的数据被分散在3个VoltDB节点上。

 

VoltDB的思想是“所有事务都由以Java实现的预编译存储过程完成，且所有存储过程在任意站点上都是序列化执行的”，这样使VoltDB达到了最高的隔离级别，且消除了锁的使用，很好地加快了处理速度。在官方的测试结果中，VoltDB可被轻松地扩展到39台服务器(300核)、120个分区，每秒处理160万复杂事务，VoltDB 的这个设计再次验证了靠近数据进行计算的重要性。

下面是VoltDB与 MySQL的测试对比结果。

 

从测试结果来看，差距还是很明显的，这也表明了先进的内存计算技术对于大数据处理的重要性。那么，关键问题来了，VoltDB是怎样实现内存数据库的呢?它并没有像 Hazelcast 那样自己设计实现复杂的内存模块，而是采用取巧的做法，整个数据库引擎“复刻”了HSQL这个在Java 界有名的数据库，HSQL与H2 Database一样，很多时候被用作内存数据库或者内嵌的数据库。

实际上，我们可以认为VoltDB是一个基于HSQL 的分片内存数据库集群。HSQL在内存中存储数据时，并没有用到Java堆外内存，在数据量特别大时可能会引发GC 的延时。但 H2Database项目组研发了一个Java堆外存储模块OffHeapStore，可以将其用于下一代的数据库存储模块MVStore中，如果VoltDB采用H2 Database并且启用堆外存储模式，则在面对更大的内存数据时，整体性能可能会表现得更加平稳。

为了充分发挥多核机器的性能，而又不引入多线程执行事务的复杂性，VoltDB 的数据分片规模是按照集群核数来划分的。在一台物理机器上可能运行着多个VoltDB服务器进程，每个进程都对应一个核，服务器进程之间都通过网络进行通信。在单个进程内只使用单线程，所有事务都按顺序执行，这种做法如果能处理好进程间通信的性能问题，则的确是很高效的一种并发编程模式。

VoltDB适合OLTP系统，即单个事务较小但是事务总量非常多的应用，比如金融、零售、互联网应用，不适合进行范围查询或者频繁多表JOIN 这样的报表场景。不管怎样，我们不得不承认， VoltDB的确是传统关系型数据库在面对众多NoSQL产品进攻局面时的一个坚决反击。VoltDB 的作者精通关系型数据库，也明白NoSQL 的优势，所以他巧妙地结合了两者的长处，并引入内存计算这个新的突破口，开启了NewSQL的一片新天地。

本文给大家讲解的内容是架构解密从分布式到微服务：深入浅析内存，内存计算产品分析

1. 下篇文章给大家讲解的是架构解密从分布式到微服务：深入解析分布式文件存储；
2. 觉得文章不错的朋友可以转发此文关注小编；
3. 感谢大家的支持！