-
一、Ignite简介
Apache Ignite 内存数组组织框架是一个高性能、集成和分布式的内存计算和事务平台，用于大规模的数据集处理，比传统的基于磁盘或闪存的技术具有更高的性能，同时他还为应用和不同的数据源之间提供高性能、分布式内存中数据组织管理的功能。
二、Ignite历史
Ignite来源于尼基塔·伊万诺夫于2007年创建的GridGain系统公司开发的GridGain软件，尼基塔领导公司开发了领先的分布式内存片内数据处理技术-领先的Java内存片内计算平台，今天在全世界每10秒它就会启动运行一次。他有超过20年的软件应用开发经验，创建了HPC和中间件平台，并在一些创业公司和知名企业都做出过贡献，包括Adaptec, Visa和BEA Systems。尼基塔也是使用Java技术作为服务器端开发应用的先驱者，1996年他在为欧洲大型系统做集成工作时他就进行了相关实践。
2014年3月，GridGain公司将该软件90%以上的功能和代码开源，仅在商业版中保留了高端企业级功能，如安全性，数据中心复制，先进的管理和监控等。2015年1月，GridGain通过Apache 2.0许可进入Apache的孵化器进行孵化，很快就于8月25日毕业并且成为Apache的*项目，9月28日即发布了1.4.0版，应该说发展、迭代速度非常之快。该技术相关资料较少，但确是一个很有潜力的技术，解决了大规模、大数据量、高并发企业级或者互联网应用面临的若干痛点。
三、Ignite和Hadoop以及Spark的关系
Ignite和Hadoop解决的是不同的问题，即使在一定程度上可能应用了类似的底层基础技术。Ignite是一种多用途，和OLAP/ OLTP内存中数据结构相关的，而Hadoop仅仅是Ignite原生支持（和加速）的诸多数据来源之一。
Spark是一个和Ignite类似的项目。但是Spark聚焦于OLAP，而Ignite凭借强大的事务处理能力在混合型的OLTP/ OLAP场景中表现更好。特别是针对Hadoop，Ignite将为现有的Map/Reduce，Pig或Hive作业提供即插即用式的加速，避免了推倒重来的做法，而Spark需要先做数据ETL，更适合新写的分析应用。
四、和类似技术的比较
在Ignite以前，大规模、大数据量、高并发企业级或者互联网应用为了解决数据缓存、降低数据库负载、提高查询性能等突出问题，很多采用了Hazelcast或者Oracle Coherence或者GemFire（比如12306网站）或者目前应用越来越广泛的Redis等缓存技术，本文对这些相关的技术做了简单的比较，基本内容来源于其官方网站，进行了翻译整理，方便更多的人了解他。
1.Ignite和Hazelcast
Apache Ignite和Hazelcast都提供了富数据网格的特性，解决了可扩展的分布式集群环境下在内存中对数据进行缓存和分区的问题。
Ignite和Hazelcast在缓存的方式上是有很多不同的，同时支持事务和数据的查询，下面的表格列出了一些主要的不同点，这些都是我们在选择内存数据网格产品时需要特别关注的。
序号
对比项目
Apache Ignite
Hazelcast
1 聚焦于开源 Ignite是一个Apache的开源项目，还在不断的增加新特性，对C++、.NET/C#和Node.js的支持也会很快到来。 Hazelcast正在持续的减少开源版本的功能，更多的功能加入了企业版中，比如堆外内存，持续查询，Web-Session集群，SSL加密支持等。 2 JCache(JSR107) Ignite完全兼容JCache (JSR 107)缓存规范 Hazelcast完全兼容JCache (JSR 107)缓存规范 3 堆外存储 Ignite根据用户配置支持将数据存储在堆内或者堆外 Hazelcast仅在商业版中提供堆外存储的功能
4 堆外索引 只要配置了堆外存储，Ignite就会在堆外存储索引(为了不影响使用堆内内存的用户应用。) 不支持 5 持续查询 Ignite支持持续查询，比如允许客户端和服务器端订阅数据变化的持续通知 Hazelcast仅在商业版中提供持续查询的功能。 6 SQL查询 Ignite支持完整的SQL(ANSI-99)语法以查询内存中的数据 Hazelcast仅对SQL提供有限的支持(只有几个关键字) 7 关联查询 Ignite支持完整的SQL关联，包括跨多个缓存的关联，比如：select * from A a, B b where a.b_id = b.id Hazelcast不支持任何的关联查询，不管用不用SQL，如果需要，开发者需要手工处理多个查询的结果。 8 查询一致性 Ignite提供完整的查询一致性，即查询是在一个特定的快照中执行的，查询开始之后的数据更新不影响查询的结果。 Hazelcast查询是不一致的，这是可能的，查询结果的一部分将看到一定的更新，而另一部分则不会。 9 查询容错 Ignite查询是容错的，即查询结果始终是一致的不会受到集群拓扑发生变化的影响，比如节点的加入，退出或崩溃。
Hazelcast查询是不容错的，即查询结果在集群拓扑发生变化时不一致，而数据正在后台重新平衡。 10 数据一致性 Ignite支持内存中数据的原子性和事务一致性，不管数据存储在分区或者复制缓存中。 Hazelcast仅在分区缓存中支持原子性和事务一致性，而存储在复制缓存中的数据没有任何事务一致性的保证。 11 SSL加密 Ignite为所有的网络传输提供SSL加密，包括客户端和服务器端以及服务器之间。 Hazelcast仅在商业版中提供SSL加密功能。 12 Web-Session集群 Ignite为所有已知的应用服务器提供Web-Session的缓存和集群化支持。 Hazelcast仅在商业版中提供Web-Session集群化支持。 13 计算网格 Ignite提供集群上的M/R，Fork/Join和基本的分布式lambda处理，包括任务负载平衡，容错，检查点，计划任务等。 Hazelcast仅支持M/R和集群内的分布式随机任务。
14 流式网格 Ignite支持内存流，包括对数据流浮动窗口的查询和维护支持 不支持 15 服务网格 Ignite可以使用户方便地将其服务集群化，包括支持各种单例集群。 Hazelcast管理的服务不提供单例集群的功能。 16 .Net/C#,C++支持 Ignite将在1.5.0版中提供完整的内存组织API Hazelcast仅在商业版中提供有限的客户端API支持。 17 Node.js支持 Ignite将在1.5.0版中提供Node.js的客户端API。 不支持 2.Ignite和Coherence
Apache Ignite和Oracle Coherence都提供了富数据网格的特性，解决了可扩展的分布式集群环境下在内存中对数据进行缓存和分区的问题。
Ignite和Coherence在缓存的方式上是有很多不同的，同时支持事务和数据的查询，下面的表格列出了一些主要的不同点，这些都是我们在选择数据网格产品时需要特别关注的。
序号
对比项目
Apache Ignite
Oracle Coherence
1 开源和闭源 Ignite是一个Apache的开源项目，并且还在不断的增加新特性，对C++、.NET/C#和Node.js的支持也会很快到来。 Coherence是一个Oracle的专有软件，并不提供开源和免费的版本。 2 JCache (JSR 107) Ignite完全兼容JCache (JSR 107)缓存规范 Coherence完全兼容JCache (JSR 107)缓存规范 3 堆外存储 Ignite根据用户配置支持将数据存储在堆内或者堆外 Coherence对开发者提供了有限的选项支持将数据存储在堆外 4 堆外索引 只要配置了堆外存储，Ignite就会在堆外存储索引(为了不影响使用堆内内存的用户应用。) 不支持 5 SQL查询 Ignite支持完整的SQL(ANSI-99)语法以查询查询内存中的数据 不支持 6 关联查询 Ignite支持完整的SQL关联，包括跨多个缓存的关联，比如：select * from A a, B b where a.b_id = b.id Coherence不支持任何的关联查询，不管用不用SQL，如果需要，开发者需要手工处理多个查询的结果。 7 ACID事务 Ignite提供了每台服务器每秒成千上万事务的优异性能。 Coherence因为性能原因不建议使用事务。 8 分层存储 Ignite支持分层存储模型，数据可以在堆内、堆外以及交换空间内存储和移动，上层将提供更多的存储能力，当然延迟也会增加。 不支持 9 数据流 Ignite提供内存流的支持，包括支持流数据的维护、查询和浮动窗口 不支持 10 配置 Ignite支持通过Java Bean以及原生的Spring XML集成对系统进行配置，同时也支持通过代码对系统进行方便配置的能力。 Coherence通过专有的XML格式文件进行配置，不支持通过代码进行配置。 3.Ignite和Gemfire
Apache Ignite和Pivotal Gemfire都提供了富数据网格的特性，解决了可扩展的分布式集群环境下在内存中对数据进行缓存和分区的问题。
Ignite和Gemfire在缓存的方式上是有很多不同的，同时支持事务和数据的查询，下面的表格列出了一些主要的不同点，这些都是我们在选择数据网格产品时需要特别关注的。
序号
对比项目
Apache Ignite
Pivotal Gemfire
1 开源和闭源 Ignite是一个Apache的开源项目，并且还在不断的增加新特性，对C++和.NET/C#和Node.js的支持也会很快到来。 Gemfire是Pivotal的专有软件。
2 JCache (JSR107) Ignite数据网格是JCache（JSR107）规范的一个实现，该API为数据访问提供了简单易用、但是功能强大的API。 Gemfire没有实现JCache，使用专有的API。 3 堆外存储 Ignite根据用户配置支持将数据存储在堆内和堆外 Gemfire不支持将数据存储在堆外 4 SQL查询 Ignite支持完整的SQL(ANSI-99) 查询语法以查询内存中的数据。 Gemfire不支持标准的SQL语法，但是他提供了他自己的叫做OQL的对象查询语言。
5 关联查询 Ignite支持完整的SQL关联，包括跨多个缓存的关联，比如：select * from A a, B b where a.b_id = b.id Gemfire不支持任何的跨区或者跨缓存的关联查询，如果需要，开发者需要手工处理多个查询的结果。 6 跨分区事务 Ignite支持跨分区事务，事务可以在整个集群中缓存的所有分区中执行。 Gemfire不支持跨越多个缓存分区或者节点的事务。 7 分层存储 Ignite支持分层存储模型，数据可以在堆内、堆外以及交换空间内存储和移动，上层将提供更多的存储能力，当然延迟也会增加。 不支持 8 数据流 Ignite提供内存流的支持，包括支持流数据的维护、查询和浮动窗口 不支持 9 配置 Ignite支持通过Java Bean以及原生的Spring XML集成对系统进行配置，同时也支持通过代码对系统进行方便配置的能力。 Gemfire通过专有的XML格式文件进行配置，不支持通过代码进行配置。 10 部署 Ignite节点是对等的，并且在启动时自动加入集群（不需要任何locator服务器）。 Gemfire需要启动和维护一个locator服务器，以便控制节点的加入和退出。 4.Ignite和Redis
Apache Ignite和Redis都提供了分布式缓存的功能，但是每个产品提供的功能特性是非常不同的。Redis主要是一个数据结构存储，但是Ignite提供了很多内存内的分布式组件，包括数据网格、计算网格、流，当然也包括数据结构。
Ignite是一个内存数据组织，并且提供了更多的功能，无法进行一个一个对应功能特性的比较，但是我们仍然能对一些数据网格功能进行比较。
序号
对比项目
Apache Ignite
Redis
1 JCache (JSR 107) Ignite完全兼容JCache（JSR107）缓存规范 不支持 2 ACID事务 Ignite完全支持ACID事务，包括乐观和悲观并发模型以及READ_COMMITTED, REPEATABLE_READ和SERIALIZABLE隔离级别。 Redis提供了客户端乐观事务的有限支持，在并发更新情况下，客户端需要手工重试事务。 3 数据分区 Ignite支持分区缓存，类似于一个分布式哈希，集群中的每个节点都存储数据的一部分，在拓扑发生变化的情况下，Ignite会自动进行数据的平衡。 Redis不支持分区，但是他提供了副本的分片， 4 全复制 Ignite支持缓存的复制，集群中的每个节点的每个键值对都支持。 Redis不提供对全复制的直接支持。 5 原生对象 Ignite允许用户使用自己的领域对象模型并且提供对任何Java/Scala, C++和.NET/C#数据类型(对象)的原生支持，用户可以在Ignite缓存中轻易的存储任何程序和领域对象。 Redis不允许用户使用自定义数据类型，仅支持预定义的基本数据结构集合，比如Set、List、Array以及一些其他的。 6 (近)客户端缓存 Ignite提供客户端缓存最近访问数据的直接支持。 Redis不支持客户端缓存。 7 服务器端并行处理 Ignite支持在服务器端，靠近数据并行地直接执行任何Java, C++和.NET/C#代码。 Redis通常没有任何并行数据处理的能力，服务器端基本只支持LUA脚本语言，服务器端不直接支持Java, .NET,或者C++代码执行。 8 SQL查询 Ignite支持完整SQL（ANSI-99）语法以查询内存中的数据。 Redis不支持任何查询语言，只支持客户端缓存API。 9 持续查询 Ignite提供对客户端和服务器端持续查询的支持，用户可以设置服务器端的过滤器来减少和降低传输到客户端的数据量。 Redis提供客户端基于键值的事件通知的支持，然而，他不提供服务器端的过滤器，因此造成了在客户端和服务器端中更新通知网络流量的显著增加。 10 数据库集成 Ignite可以自动集成外部的数据库-RDBMS, NoSQL,和HDFS 不支持 按照官方的说法，Ignite是很强大的整体解决方案和开发平台，功能很多而且复杂，没有提到缺点或者说坑，这个只能使用过程中逐步发现和解决，虽然Ignite本身历史尚短，但是既然来源于历史不算短的商业软件，还是经过实际生产环境验证的，基本功能的可用性肯定是有的。