共计 2384 个字符，预计需要花费 6 分钟才能阅读完成。
这篇文章主要讲解了“Apache Ignite1.7 有哪些新特性”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着丸趣 TV 小编的思路慢慢深入，一起来研究和学习“Apache Ignite1.7 有哪些新特性”吧！
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这个查询的执行流程是这样的：
查询发起节点（mapper 和 reducer）会将查询发给所有缓存数据的节点；
从 reducer 收到查询的所有节点会在本地执行查询，只会使用本地数据执行关联；
这些节点会将结果集的一部分反馈给 reducer；
reducer 最后会汇总从所有远程节点收到的结果集，然后向发起节点发送一个最终的聚合的结果。
非并置的分布式关联
如果同样的查询执行在一个非关系并置的数据上，那么会得到一个不完整以及不一致的结果，原因是 Apache Ignite 在 1.7.0 之前的版本只会在本地数据上执行查询（就像上述流程的第二步描述的那样）。然而，在 Ignite 1.7.0 之后的版本不再是这样的了，他会支持非并置的分布式关联，这些关联不再要求并置数据。现在，会使用 Person 的真实 Id 作为缓存键，替代 AffinityKey(id, orgId)，然后将 orgId 字段加入 Person 对象的内部来执行这两个缓存的关联，即使这些发生了改变，仍然会得到一个完整的结果，不用管实际上 Person 的数据是否与他们的 Organization 数据并置在一起，这是因为最新版的 Ignite 会以如下的流程执行同样的 SQL 查询（上面提到的）：
查询发起节点（mapper 和 reducer）会将查询发给所有缓存数据的节点；
从 reducer 收到查询的所有节点会在本地执行查询，但是使用本地数据和远程节点的数据进行关联（因为数据是全集群分布的）；
这些节点会将结果集的一部分反馈给 reducer；
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 有哪些新特性这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是丸趣 TV，丸趣 TV 小编将为大家推送更多相关知识点的文章，欢迎关注！
