系统设计建议Graph

选择 QPS 优先或时延优先Graph

• NebulaGraph 2.6.1 更擅长处理（互联网式的）有大量并发的小请求。也即：虽然全图很大（万亿点边），但是每个请求要访问到的子图本身并不大（几百万个点边）——单个请求时延不大；但这类请求的并发数量特别多——QPS 大。

• 但对于一些交互分析型的场景，并发请求的数量不多，而每个请求要访问的子图本身特别大（亿以上）。为降低时延，可以在应用程序中将一个大的请求，拆分为多个小请求，并发发送给多个 graphd。这样可以降低单个大请求的时延，降低单个 graphd 的内存占用。另外，也可以使用Graph。

水平扩展或垂直扩展Graph

NebulaGraph 2.6.1 支持水平扩展：

• Storaged 的水平扩展：

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

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

• Graphd 的水平扩展：

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

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

• Metad 不支持水平扩展。

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

数据传输与优化Graph

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

查询预热与数据预热Graph

应用端进行预热：

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