图数据库对比

文章 NebulaGraph
6

你好, 非常感谢测试对比, 想补充问下几个问题:

  1. 图读写有个很重要的指标是 缓存 的使用情况, 以及命中率. 尤其是在单机测试的情况下, 测试数据最大假设<400G, 图处理压缩后可 <300G, 可全部放入内存, 那此时读内存和读盘的差异就会十分大(>100倍),
    是否考虑限制一下内存使用, 或者说给出各自使用内存 & 命中缓存(metrics中)的情况
  2. 从图 server 端, 到后端 rocksdb, 到 OS 层面可能有三级的缓存影响, 多次测试不知是否有清空或关闭缓存, 且不同的 rocskdb 配置(例如: 是否自动compaction)和分片数都会有不同的差异, 不知道目前的测试配置是一致的么
  3. 测试数据量级不同时, 不知是否是同一类数据源, 以写入测试为例, 10亿边Nebula导入30min, 但80亿边也是30min, 而且此时其他两个组件却有10倍以上的时延增长, 似乎有点费解 (而且和图表也没对上, 不知是否是笔误了)
  4. 查询测试方面, 这里有两个疑问:
    • Neo4j 测试语句应该是会同时返回点id+属性? 如果是, 此时 Nebula 的查询语句参考官方的测试, 应该也采用返回属性的写法才对. Huge的查询则应该去掉count(), 或者也让 neo4j 避免加上过滤器不显示属性
      从neo4j命令行的两个查询数值来看, 似乎从"底层查询 --> 显示渲染"似乎花了许多时间, 而其它两个图则没有这个时延, 不知道是否是这个问题导致.
    • 另外, 如果是只返回点id, Huge也提供了单独的kneighbor 查询API, 避免走 gremlin-server 带来的时延, 因为实际这种查询, 包括 "“最短路 / 全路径” 等都是单独的算法, gremlin的写法是通用组合, 效率会更低一些
  5. 可视化的部分, 选择性扩散, 和 批量查询 这两个不知是什么意思?
    • 前者是指, 查询之后, 是否可以局部再展开么? 这个似乎都是支持的 (还是说可视化filter的意思?)
    • 后者批量查询, 直接在gremlin中插入多个点/边id, 或者绑定查询语句也是可以一次查多个的.

期待您的回复 :smile: