知识卡片：在 SQL 规模上查询图——关系核心图分析为何认为“节点/边”模型是一种性能税

一句话结论

该预印本主张：对于企业实际运行的分析型图查询，用列式关系引擎承接图查询语言，能够匹配甚至超过原生图引擎，并且能扩展到后者因内存限制而失效的规模；属性图的“节点/边”表达并不比关系表更忠实于连接数据，反而可能带来额外的重建开销。（基于标题与候选摘要，待核实）

事件概述或研究问题

论文挑战“图分析必须使用专用图引擎，关系系统不适合连接数据”的常见假设。作者提出“关系核心”（Relational-Core）图分析路径：不应将图数据导入独立图数据库，而应让图查询直接落到已有的关系表、字段和外键上执行。

说明：本次未能抓取论文正文，论文版本、作者及具体论证细节均待核实。

方法/产品要点

• 系统名称：ClickGraph，以及面向 Databricks 方言的版本 DeltaGraph。
• 论文声称可将 Cypher 直接翻译到原生关系模式上，在 ClickHouse、Databricks 或 lakehouse 文件上原位执行。
• 不需要导入流程，不需要单独集群；输出是普通 SQL，因此查询性能不佳时可以改写，引擎本身也可扩展。
• 以上内容来自候选摘要，原文正文未获取，待核实。

主要结果或产业意义

• 论文称可借助某对等系统已发布的基准，使列式引擎在分析型图查询上比 Neo4j 快 2 到 4 个数量级。
• 论文还称在 LDBC Social Network Benchmark 套件上有可复现测量。
• 如果这些结果成立，产业意义可能在于：企业现有 SQL/数据仓库基础设施已经可以承担部分分析型图负载，而不必为此引入专用图数据库。

需要强调的是：以上均为论文主张的转述，不是第三方验证结果；具体数字需以原始论文和基准实测为准。

为什么重要

• 该工作直接关系图数据库选型：并不是所有“连接数据”都需要专门的图数据库技术栈。
• 它将图查询性能讨论从“专用引擎更优”转变为“查询表达与底层存储/执行引擎的适配”。
• 若该路线可行，企业可以在同一套关系/湖仓体系中统一处理关系型与图分析负载，降低数据移动与运维成本。

局限与不确定性

• 本文档仅基于标题和候选摘要生成，论文正文未抓取，所有具体结论都需核对原始论文。
• 论文对比的主要是分析型图查询，未必覆盖事务型图操作、递归图算法或复杂图挖掘负载。
• “2 到 4 个数量级”来自论文引用某“对等系统”已发布基准；不同工作负载、数据规模和测试条件下结论可能不同。
• ClickGraph/DeltaGraph 是否开源、能否获取、是否经第三方复测，均待核实。

可用于图书/PPT/简报的角度

• 可作为“图数据库 vs 关系数据库”争论中的一极论据：专门图存储可能是性能税。
• 引用时应写明“该预印本主张”或“初步证据显示”，避免将其表述为公认结论。
• 在介绍列式数据库或湖仓能力时，可引入“直接对关系表执行图查询”的原位分析思路。
• 可结合 LDBC Social Network Benchmark 讨论图系统评测与基准真实性问题。

与既有脉络的关系

已有相关卡片分别涉及大模型检索-整合、3D点云数据投毒、PAC-Bayes压缩，与本次“图分析引擎选型”问题没有直接承接关系。本条目的增量信息在于：提出了一种用列式 SQL 引擎覆盖图分析负载的系统/架构主张，并以 ClickGraph/DeltaGraph 和 LDBC 基准证据作为支撑（待核实）。

原始材料

• 英文标题：Relational-Core Graph Analytics Querying graphs at SQL scale, and why the node/edge model is a performance tax, not a truer picture of connected data
• 英文关键词：graph analytics; SQL; Cypher; relational model; columnar engine; ClickGraph; DeltaGraph; LDBC Social Network Benchmark
• 原始来源：https://arxiv.org/abs/2609.01525v1
• 抓取状态：正文未获取，以上内容基于标题和候选摘要整理，待核实。