千家信息网

Apache Ignite1.7有哪些新特性

发表于:2026-11-01 作者:千家信息网编辑
千家信息网最后更新 2026年11月01日,这篇文章主要讲解了"Apache Ignite1.7有哪些新特性",文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习"Apache Ignite1.7有哪些新
千家信息网最后更新 2026年11月01日Apache Ignite1.7有哪些新特性

这篇文章主要讲解了"Apache Ignite1.7有哪些新特性",文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习"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

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

  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有哪些新特性这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是,小编将为大家推送更多相关知识点的文章,欢迎关注!

查询 数据 节点 缓存 关联 结果 特性 实体 业务 分布式 引擎 流程 存储 多个 对象 学习 支持 不同 一致 两个 数据库的安全要保护哪些东西 数据库安全各自的含义是什么 生产安全数据库录入 数据库的安全性及管理 数据库安全策略包含哪些 海淀数据库安全审计系统 建立农村房屋安全信息数据库 易用的数据库客户端支持安全管理 连接数据库失败ssl安全错误 数据库的锁怎样保障安全 鸠鸠互联网科技 与互联网科技公司 小马过河互联网科技 广州善班互联网科技 互联网 新科技 互联网金融和金融科技 中国科技互联网公司收入 中化能源互联网科技招聘 互联网大会黑科技排名 栖莱科技互联网股份有限公司 宜昌元轩互联网科技有限公司 允成互联网科技有限公司融资 互联网在线教育科技创业 世界互联网领先科技成果获奖 下一代互联网重大应用科技园 广州互联网高科技取餐柜 济南小医互联网科技有限公司招聘 互联网科技手机排行榜 北京军民互联网科技公司 杭州科技互联网公司有哪些 中关村互联网科技集团 衡水科技产业互联网平台 以后互联网后是啥科技 中化能源互联网科技招聘 浙江互联网科技研学营 和信科技工业互联网 徐州市互联网科技有限公司 陕西云淼互联网科技公司 长沙易易互联网科技有限公司 六子台科技互联网展会
0