系统设计建议

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

    Nebula Graph 2.5.1 支持水平扩展：

    • Storaged 的水平扩展：

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

    • Graphd 的水平扩展：

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

    • Metad 不支持水平扩展。

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

    • 选择不同的写入方式。大批量的数据写入可以使用sst加载的方式；小批量的写入使用语句。
    • 选择合适的时间运行 COMPACTION 和 BALANCE，来分别优化数据格式和存储分布。
    • Nebula Graph 2.5.1 不支持关系型数据库意义上的事务和隔离性，更接近 NoSQL。

    应用端进行预热：

    • Graphd 不支持预编译查询及相应生成查询计划，也不支持缓存之前的查询结果；
    • 点和边被访问过后，会各自缓存在 Storaged 的两种 (LRU) Cache 中。