设想一下，你是反诈中心的一位老刑警。过去办案，你要抱着一摞厚厚的纸质档案册，每一本是一个人的身份信息和银行流水。想查“张三最近把钱转给了谁”，翻册子要十分钟；想查“张三的钱最终流进了谁的口袋”，中间可能隔着五六个转账人，你需要在几十本册子之间来回翻，一个下午就这么没了。今天，指挥中心引入了一套全新的“关系沙盘”——TigerGraph。整座城市的人和资金往来被织成一张巨网：每个账户是一枚图钉，每笔转账是一根连线。更厉害的是 GSQL，这套沙盘的指挥语言——它让所有辖区的警员在同一秒同时出发，顺着一笔钱往下追五跳、十跳，几秒钟就把整条隐藏资金链摆到指挥长面前。这就是图数据库，尤其是 TigerGraph 原生并行图计算 GSQL 的魅力。下面我们从零开始：先看关系沙盘长什么样，再看它凭什么快，最后看它怎么抓坏人。

岗位关联

掌握 GSQL 与并行图计算的核心思想，意味着你能在反欺诈、社交推荐等关系密集型场景中，把查询从分钟级压到秒级——这是数据工程师与算法工程师拉开差距的关键技能。

目录
  1. 可视化演示
  2. 图数据库基础：从档案册到关系沙盘
  3. TigerGraph架构：浇筑式巨无霸沙盘
  4. GSQL语法特性：二合一指挥手册
  5. 并行执行引擎：全城警员同时开工
  6. 深链路查询：顺藤摸瓜五跳抓人
  7. 性能优化策略：先圈草地再放猎犬
  8. 实战应用案例：指挥中心战报墙
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

本节配有交互动效（进入视口后自动加载，约 3KB）。

系统可视化 处理流程：输入→处理→模型→输出 性能监控：实时指标 P=L×T

图数据库基础：从档案册到关系沙盘

在反诈中心的档案室里，老刑警最怕三件事：查关系、查多跳关系、查多跳关系还要快。张三给李四转过钱，翻一册；李四又转给王五，再翻一册；要查“张三的钱三跳后进了谁的账户”，就得三本册子来回翻。关系一旦隔了三四个人，办案基本靠加班。

图数据库换了个思路：与其把每个人写在独立册子里，不如把全城关系直接铺成一张“关系沙盘”。每个账户是一枚图钉（节点），每笔转账是一根连线（边）。查关系不再翻册子，而是顺着沙盘上的线直接走。

数学上，这张沙盘叫图，记作 G=(V,E)。图数据库把节点和边当作一等公民来存储和索引：存一个账户，就顺带存好它连了哪些邻居。相比关系型数据库用“外键加 JOIN”现场拼接关系，图数据库是提前把关系铺好，查询时局部游走，不需要把两张百万行的大表做笛卡尔积。

所以老刑警第一次见到沙盘时感慨：以前是“查一个人翻一本书”，现在是“找一个人低头看一眼他的图钉连线”——查关系这件事，从体力活变成了眼力活。这就是图数据库的地基。

G=(V,E)\displaystyle G = (V, E)
图就是“顶点集合 V 加上边集合 E”，顶点是账户，边是账户之间的转账关系。
  1. G 表示整张关系图图结构就是城市关系沙盘本身，装下了所有账户与转账关系。
    G=(V,E)\displaystyle G = (V, E)
  2. V 是顶点集合V 是所有账户图钉的集合，从第 1 个到第 n 个账户都在其中。
    V={v1,v2,…,vn}\displaystyle V = \{v_1, v_2, \ldots, v_n\}
  3. E 是边集合E 是所有转账连线的集合，每条边 (u,v) 连接两个账户。
    E={(u,v)∣u∈V, v∈V}\displaystyle E = \{(u, v) \mid u \in V,\ v \in V\}

TigerGraph架构：浇筑式巨无霸沙盘

城市太大，一张沙盘放不下。TigerGraph 的解法是：把整座城一次性浇筑成一张巨无霸沙盘，再按辖区切成若干分区，每个分区由一台服务器负责。注意“一次性浇筑”这个细节——图钉和连线是物理上连在一起的，这叫原生图存储。

原生图存储的意思是：一个顶点存着指向邻居的直接指针，查“这人的所有联系人”根本不用查索引表，沿着指针读一遍即可。关系型数据库用关联表模拟图，每跳一层都要做一次 JOIN；原生图则是“线就长在图钉上”。

在架构上，TigerGraph 把数据分布到多台机器上（分布式多节点），每台机器有自己的计算引擎；查询一来，这些引擎组成并行计算引擎同时开工。配合高性能索引，即使不做全图扫描，也能快速锁定起点顶点所在的区。

辖区越多，理论上破案越快；但辖区之间要打电话核对线索，这通“电话”就是通信开销。理解了电话费，就理解了加速比为什么到不了分区数。

Sp=T1Tp\displaystyle S_p = \frac{T_1}{T_p}
加速比 S_p 等于“单台机器串行耗时”除以“p 台机器并行耗时”，理想最大是 p，实际受通信开销拖累。
  1. T1 是单机串行耗时整个任务都交给一台机器跑完需要的时间。
    T1=串行执行时间\displaystyle T_1 = \text{串行执行时间}
  2. Tp 是 p 台机器并行耗时任务分到 p 个分区同时执行后，从开始到全部结束的墙钟时间。
    Tp=并行执行时间\displaystyle T_p = \text{并行执行时间}
  3. Sp 是加速比加速比等于串行耗时除以并行耗时，理想情况下最大接近分区数 p。
    Sp≤p\displaystyle S_p \le p

GSQL语法特性：二合一指挥手册

指挥中心发了两本命令手册。第一本教警员“要什么”：你只说“报告，把 3 跳内所有可达的嫌疑人列出来”，剩下交给系统——这叫声明式。第二本教警员“怎么做”：先查 A，再沿线走，遇到 B 就停下——这叫过程式。GSQL 把两本手册装订成了一本。

GSQL（GraphSQL）是 TigerGraph 的查询语言。它的声明式部分用类似 SQL 的 SELECT/MATCH 语法描述想要的子图模式；过程式部分提供 IF/WHILE/FOREACH 和变量，让复杂算法（多跳循环、条件分支）写起来像写程序。

混合编程模式的最大受益者是深链路算法：一段 GSQL 脚本既能声明“我要 3 跳邻居”，又能用循环控制跳数、用 IF 过滤可疑账户。支撑这一切的，是累加器（Accumulator）——绑定在顶点或全局的聚合变量。并行执行时，每个分区各自维护本地累加，最后由引擎自动合并，程序员不用手写分布式协调。

有了这本二合一手册，全城警员才能行动整齐：要什么说得清，怎么做写得明，各辖区的线索还能自动拼成一张完整的犯罪网络。

X(v)=∑u∈N(v)w(v,u)×f(u)\displaystyle X(v) = \sum_{u \in N(v)} w(v, u) \times f(u)
每个顶点的累加器最终值，等于所有邻居贡献的加权和：转账金额越大、邻居越可疑，这个顶点的风险分越高。
  1. X(v) 是顶点 v 的累加值它就是 GSQL 里绑定在顶点上的累加器，最终存着邻居们贡献的汇总结果。
    X(v)=累加器最终值\displaystyle X(v) = \text{累加器最终值}
  2. N(v) 是 v 的邻居集合所有与 v 直接相连的账户，即沙盘上与 v 有连线的那群图钉。
    N(v)={u∣(u,v)∈E}\displaystyle N(v) = \{u \mid (u, v) \in E\}
  3. w(v, u) 是边权重例如转账金额，金额越大贡献越大。
    w(v,u)=转账金额\displaystyle w(v, u) = \text{转账金额}
  4. f(u) 是邻居特征例如该账户是否已被标记为高风险，取 1 表示可疑、0 表示正常。
    f(u)∈{0,1}\displaystyle f(u) \in \{0, 1\}

并行执行引擎：全城警员同时开工

真正开跑时，指挥中心把沙盘切成 K 个辖区，每个辖区配一名警员。所有人同时出发，各自负责自己那片图钉。谁的线索跨过辖区边界，就通过对讲机喊隔壁——这就是并行执行引擎的工作画面。

引擎拿到一条 GSQL 查询后，先把查询计划自动分配到所有分区（任务自动分配），你不用手动指定“谁跑哪块”。每个分区只处理本地顶点（分区并行处理），遇到跨分区的边就打包成消息发出去（跨节点通信）。

每一轮迭代，分区并行扫描本地顶点、更新累加器，把变化通过消息传给邻居分区；下一轮再用收到的消息继续推进，最后把所有分区的部分结果汇总归约成最终答案（结果合并归约）。这种“局部计算 + 消息传递 + 归约”的模式，正是原生并行图计算的核心套路。

破案总时长由最慢的辖区和辖区间的对讲机决定——想快，就要让各区活差不多重，还要把“电话费”压到最低。

Ttotal=max⁡1≤i≤pTi+Tcomm\displaystyle T_{\text{total}} = \max_{1 \le i \le p} T_i + T_{\text{comm}}
查询总耗时等于“最慢分区的耗时”加上“跨分区通信耗时”——木桶效应与对讲机费用共同决定整体速度。
  1. Ti 是第 i 个分区的本地耗时第 i 个辖区警员在自己地盘上摸排需要的时间。
    Ti=第 i 个分区计算时间\displaystyle T_i = \text{第 } i \text{ 个分区计算时间}
  2. max 取最慢分区整体进度被最慢的辖区卡住，这就是木桶效应。
    max⁡1≤i≤pTi\displaystyle \max_{1 \le i \le p} T_i
  3. T_comm 是跨分区通信耗时辖区间互相传线索（消息传递）的总开销，并行规模越大，这笔账越不能忽略。
    Tcomm=通信总开销\displaystyle T_{\text{comm}} = \text{通信总开销}

深链路查询：顺藤摸瓜五跳抓人

顺藤摸瓜是刑侦的基本功。一笔赃款从 A 转给 B，B 转给 C，再转给 D、E，最后进了境外账户——中间隔了五个人。老刑警需要一张能一次走五步的沙盘，而不是翻五轮册子。

深链路查询指两点之间隔了多个中间节点的关系检索，也就是多跳查询。反欺诈中最典型的深链路模式是“循环转账”：A→B→C→A，钱转了一圈回到原点，往往是在洗钱。另一个模式是“分散转入、集中转出”：几十个小账户的钱汇聚到一个大账户。

图上游走的每一步，候选范围都按邻居数量扩张，最坏情况是每跳扩大 d 倍（d 为最大度数），所以不剪枝的深链路会指数爆炸。但关系型库也逃不掉：实现同样的 5 跳查询要做 4 次 JOIN，中间结果膨胀得更厉害。TigerGraph 用并行分区加累加器加剪枝，把 5 到 10 跳的实时查询变成可能；社交网络分析里的“影响力传播路径”，本质也是这种深链路查询。

藤蔓再深，只要沙盘上每一段藤都看得清，瓜就总能被找到——这正是深链路查询存在的意义。

∣Rk∣≤d k\displaystyle \left| R_k \right| \le d^{\,k}
第 k 跳能够触达的顶点数，最坏情况下按最大度数 d 的 k 次方增长——这就是为什么深链路必须靠并行和剪枝兜底。
  1. R_k 是第 k 跳可达顶点集合从起点出发恰好走 k 步能够到达的所有账户。
    Rk={v∣dist⁡(s,v)=k}\displaystyle R_k = \{v \mid \operatorname{dist}(s, v) = k\}
  2. d 是图的最大度数沙盘上连线最多的那个账户的邻居数量。
    d=max⁡v∈Vdeg⁡(v)\displaystyle d = \max_{v \in V} \deg(v)
  3. d^k 给出最坏扩张上界每一步最多新增 d 倍候选，说明不剪枝的话深链路查询会指数爆炸，必须靠并行与剪枝兜底。
    ∣Rk∣≤d k\displaystyle \left| R_k \right| \le d^{\,k}

性能优化策略：先圈草地再放猎犬

老刑警不傻，不会把全城二十万个账户挨个盘问一遍。他先看通缉令照片（属性过滤）、圈定几个活跃区域（剪枝）、再分配人手（资源调度）。这套经验搬到 GSQL 上，就是性能优化。

第一抓手是查询模式设计：能局部遍历就别全图扫描；把重活拆成多个子查询分步执行；能用累加器聚合就别逐点查库。第二抓手是索引与剪枝：先用“转账金额大于阈值”“账户类型等于可疑”这类属性条件把候选子图缩小，再在候选上做深链路游走。

第三抓手是资源调度调优：图数据天然负载不均——热门账户（如中心化交易所）所在的“热分区”压力极大，需要合理设置并行度和资源配额。剪枝的收益可以量化：候选集合从 P0 缩小到 P1，深链路查询要探索的搜索空间就缩小了 R 倍。

好猎手不追全城的野兔，而是先圈定那片草地。GSQL 调优的精髓，就是让每一分算力都花在值得追的图钉上。

R=∣P0∣∣P1∣\displaystyle R = \frac{\left| P_0 \right|}{\left| P_1 \right|}
剪枝收益 R 等于“剪枝前候选集合大小”除以“剪枝后候选集合大小”，R 越大说明要走的冤枉路越少。
  1. P0 是剪枝前的候选集合把所有符合条件的账户都捞出来，样本量大。
    P0=剪枝前候选\displaystyle P_0 = \text{剪枝前候选}
  2. P1 是剪枝后的候选集合先用金额、账户类型等属性把明显无关的账户筛掉，留下的都是重点。
    P1=剪枝后候选\displaystyle P_1 = \text{剪枝后候选}
  3. R 是搜索空间缩小倍数R 越大说明剪枝越狠，深链路查询要走的冤枉路越少。
    R=∣P0∣∣P1∣\displaystyle R = \frac{\left| P_0 \right|}{\left| P_1 \right|}

实战应用案例：指挥中心战报墙

指挥中心上线一周年，战报贴满了墙：反欺诈组、社交关系组、推荐组、知识图谱组，每一组都在晒沙盘带来的战绩。

金融反欺诈是 TigerGraph 的招牌场景：图里有 10 亿账户、200 亿笔转账，GSQL 用并行深链路查询在毫秒级完成“3 跳内循环转账”和“分散转入集中转出”的检测，团伙一冒头就被圈住。社交网络分析则用并行 PageRank 和社区发现找出意见领袖；推荐系统把“用户-物品-用户”的共现路径变成可解释推荐；知识图谱让实体关系推理和问答检索有了图上的快车道。

评价反欺诈系统的效果，不能只看抓了多少，还要看漏了多少——这就是召回率。TP 是正确抓出的异常账户，FN 是漏网之鱼，召回率等于抓住的占总坏人的比例。深链路并行查询的价值，正在于把 FN 压下去。

战报上那些飙升的数字，就是“关系沙盘 + 二合一手册 + 全城警员并行”三件套合力的结果——也是你读到这里时已经掌握的整套故事。

Rrecall=TPTP+FN\displaystyle R_{\text{recall}} = \frac{TP}{TP + FN}
召回率等于“正确抓出的异常账户”除以“所有真实异常账户”（抓出的加漏网的），衡量坏人被抓住的比例。
  1. TP 是正确抓出的异常账户系统识别为可疑、事后核实确实有问题的账户数量。
    TP=正确识别数\displaystyle TP = \text{正确识别数}
  2. FN 是漏网的异常账户实际有问题但系统没标记出来的账户数量。
    FN=漏报数\displaystyle FN = \text{漏报数}
  3. R_recall 是召回率真实坏人里被系统抓住的比例，反欺诈场景里“少漏一个”往往比“少错一个”更关键。
    Rrecall=TPTP+FN\displaystyle R_{\text{recall}} = \frac{TP}{TP + FN}

AI 应用场景

金融反欺诈：毫秒级团伙识别

阶段：特征工程与关系推理（风控模型上线前的召回特征计算）

解决的问题：传统规则引擎只盯单账户的流水与频次，看不到“钱经过五手回流”“几十个小账户汇聚一个大账户”这类团伙模式。GSQL 把每个可疑交易放回整张关系网中，用并行深链路查询在 3 到 5 跳内圈出犯罪网络，把关系特征实时喂给风控模型。

具体案例：某支付平台用 TigerGraph 存储 10 亿账户、200 亿笔转账，用 GSQL 实现“3 跳内循环转账 + 分散转入集中转出”的团伙识别查询，日均拦截数千个洗钱团伙，模型召回率从 62% 提升到 89%。

社交网络分析：寻找意见领袖与社区

阶段：图特征计算与社区发现（用户画像、传播预测的底层支撑）

解决的问题：营销团队想知道“哪些人辐射最广、消息沿什么路径扩散”，关系型库算 5 跳好友代价巨大；GSQL 原生并行执行 PageRank、社区发现和影响力路径枚举，让亿级用户的传播分析分钟级出结果。

具体案例：某社交 App 用 GSQL 对关注关系做并行 PageRank 和标签传播社区检测，圈出 3000 个高影响力用户，广告投放 ROI 提升 35%。

知识图谱查询：可解释推荐与问答

阶段：知识图谱构建与关系检索（推荐、问答系统的推理底座）

解决的问题：把用户、商品、品牌、事件连成知识图谱后，推荐从“行为相似”升级到“关系路径可解释”。GSQL 并行查询“用户-浏览-商品-同类商品”路径，让推荐理由变成一条看得见的关系链。

具体案例：某电商平台用 GSQL 在商品知识图谱上做多跳路径查询，生成“你看过的商品，与它同品牌的热销款”这类可解释推荐，点击率提升 18%。

Python 演示

python46 行
#!/usr/bin/env python3# -*- coding: utf-8 -*-"""用 Python 模拟 TigerGraph GSQL 的原生并行风险扩散查询:从黑名单账户出发, 沿转账边做最多 3 跳的风险标记."""from collections import deque  class SimGraph:    def __init__(self):        self.adj = {}  # 邻接表: 账户 -> 相邻账户列表     def add_edge(self, u, v):        self.adj.setdefault(u, []).append(v)        self.adj.setdefault(v, []).append(u)  def risk_propagate(g, seeds, max_hop=3):    """模拟 GSQL 累加器的并行消息传递: 每轮所有节点同步扩张一跳."""    risk = {s: 0 for s in seeds}    cur = seeds[:]    for hop in range(1, max_hop + 1):        nxt = []        for acc in cur:            for nb in g.adj.get(acc, []):                if nb not in risk:                    risk[nb] = hop                    nxt.append(nb)        cur = nxt    return risk  def main():    g = SimGraph()    pairs = [("a", "b"), ("b", "c"), ("c", "d"),             ("c", "e"), ("e", "f"), ("f", "g"),             ("x", "y"), ("y", "z"), ("z", "b")]    for u, v in pairs:        g.add_edge(u, v)    seeds = ["a", "x"]    result = risk_propagate(g, seeds, max_hop=3)    for acc in sorted(result):        print(acc, "风险跳数", result[acc])  if __name__ == "__main__":    main()
目的：演示 TigerGraph GSQL 多跳风险扩散查询的核心逻辑——并行消息传递、剪枝去重、累加结果。
  1. risk = {s: 0 for s in seeds}初始化风险标记字典，相当于 GSQL 中给种子顶点赋初始值的累加器。
  2. for hop in range(1, max_hop + 1):控制最大追查跳数，对应 GSQL 过程式语言里的多跳循环。
  3. for nb in g.adj.get(acc, []):并行扫描当前账户的邻居，模拟分布式引擎在每个分区同时展开查询边。
  4. if nb not in risk:剪枝：已经标记过的账户不再重复入队，避免循环转账带来的死循环。
  5. result = risk_propagate(g, seeds, max_hop=3)执行整段“GSQL 脚本”，返回 3 跳内所有嫌疑账户及风险跳数。

常见误区

误区我一直以为图数据库就是生成社交关系图、知识图谱那些漂亮连线图表的工具，跟 BI 可视化差不多，存的是图片。

正解图数据库存储的是拓扑结构——节点、边以及边上的属性，它把“关系”本身当作一等公民持久化。可视化只是查询结果的一种展示方式。回到沙盘比喻：沙盘的价值不是“好看”，而是图钉和连线本身可以被顺着走、被搜索、被并行计算。

为何常见：“图”在中文里既有 graph 又有 picture 的含义，初学者看到“图”字自然联想到图片和图表，而忽略了它指的是数学上的图论结构。

误区既然叫 GSQL，语法肯定和 SQL 差不多，我在 MySQL 里写过 select/join，直接上手应该没问题。

正解GSQL 虽然沿用类 SQL 关键字，但它操作的是顶点和边，还引入了累加器、分布式并行执行、过程式控制等 SQL 完全没有的概念。好比两本手册都叫“巡逻手册”，但一本是交警的、一本是刑警的，任务模型完全不同。

为何常见：命名相似带来幸存者偏差，人们倾向于用已知的 SQL 心智模型去套 GSQL，忽略图查询独有的执行模型。

误区TigerGraph 会自动把查询并行化，那我写个全图遍历或者超深的多跳查询，反正引擎会帮我加速。

正解并行加速受三个硬约束：通信开销、最慢分区（木桶效应）、以及查询里不可避免的串行片段。查询模式不剪枝、累加器滥用，照样会把引擎拖垮。沙盘再大，如果警员全城地毯式搜索而不是先圈重点，一样要加班。

为何常见：把“并行”理解成万能加速器，忽略了 Amdahl 定律和真实分布式系统的工程开销。

误区图数据库这么厉害，干脆把公司所有数据都迁过去，一张图搞定一切。

正解关系型数据库在强事务（ACID）、复杂聚合报表、成熟生态上仍有不可替代的优势；图数据库擅长的是关系密集型查询。实际企业架构常是“关系库管交易、图库管关系”的混合部署。就像沙盘再先进，户籍档案册还得留一本做法律凭证。

为何常见：只看到图查询的强大，忽略了事务、报表、迁移成本和生态成熟度等现实因素。

误区查 5 跳关系不就是把五张表 JOIN 在一起吗？MySQL 加索引也能做，为什么非得上图数据库？

正解关系库做 k 跳查询需要 k-1 次 JOIN，中间结果按连接顺序指数级膨胀，索引也很难救；TigerGraph 在图上做局部游走加剪枝加并行分区，每一步只沿真实存在的边前进，复杂度可控。沙盘上顺藤摸瓜，和把五本档案册硬拼成一摞，完全是两件事。

为何常见：对多跳 JOIN 的代价模型和图游走的算法优势缺乏直观感受，低估了中间结果膨胀的杀伤力。

面试题

Q1. 图数据库中，最基本的两类元素是？

单选题 · easy

  • A.表与行（table & row）
  • B.节点与边（node & edge）← 正确答案
  • C.文件与块（file & block）
  • D.键与值（key & value）

答案：B。图数据库以节点和边为核心，节点是实体（如账户），边是关系（如转账）。表与行属于关系型数据库，文件与块属于分布式存储，键与值属于 KV 存储。用沙盘比喻：图钉是节点，连线是边，二者缺一不可。

Q2. 一个图 G=(V,E) 中，V 与 E 分别表示？

单选题 · easy

  • A.顶点集合与边集合← 正确答案
  • B.边集合与顶点集合
  • C.查询集合与结果集合
  • D.节点集合与属性集合

答案：A。V 是顶点集合（vertices），E 是边集合（edges）。边集合由顶点对组成，表示两个顶点之间的关系。搞混顺序是入门最常见的错误，记住“V 在前，E 在后”对应沙盘上“先有图钉，再拉线”。

Q3. TigerGraph 的“原生并行”主要体现在？

单选题 · mid

  • A.查询自动切分到多节点并行执行← 正确答案
  • B.用 GPU 加速所有 SQL 运算
  • C.把数据复制多份分别存储
  • D.定时批量跑离线分析任务

答案：A。TigerGraph 的并行执行引擎把一条 GSQL 查询自动分配到多个分区节点上同时执行，这是“原生并行”的核心。GPU 加速不是它的主要方式，复制多份是冗余备份而非并行查询，批量离线任务也不等于原生并行。

Q4. GSQL 的混合编程模式指的是？

单选题 · mid

  • A.声明式查询与过程式控制相结合← 正确答案
  • B.Python 与 Java 代码混合运行
  • C.多种存储引擎同时对外提供服务
  • D.把 SQL 与 NoSQL 语法合二为一

答案：A。GSQL 既能用类 SQL 的声明式语法描述“要什么子图”，又能用 IF/WHILE/FOREACH 等过程式语法控制“怎么做”，两者结合就是混合编程模式。它不是多语言混合、多引擎混合，也不是 SQL 与 NoSQL 的拼接。

Q5. GSQL 中累加器（Accumulator）的典型作用是？

多选题 · mid

  • A.在并行执行时跨分区汇总中间结果← 正确答案
  • B.为每个顶点维护可更新的聚合值← 正确答案
  • C.把查询语句自动翻译成机器码
  • D.直接替换图存储层的持久化文件

答案：AB。累加器是绑定在顶点或全局的聚合变量，各分区并行更新后由引擎自动合并，因此跨分区汇总和顶点聚合值都是它的职责。把查询翻译成机器码是编译器的事，替换持久化文件更是与累加器无关。

Q6. 深链路查询（如 5 跳转账追踪）相比关系型多表 JOIN 的优势是？

单选题 · hard

  • A.图的局部游走避免中间结果爆炸← 正确答案
  • B.多表 JOIN 会自动减少数据冗余
  • C.关系库不支持存储流水与账务
  • D.图库完全不需要索引参与查询

答案：A。关系库做 5 跳查询要 4 次 JOIN，中间结果指数级膨胀；图数据库只沿真实存在的边走，候选规模可控。JOIN 不会减少冗余，关系库当然能存流水账，图库查询也需要索引定位起点。

Q7. 影响 TigerGraph 并行查询加速比的因素有？

多选题 · hard

  • A.各分区计算负载是否均衡← 正确答案
  • B.跨节点消息传递的通信开销← 正确答案
  • C.查询中必须串行执行的片段← 正确答案
  • D.磁盘上图片文件的存储格式

答案：ABC。加速比受木桶效应（最慢分区）、通信开销和串行片段三重约束，这与 Amdahl 定律一致。图片文件存储格式与图计算加速比毫无关系，属于无关干扰项。

Q8. 关于 GSQL 查询性能优化，“剪枝”的首要目标是？

单选题 · easy

  • A.缩小搜索空间减少无效遍历← 正确答案
  • B.给所有边建立冗余索引副本
  • C.把查询拆成多条循环去重跑
  • D.增加中间结果的落盘缓存

答案：A。剪枝就是用属性条件先过滤掉无关顶点，把搜索范围缩小，让深链路查询少走冤枉路。建冗余索引、拆循环、落盘缓存都不是剪枝的本意，反而可能增加开销。

Q9. 下列哪些场景适合发挥图数据库的优势？

多选题 · mid

  • A.金融转账中识别多跳洗钱团伙← 正确答案
  • B.社交网络中寻找社区与影响力← 正确答案
  • C.复杂报表与强事务的账务结算
  • D.大型联机事务处理的订单系统

答案：AB。多跳洗钱识别和社区发现都是关系密集型查询，适合图数据库。复杂报表与强事务、高并发订单处理恰恰是关系型数据库的传统强项，强行用图库反而事倍功半。

Q10. 某团伙 A→B→C→A 循环转账，查询要求“找出所有 3 跳内回到起点的账户”，最合适做法是？

单选题 · extreme

  • A.用累加器记录路径并检测环路← 正确答案
  • B.先删除所有边再重建图索引
  • C.把数据导出到 Excel 手动核对
  • D.对所有顶点做全图笛卡尔乘积

答案：A。环形检测需要边走边记录路径，回到起点即报警，累加器绑定路径集合是 GSQL 的惯用手法。删边重建是破坏数据的错误操作，导出 Excel 不可扩展，全图笛卡尔乘积就是关系库式的爆炸 JOIN，恰恰是图库要避免的。