Star

如何定义超级节点?一个顶点上的关系超过多少时会面临性能问题?

  • nebula 版本:2.0.0
  • 部署方式(分布式 / 单机 / Docker / DBaaS):单机
  • 硬件信息
    • 磁盘( 推荐使用 SSD)HDD
    • CPU、内存信息:128G
  • 问题的具体描述
    在设计schema时需要考虑到后期的数据查询效率问题,看1.0文档中存在超级顶点的问题,需要手动配置优化,但是具体到Nebula中,当边的数量超过多少时可以被定义为超级节点,会面临性能问题呢?
    另外,对于2.0增加了字符串的节点id类型,但是这个字符串是定长的,如何处理顶点名长度超过固定长度的情况呢?截取前缀貌似并不合理呀,难道需要回到hash的方案吗?
2赞

第一个问题,在超级顶点这里,可以通过limit或截断机制来改善性能问题。
第二个问题,指的是在创建space的时候不知道实际vid的最大长度?然后导致在实际写数据的时候vid超过了预定长度?

第一个问题:在节点的关系数量达到多少时需要考虑截断问题?1w?还是100w?还是需要自己根据业务响应速度自己做经验判断?另外可否基于where使用边的属性来做限定?
第二个问题:节点的插入在初始设计时可能是32位长度,但是保不齐后期的业务发展会偶尔出现超过32位字符的,因此这个最大长度就很不好定义,如果设置字符串的最大长度过大(如1024)我感觉应该对于绝大部分节点是用不了这个长度的(一般小于32),这会不会导致存储浪费或者效率变低?

截断的问题,最好结合着自己的业务来做,比如推荐附近10个感兴趣的商家,可能有10000家,随便推荐10个就可以。边的属性可以放在 WHERE 中做过滤,这里还是要具体问题具体分析,因为可以加 WHERE 的语句有很多,你是想在 GO 里加 WHERE 还是 YIELD 中的 WHERE?

字段的长度最好是设置个绝大多数的 VID 的长度,不然太长的话,如果真实的 vid 没有到达这个长度,nebula 会自动补 \0 ,还是会占用实际空间。针对某些超出长度的 VID 建议在业务层做下处理,可以针对这种 VID 算 hash 或者拼接个有意义但又不跟其他 vid 冲突的字符串。

关于占用空间的问题,论坛中用户碰到过类似的情况:

2赞

浙ICP备20010487号