大学生数据库实践课：社交网络分析

本期播客

大学生数据库实践课：社交网络分析

同学们好，欢迎来到《大学生数据库实践课》第 19.1 讲。上一讲我们聊了 PGQ 的理论，今天我们直接上手，进实战场景：社交网络分析。

社交网络（Social Network）是图数据库最天然的战场。想象一下，如果你要在几亿用户里找“朋友的朋友”，或者计算“谁才是真正的网红”，传统 SQL 的多表 Join 会让你写到怀疑人生，性能也跑不动。而有了 DuckPGQ，你会发现一切变得像写自然语言一样简单。

一、 为什么社交网络离不开“图”？

在传统关系数据库里，数据是“平”的；但在社交网络里，数据是“立体”的。

• 背景：我们有一张 Person 表（点），一张 Forum 表（点），还有 knows（人认识人）和 hasMember（人属于论坛）这两张关系表（边）。
• 需求：我们不只要查“张三是谁”，我们要查“张三通过几个人能认识李四”、“张三和李四有没有共同好友”、“谁是这个社区的核心大 V”。

二、 实战案例拆解：图式搜索的四种高级玩法

我为大家准备了四个从易到难的 SQL:PGQ 示例：

1. 验证“六度分隔理论”（最短路径）

场景：我想知道用户 14 到全网其他所有人最快怎么联系。

MATCH p = ANY SHORTEST (p1:person WHERE p1.id = 14)-[k:knows]->*(p2:person)  

• 细节：那个 * 就像魔法，它代表“无限跳”，直到找到目标。这在传统 SQL 里需要写递归 CTE，非常繁琐。

2. 精准好友推荐（共同好友）

场景：系统发现 ID 为 16 和 32 的两个用户经常活跃，想看看他们之间有没有共同的朋友。

MATCH (p1:Person WHERE p1.id = 16)-[k:knows]->(p2:Person)<-[k2:knows]-(p3:Person WHERE p3.id = 32)  

• 细节：注意那个反向箭头 <-。它直观地表达了：16 认识 p2，32 也认识 p2。p2 就是那个“中间人”。

3. 捕捉“社交网红”（影响力排名）

场景：找出被最多人关注的前 3 名“大 V”。

• 逻辑：在图里匹配 (follower)-[:knows]->(person)，然后直接用标准 SQL 的 COUNT 和 ORDER BY 进行统计。这展示了 PGQ + SQL 混合查询的强大威力。

4. 深度画像：大 V 到底有多活跃？

场景：先找出全网第一大 V，再查他一共加入了多少个论坛。

• 技巧：这里用了 CTE (WITH 子句) 。先用图查询算影响力，再把结果丢给另一个图查询查论坛关联。这种链式分析是现代数据挖掘的标配。

三、 课后思考题：图数据库“三问”

为了帮大家消化，我留下三个循序渐进的问题，大家可以带入开发者的视角思考：

1. 【原理篇】：在定义属性图时，为什么要明确指定 SOURCE KEY 和 DESTINATION KEY？如果这两个 Key 指向同一张表（比如 Person），这在现实社交场景中代表什么意思？
2. 【语法篇】：观察共同好友的 MATCH 模式，如果我把箭头方向都改成同向 (p1)->(p2)->(p3)，这还叫共同好友吗？这种模式在金融风控（比如资金链追踪）中有什么意义？
3. 【应用篇】：如果我们要实现“朋友的朋友”推荐（2 度关系），但要求排掉“已经认识的好友”，你会如何修改现有的最短路径查询？

四、德哥的总结笔记

1. 表是基础，图是灵魂：DuckPGQ 让你的关系表“活”了，它不再是冷冰冰的行列，而是纠缠交错的关系网。
2. 性能降维打击：传统 SQL 处理 3 跳以上的关系几乎会瘫痪，而图查询利用 CSR（压缩稀疏行） 结构进行“指针跳转”，速度是百倍级的提升。
3. 学习路径：先学会用 CREATE PROPERTY GRAPH 建模，再熟练掌握 MATCH 里的各种箭头方向，你就能处理 80% 的复杂业务逻辑。

下一站预告：我们将深入探讨《金融风控：如何利用环路检测抓捕洗钱团伙》。

想要本文配套的 snb.duckdb 测试数据集来自行练手吗？ 或者对“三问”的答案有疑问？欢迎在评论区或 Github 留言与我交流。

详细教程, 点击「阅读原文」