图数据库基准测试与压测：LDBC SNB、混合负载与尾延迟

用途 A：选型（A 还是 B？）
  要公平：同一数据集、同一硬件、同一负载、同样调优力度
  产出：典型查询上的延迟/吞吐对比 + 运维复杂度定性评价
  陷阱：厂商给的 benchmark 通常在自家最擅长的负载上跑

用途 B：容量规划（需要几台机器？）
  要贴近生产：用真实数据规模与真实查询分布
  产出：目标延迟下的最大可持续吞吐 → 反推机器数
  陷阱：用峰值吞吐做规划，生产一有毛刺就雪崩

用途 C：回归验证（升级/调参有没有变快？）
  要可重复：固定数据集与负载，只改一个变量
  产出：同一套指标的前后对比 + 显著性判断
→ 先明确用途，再设计基准；三者的方法论不通用

1. 查询类型：点查 / 一跳 / 多跳 / 全图算法 / 聚合
2. 并发水平：单线程延迟 vs 高并发吞吐（两者常成反比）
3. 缓存状态：冷缓存（首次访问）vs 热缓存（page cache 命中）
4. 数据规模：小图放得下内存 vs 大图必须走磁盘
5. 读写比例：纯读 / 读写混合 / 写为主
6. 结果规模：返回 10 行 vs 返回 10 万行（网络与序列化开销）
→ 只报一个「平均延迟」数字，等于什么都没说

SNB 的组成部分：
1. 数据生成器（Datagen）：按社交网络语义生成可伸缩的数据
   - 有明确的数据模式（Person/Post/Comment/Forum/Tag/City...）
   - 有相关性（不是随机图：存在社区、幂律度分布、时间演化）
2. 工作负载：
   - Interactive（交互式）：低延迟复杂查询 + 短事务更新
   - BI（商业智能）：大规模聚合分析查询（跑分钟级）
3. 更新流：持续插入新的人、帖子、好友关系
4. 验证：查询结果有正确性校验，防止「跑得快但算错了」
→ 价值：可复现、有语义、能横向对比；社区有公开的审计结果

LDBC SNB 的规模因子：
SF1  ≈ 3 GB（约 320 万节点）      SF10 ≈ 30 GB
SF3  ≈ 10 GB                      SF30 ≈ 100 GB
SF100 ≈ 300 GB（约 3 亿节点）
→ 报结果必须写清 SF，否则数字毫无意义
→ 「SF1 上 5ms、SF100 上 5s」完全可能（内存放不下时性能断崖）

1. 度分布：真实社交/资金图是幂律（少数枢纽 + 大量低度节点）
   → 用均匀随机图压测会严重低估超节点带来的问题
2. 社区结构：真实图有聚类（朋友的朋友也认识）
   → 无聚类的图会让多跳查询结果规模失真
3. 时间演化：节点与边有先后顺序（新节点更活跃）
   → 时间维度影响增量写入与时序查询的性能
→ SNB Datagen 已内建这些性质，自研生成要自己补

- 规模因子与总数据量（节点数/边数/属性字节数）写进报告
- 度分布的形状（max/median 度数、超节点数量）
- 是否含时间戳、是否有环、有向还是无向
- 数据量与可用内存的比值
- 导入耗时与导入方式（批量导入 vs 在线写入）
→ 缺任何一项，别人都无法复现你的结论

import random

def gen_powerlaw_graph(n, alpha=2.5):
    """生成幂律度分布的有向图：少数枢纽 + 大量低度节点"""
    weights = [1.0 / (i ** alpha) for i in range(1, n + 1)]
    total = sum(weights)
    weights = [w / total for w in weights]
    deg_target = [max(1, int(random.choices(range(1, n + 1), weights)[0] / 10))
                  for _ in range(n)]
    edges = set()
    for u in range(n):
        for _ in range(deg_target[u]):
            v = random.choices(range(n), weights)[0]
            if v != u:
                edges.add((u, v))
    return list(edges)

# 关键：生成后必须校验度分布是否真的是幂律（双对数坐标下近似直线），
# 否则生成器参数写错会退化成均匀随机图，压测结论全部失真

import random, time, statistics

READ_TEMPLATES = [                      # (名称, 权重, 查询)
    ("point_lookup", 0.40, "MATCH (a:Account {id:$id}) RETURN a"),
    ("one_hop",      0.30, "MATCH (a:Account {id:$id})-[:T]->(b) RETURN count(b)"),
    ("two_hop",      0.20, "MATCH (a:Account {id:$id})-[:T*2]->(b) RETURN count(DISTINCT b)"),
    ("agg_window",   0.10, "MATCH (a:Account {id:$id})-[:T]->(b) "
                           "WHERE b.ts > $ts RETURN sum(b.amount)"),
]
WRITE_TEMPLATES = [
    ("add_edge",    0.70, "MATCH (a:Account {id:$s}),(b:Account {id:$d}) "
                          "MERGE (a)-[:T {ts:$ts, amount:$amt}]->(b)"),
    ("update_prop", 0.30, "MATCH (a:Account {id:$s}) SET a.score = $v"),
]

def pick(templates):
    r, acc = random.random(), 0.0
    for name, w, q in templates:
        acc += w
        if r <= acc:
            return name, q
    return templates[-1][0], templates[-1][2]

def run_mixed(driver, seconds, write_ratio=0.1):
    """按比例混合读写，记录每个模板的延迟分布"""
    lat, stop = {}, time.time() + seconds
    while time.time() < stop:
        name, q = pick(WRITE_TEMPLATES if random.random() < write_ratio
                       else READ_TEMPLATES)
        params = {"id": rand_id(), "s": rand_id(), "d": rand_id(),
                  "ts": now_ms(), "amt": rand_amt(), "v": random.random()}
        t0 = time.perf_counter()
        with driver.session() as s:
            s.run(q, **params).consume()      # 必须 consume，读全结果
        lat.setdefault(name, []).append((time.perf_counter() - t0) * 1000)
    return {k: {"p50": statistics.median(v),
                "p99": sorted(v)[int(len(v) * 0.99) - 1]} for k, v in lat.items()}

1. 吞吐：QPS / TPS，以及「在什么延迟下达到」
   → 「吞吐 5000 QPS」若不写延迟，可能是 p99 已经 5 秒
2. 延迟分布：p50 / p90 / p95 / p99 / p999 / max
   → 平均值掩盖一切；p99 才是用户感知与 SLO 的关键
3. 正确性：结果是否与预期一致（防「跑得快但算错」）
   → LDBC 有官方校验；自研基准要自己写断言
→ 三个缺一不可，尤其正确性最容易被压测脚本忽略

def assert_correct(driver, checks):
    """checks: [(名称, 查询, 参数, 期望值), ...]"""
    for name, query, params, expected in checks:
        with driver.session() as s:
            got = s.run(query, **params).single()[0]
        if got != expected:
            raise AssertionError(f"{name}: got {got}, expected {expected}")

正确性校验的三种粒度：
1. 逐查询断言：每个模板配一个已知答案的用例（最实用）
2. 交叉校验：与另一个实现或另一份数据快照的结果对拍
3. 不变量校验：如「计数不为负」「路径长度单调」等结构性约束
→ 加断言的成本很低，漏掉的代价是结论完全错误

这张表比「平均 38ms」有用得多：
- two_hop 的 p99 是 p50 的 14 倍 → 尾延迟问题集中在这个模板
- agg_window 有 1.2% 错误率 → 超时或资源不足，必须单列不能剔除
- 按权重加权后整体 p99 约 620ms，远高于平均值暗示的「还行」
→ 报告模板固定下来，回归对比才有意义

1. 官方驱动 + 自写脚本：完全可控，能精确表达业务负载与正确性校验；
   代价是要自己实现并发、统计、限流
2. 通用压测框架（JMeter / Gatling / k6 / Locust）：并发模型、报告、
   限流开箱即用；代价是图查询的参数化与结果校验要额外写
3. 图数据库自带压测工具（LDBC 官方驱动、厂商套件）：与标准对齐、
   结果可对比；代价是只能测它支持的负载
→ 常见组合：官方驱动跑 SNB（选型），Locust/k6 跑自研混合负载（容量）

from locust import User, task, between
from neo4j import GraphDatabase
import random

class GraphUser(User):
    wait_time = between(0.001, 0.01)      # 控制请求间隔，模拟思考时间

    def on_start(self):
        self.driver = GraphDatabase.driver(
            "bolt://db:7687", auth=("neo4j", "pw"),
            max_connection_pool_size=50)   # 池要够，否则测的是池等待

    @task(40)
    def point_lookup(self):
        with self.driver.session() as s:
            s.run("MATCH (a:Account {id:$id}) RETURN a",
                  id=random.randint(1, 1_000_000)).consume()

    @task(30)
    def one_hop(self):
        with self.driver.session() as s:
            s.run("MATCH (a:Account {id:$id})-[:T]->(b) RETURN count(b)",
                  id=random.randint(1, 1_000_000)).consume()

    @task(20)
    def two_hop(self):
        with self.driver.session() as s:
            s.run("MATCH (a:Account {id:$id})-[:T*2]->(b) "
                  "RETURN count(DISTINCT b)",
                  id=random.randint(1, 1_000_000)).consume()

    @task(10)
    def add_edge(self):
        with self.driver.session() as s:
            s.run("MATCH (a:Account {id:$s}),(b:Account {id:$d}) "
                  "MERGE (a)-[:T {ts:$ts}]->(b)",
                  s=random.randint(1, 1_000_000),
                  d=random.randint(1, 1_000_000), ts=0).consume()

    def on_stop(self):
        self.driver.close()

必须报告的内容（缺一不可）：
1. 硬件：CPU 型号/核数、内存、磁盘类型（SSD/NVMe）、网络
2. 软件：数据库版本、配置项（尤其内存与并发相关）、JVM 参数
3. 数据：规模因子、节点/边数、导入方式与耗时
4. 负载：查询模板、参数分布、读写比例、并发数、持续时间
5. 口径：客户端/服务端延迟、是否读全结果、冷热缓存、预热时长
6. 结果：吞吐、p50~p999、错误率、资源使用率
→ 缺任何一项，别人都无法复现，也就无法验证你的结论

数据：LDBC SNB SF10（约 30GB）+ 生产脱敏样本做交叉验证
环境：单机 32 核 / 128GB / NVMe；数据量/内存 ≈ 0.25（可全放内存）
配置快照：page cache 分配 80GB、堆 16GB、并发连接上限 1000
基线记录：无负载时的空转资源占用（CPU 2%、内存 18GB）

典型曲线形态：
1→64：吞吐近似线性上升，延迟基本持平（资源未饱和）
64→256：吞吐增速放缓，p99 开始抬升（接近饱和）
256→512：吞吐不再增长，p99 翻倍（排队主导）
→ 饱和点（吞吐拐点）就是容量上限；SLO 应取拐点之前的某个点
→ 规划时留 30%~50% 余量，不要贴着拐点部署

结论模板：
- 在 <硬件配置> 上，<数据规模> 的数据，<负载定义> 下：
  吞吐 <X> QPS 时 p99 = <Y> ms；饱和点约 <Z> QPS（并发 <C>）
  写入比例从 10% 提升到 20% 使 p99 从 <a> 升到 <b>
- 瓶颈定位：<CPU/内存/磁盘/GC/锁> 中的哪一项
- 规划建议：按 SLO 留 30%~50% 余量 → 需要 <N> 台
→ 报告里必须有「瓶颈在哪」和「建议怎么扩」，否则只是数据搬运

每次压测产出一行记录：
配置哈希 | 数据 SF | 并发 | 写比例 | QPS | p50 | p99 | 错误率 | 瓶颈
→ 累积多行后就形成「配置 → 性能」的对照表，
  升级、调参、换硬件都能直接查表，而不必重跑
→ 这张表也是回归验证的基线，没有它「变快了」永远只是感觉

1. 客户端成为瓶颈：加压机 CPU 打满，测出的是客户端的极限
2. 不读结果集：只发查询不消费结果，延迟被严重低估
3. 参数分布失真：固定 ID 或均匀随机，与生产访问分布不符
4. 只测热缓存：忽略冷启动，上线后首次访问雪崩
5. 只测一个并发数：得到一个点而非曲线，无法定容量
6. 压测时长太短：没覆盖后台任务周期，测不到尾延迟
7. 剔除超时请求：把最慢的样本从统计里删掉，指标失真
8. 数据量未对齐内存：小图跑出「全内存」的好成绩，大图完全不同
9. 未做正确性校验：跑得快但算错，结论毫无价值
10. 环境噪声未隔离：备份/压缩/降频同时进行，结果不可复现
→ 这十条覆盖了绝大多数「结论错误」的案例，逐条核对

把这张表变成脚本里的断言，例如「压测结束时若客户端 CPU > 80% 则标记结果无效」，
比靠人记住可靠得多；失败时脚本直接报错，避免拿无效数据出结论。