跳转至

系统设计建议Graph

选择QPS优先或时延优先Graph

  • NebulaGraph 2.6.0 更擅长处理(互联网式的)有大量并发的小请求。也即:虽然全图很大(万亿点边),但是每个请求要访问到的子图本身并不大(几百万个点边)——单个请求时延不大;但这类请求的并发数量特别多——QPS大。
  • 但对于一些交互分析型的场景,并发请求的数量不多,而每个请求要访问的子图本身特别大(亿以上)。为降低时延,可以在应用程序中将一个大的请求,拆分为多个小请求,并发发送给多个graphd。这样可以降低单个大请求的时延,降低单个graphd的内存占用。另外,也可以使用Graph。

水平扩展或垂直扩展Graph

NebulaGraph 2.6.0 支持水平扩展:

  • Storaged 的水平扩展:

    - 增加storaged的机器数量,可以大体线性增加集群的整体能力,包括增加整体QPS和降低时延。

    - 但由于 partition 数量在 CREATE SPACE 时已固定,因此单个 partition 的服务能力只由单服务器决定——例如:获取单个点的属性(FETCH)、单个点开始的广度优先遍历(GO)

  • Graphd 的水平扩展:

    - 来自客户端的每个请求,都由且仅由一个 graphd 处理,其他 graphd 不会参与处理该请求。

    - 因此增加 graphd 机器数量,可以增加集群整体QPS,但不能降低单个请求时延。

  • Metad 不支持水平扩展。

垂直扩展通常硬件成本更高,但运维操作相对简单。NebulaGraph 2.6.0 也可以垂直扩展。

数据传输与优化Graph

  • 读写平衡。NebulaGraph 适合读写平衡性的在线场景,也即 OLTP 型的的“并发的发生写入与读取”;而非数仓 OLAP 型的“一次写入多次读取”。
  • 选择不同的写入方式。大批量的数据写入可以使用sst加载的方式;小批量的写入使用INSERT语句。
  • 选择合适的时间运行 COMPACTION 和 BALANCE,来分别优化数据格式和存储分布。
  • NebulaGraph 2.6.0 不支持关系型数据库意义上的事务和隔离性,更接近 NoSQL。

查询预热与数据预热Graph

应用端进行预热:

  • Graphd 不支持预编译查询及相应生成查询计划,也不支持缓存之前的查询结果;
  • Storaged 不支持预热数据,只有 RocksDB 自身的 LSM-tree 和 BloomFilter 会启动时加载到内存中。
  • 点和边被访问过后,会各自缓存在 Storaged 的两种 (LRU) Cache 中。

最后更新: June 1, 2021
Back to top