宜宾网站建设公司

ApacheIgnite1.7有哪些新特性

这篇文章主要讲解了“Apache Ignite1.7有哪些新特性”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“Apache Ignite1.7有哪些新特性”吧！

成都创新互联公司-专业网站定制、快速模板网站建设、高性价比信州网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式信州网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖信州地区。费用合理售后完善，十年实体公司更值得信赖。

Apache Ignite 1.7的新特性-非并置的分布式关联

最近，Apache Ignite发布了1.7.0版，在众多的改变中，有一个众多Apache Ignite用户和客户期待已久的杀手级特性-SQL查询支持非并置的分布式关联。本文会聚焦于这个特性，详细描述非并置的分布式关联是如何工作的以及它与传统的（基于关系并置）Apache Ignite关联有何不同。

基于关系并置的关联

以前，Apache Ignite支持跨多个不同表的SQL关联查询，但是要求一个查询中关联的缓存数据要并置在一起。实际上在Ignite中，并置通过关系键可以非常方便地启用，这时，一个业务实体的数据会与另一个相关业务实体的数据存储于同一个节点。 比如，假设有两个业务实体，Organization和Person，并且一个Organization的Id会作为来自该Organization的Person的一个关系键。然后，Ignite会确保将Person的所有数据存储于他们所属的Organization数据所在的节点上，这个简单的概念可以执行一系列可以想象的兼容于ANSI-99的SQL查询，包括多个缓存的关联。 基本上，一个使用关联的SQL查询与一个没有关联的SQL查询的执行流程是绝对一致的。 我们可以看一下一个很基本的查询的执行流程，它使用Organization和Person业务实体通过如下方式定义：

  • Organization(id, address)实体：这个id会作为Organization的ID，它的值在将Organization注入缓存时会作为缓存键，这个用作缓存键的键在Ignite的SQL引擎层会被视为一个主键，这个概念会贯穿本文始终。

  • Person(name, salary)实体：位于Persons缓存，会使用AffinityKey(id, orgId)作为缓存键，这里AffinityKey是Ignite中的一个特别的对象，他会定义一个Person的唯一Id（第一个参数）以及他的关系键（第二个参数），这里，Organization ID（orgId）被选为一个Person的关系键，这意味着Persons数据会与他们所属的Organizations的数据位于同一个节点上。

在定义这些业务实体以及预加载缓存数据之后，可以随意执行一个像下面这样的SQL查询，因为Person与他们的Organization是关系并置的，Ignite会确保返回一个完整的结果集。

SELECT * FROM Organization as org JOIN Person as p ON org.id = p.orgId

这个查询的执行流程是这样的：

  1. 查询发起节点（mapper和reducer）会将查询发给所有缓存数据的节点；

  2. 从reducer收到查询的所有节点会在本地执行查询，只会使用本地数据执行关联；

  3. 这些节点会将结果集的一部分反馈给reducer；

  4. reducer最后会汇总从所有远程节点收到的结果集，然后向发起节点发送一个最终的聚合的结果。

非并置的分布式关联

如果同样的查询执行在一个非关系并置的数据上，那么会得到一个不完整以及不一致的结果，原因是Apache Ignite在1.7.0之前的版本只会在本地数据上执行查询（就像上述流程的第二步描述的那样）。 然而，在Ignite 1.7.0之后的版本不再是这样的了，他会支持非并置的分布式关联，这些关联不再要求并置数据。 现在，会使用Person的真实Id作为缓存键，替代AffinityKey(id, orgId)，然后将orgId字段加入Person对象的内部来执行这两个缓存的关联，即使这些发生了改变，仍然会得到一个完整的结果，不用管实际上Person的数据是否与他们的Organization数据并置在一起，这是因为最新版的Ignite会以如下的流程执行同样的SQL查询（上面提到的）：

  1. 查询发起节点（mapper和reducer）会将查询发给所有缓存数据的节点；

  2. 从reducer收到查询的所有节点会在本地执行查询，但是使用本地数据和远程节点的数据进行关联（因为数据是全集群分布的）；

  3. 这些节点会将结果集的一部分反馈给reducer；

  4. reducer最后会汇总从所有远程节点收到的结果集，然后向发起节点发送一个最终的聚合的结果。

这里需要注意的一个重要的事是，由于查询的特殊性，一个节点会向集群发送广播来请求在第二步中丢失的数据，然而，现在也有一种方式来优化，就是SQL引擎会为特定的关联类型、典型的查询将广播切换为单播，下面的修改就会切换为单播模式：

SELECT * FROM Organization as org JOIN Person as p ON org._key = p.orgId

在这个查询中，如果SQL引擎决定在Persons缓存加上Organizations上执行查询，然后引擎会使用org._key(s)向存储Organizations缓存的节点发送单播请求，这里_key是Ignite SQL查询中使用的一个特别的关键字，他会指向一个对象的缓存键/主键。基本上，因为引擎知道了它的缓存键/主键，会轻松地找到存储条目的节点，用于多个缓存的关系键也是同样的道理。

感谢各位的阅读，以上就是“Apache Ignite1.7有哪些新特性”的内容了，经过本文的学习后，相信大家对Apache Ignite1.7有哪些新特性这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是创新互联，小编将为大家推送更多相关知识点的文章，欢迎关注！


本文名称：ApacheIgnite1.7有哪些新特性
分享链接：http://ybzwz.com/article/gcdcdi.html

其他资讯