外贸商城网站 定制,网页设计师培训费用,电商网名大全,cms客户管理系统程序源码背景 “为什么你们的图形产品不支持 SQL 或类似 SQL 的查询语言#xff1f;” 过去#xff0c;我们的一些客户经常问这个问题#xff0c;但随着时间的推移#xff0c;这个问题变得越来越少。
尽管一度被忽视#xff0c;但图数据库拥有无缝设计并适应其底层数据结构的查询…背景 “为什么你们的图形产品不支持 SQL 或类似 SQL 的查询语言” 过去我们的一些客户经常问这个问题但随着时间的推移这个问题变得越来越少。
尽管一度被忽视但图数据库拥有无缝设计并适应其底层数据结构的查询语言的必要性已被创新产品所明确证明并受到市场的欢迎。图数据库在数据模型、数据存储、性能等方面与关系数据库存在显著差异适合不同的应用场景和业务目标。这些区别表明SQL不适合用作本机图计算引擎的查询语言。
为了进行更全面的比较我们将演示针对存储在 SQL Server 中的表格数据集的 SQL 查询以及在 UQL 中编写的等效查询以针对加载到 Ultipa 中的相同内容的图形数据集运行。这两个数据集在另一篇文章《分步指南如何将表格转换为图形》中进行了分析。
数据集
如果您还没有机会查看它我们将使用的表格数据集包含来自医院信息管理系统内的六个表的数据医生、患者、科室、病床、诊断和住院患者。该数据集相对较小由大约 60 行记录组成。每个表的数据字段概述如下重点关注它们的互连从外键指向主键的箭头
表结构的简洁可视化强调从外键到主键的 连接。
SQL Server 连接中的分层数据管理结构表示为“数据库表字段”在 Ultipa 图形系统中可以将其转换为“图形架构属性”。换句话说Ultipa图系统中的模式对应于关系数据库中的表模式属性类似于表字段。
图数据集是从上述表格数据集通过将表结构转换为节点模式具有 _id 等属性和边模式具有 _from、_to 等属性而派生出来的。此过程涉及相当于对原始表进行修改的任务如下所述 通过对原始表结构的修改来说明图模型的全面描述
生成的图形数据集包含五个节点模式DOCTOR、PATIENT、DEPARTMENT、BED 和 ROOM以及三个边缘模式DIAGNOSIS、INPATIENT 和 BELONGTO。节点 ID 是从表的主键中提取的而边的 FROM 和 TO 是从表的外键中导出的并在必要时进行补充。
表查询与架构查询
鉴于 SQL Server 中表的概念与 Ultipa 中架构的概念相对应我们首先比较一下 DOCTOR 表和 DOCTOR 节点架构的查询过程。 查询目标检索每位医生的所有信息。
SQL
SELECT * FROM guest.DOCTOResult of single-table query using SQL
UQL
n({DOCTOR} as N) RETURN N{*} 使用 UQL 的单模式查询结果
尽管两个查询同样清晰并产生相同的结果但 SQL 类似于请求“从 DOCTOR 表中选择所有数据字段”的英语句子而 UQL 故意偏离这种基于自然语言的语法利用符号来传达其执行逻辑即“n()”表示图中的节点。
这种方法符合图的本质其中节点和边是基本组件这与表作为核心数据模型存在的关系数据库不同。在下一轮中我们将遇到 UQL 中表示边缘的“e()”。
连接查询与路径查询
图数据通过忠实地复制现实世界的复杂性而赢得赞誉。例如可以轻松地查询图形数据之间的链式关系称为路径查询 特别是与关系表的JOIN 查询相比。 查询目标检索Michael Roberts医生治疗过的所有患者的详细信息包括诊断结果和医生姓名。
SQL
SELECT PATIENT.PNO, PATIENT.PNAME, PATIENT.PSEX, DIAGNOSIS.DIAGNOSISRESULT, DIAGNOSIS.DNAMEFROM guest.DIAGNOSIS JOIN guest.PATIENT ON guest.DIAGNOSIS.PNO guest.PATIENT.PNOWHERE DNAME James Anderson 使用SQL进行表JOIN查询的结果
UQL
n({DOCTOR.DNAME James Anderson} AS D) .e({DIAGNOSIS} AS A) .n({PATIENT } AS P)RETURN table( P._id, P.PNAME, P.PSEX, A.DIAGNOSISRESULT, D.DNAME) 使用UQL的路径查询结果
虽然在前面用于查询单个表或模式的代码中可能没有突出强调这一点但在这些更广泛的代码摘录中出现了一个有趣的观察结果这两种查询语言的语法表达式是相反的。SQL 首先定义要检索的数据然后概述数据必须满足的过滤条件。另一方面UQL 首先描述数据应满足的标准然后指定要检索的数据。这种语法顺序的颠倒会影响开发人员的思维过程从而带来不同的编程体验。 语法顺序比较SQL左与 UQL右
让我们将焦点转移回数据关系的表示。SQL 使用 JOIN 来链接表并应用 ON 来锚定关键字段主键、外键。相比之下UQL 采用路径模板 n().e().n() 来系统地定义互连的节点和边基本上消除了额外锚定步骤的需要。 关系表达式的比较SQL左与 UQL右
为什么图查询语言这里是UQL能够实现如此精简的表达这是因为表之间固有的锚定关系即从外键到主键的链接无缝嵌入到边缘数据_from 和 _to中。这种基本的集成正是图数据库在有效管理关联关系方面优于关系数据库的原因。
此外UQL 直接将过滤条件合并到每个节点和边声明 n() 和 e() 中这与 SQL 的 WHERE 子句不同后者在连接所有表并锚定后添加过滤条件。这种方法使 UQL 语法更加简洁、有凝聚力并增强了代码的可读性。 UQL巧妙地将每个节点和边缘及其过滤条件整合成一个自然的链状路径模型。 值得强调的是虽然上面的 SQL 和 UQL 片段长度相似并且产生相同的结果但它们的实际查询功能从底层来看是不同的。在上面的示例中SQL 仅完成 PATIENT 和 DIAGNOSIS 两个表之间的连接从 DIAGNOSIS 表中检索医生的姓名 (DNAME)。相比之下UQL 在 PATIENT、DIAGNOSIS 和 DOCTOR 之间建立关系本质上是跨三个表模式执行 JOIN。它返回 D.DNAME这是节点模式 DOCTOR 的属性。了解这些潜在的区别给性能比较增添了讽刺SQL 查询花费了 3 毫秒而处理更多数据关联的 UQL 查询只花费了 0.5 毫秒。
从 3 毫秒到 0.5 毫秒的转变可能看起来无关紧要但随着查询的链式关系数量的增加它变得非常明显。SQL 中针对 10,000 行的小表的递归 5 表 JOIN 查询将需要 38 秒而 UQL 中的 5 步路径模板实现的等效查询仅需要 0.001 秒。在更一般的情况下SQL 在针对大型数据集执行冗长的链表 JOIN 时往往会遇到困难。虽然并发性的低效利用确实造成了这种显著差异但与 UQL 相比所有 JOIN 过程中表记录的笛卡尔积是 SQL 查询性能指数级下降的根本原因。
使用图查询的技巧
到目前为止我们一直以传统的表格格式呈现UQL的查询结果以便与SQL进行比较。然而我们强烈建议使用 2D/3D 可视化在小规模图上表示路径查询的结果。这种方法有助于更直观地理解和分析数据。
本文中实现的查询目标表示图中的一步路径。将提供的 UQL 的返回值重新配置到这些路径并执行查询后Ultipa Manager 中获得的 2D 结果如下所示
n({DOCTOR.DNAME James Anderson}) .e({DIAGNOSIS}) .n({PATIENT}) AS p RETURN p{*}
结论
在本文中我们的目标不是全面展示图查询语言与结构化数据查询语言的不同之处。相反我们的目标是传达图数据库应该如何从根本上设计其查询语言以及为什么 SQL 可能不适合查询图数据。
代码组合的简单性和针对本机图的查询效率提供了宝贵的见解——也许在处理数据时我们应该采用更直观、更自然的方法类似于通过图来理解世界而不是陷入抽象的数据网络中关系数据库。 作者Ricky Sun
更多技术干货请关注公号【云原生数据库】
squids.cn云数据库RDS迁移工具DBMotion云备份DBTwin等数据库生态工具。
irds.cn多数据库管理平台私有云。
