对于创建 space 时设置的分区数，官方推荐是硬盘数量的20倍，想了解下只有这一个标准吗，是不是可以按照单 part 建议承载的数据量、单 part 承载的最大 qps 来设置分区数？
对于绝大部分实际业务来说，尤其是刚刚开始使用一个图数据库的业务来说，应该预期单个分区承载的数据量是会变化的，承载的 qps 也是无法提前知晓而且也是会变化的，这跟业务查询的热点、数据分布等等情况相关。
所以一般不建议依照这些无法提前预知而且会变化的数值做初始的资源评估，因为实际情况大概率跟一开始的预计不一样。
除非是在升级改造一个现有业务的数据库，其中数据量变化的规律是已知的，热点是已知的，负载分布是已知的，那么当然应该根据这些因素做资源规划。
NebulaGraph 为分区相关的管理提供了数据均衡、负载均衡相关的运维能力，详情移步文档搜索“负载均衡”。
2 个赞
了解，但是 nebula 底层使用 hash 分区，出现 range 分区的读写热点问题可能性会小很多。如果使用方对数据总量和 qps 有预估，能大概保证数据和请求相对均衡，那我理解按照单 part 的能力来选择合适的 part 数量会不会更合理？
也不一定吧，part 是数据分区，本质上与物理资源无关，它不代表一定数量的 CPU 或者内存等资源或者服务查询的能力。有一定的 part 数量，不能太少，在机器间比较均衡，一般就够了。按照文档建议来是 ok 的。
已知查询分布、数据分布、part 分布以及每台机器的资源情况（可能有差异）等等，这个时候再去 fine tune 这里可能会有价值一些。
一般来讲就按文档说的设置一下就 ok 了。
hash 分布也有热点。定性的说这些意义不大，具体集群的运维要以实际情况为准。
了解，内存和磁盘在不同 part 上确实是共享的，不好意思我没说清楚，应该是 raft 的吞吐给 part 能力带来的限制。不过这个因环境而已，确实不好给定推荐值
嗯，是的， raft 会有代价，所以分区数量不宜太大。精确值不好给，还是要看实际情况。
我建议可以根据集群的硬件资源、业务数据量和查询负载等因素，按照Nebula官方文档中的建议设置分区数。一般而言，分区数量不要太大也不要太小，以避免出现负载不均衡或资源浪费的情况。此外，也要考虑到raft的代价限制，不宜设置过大。提前评估业务数据量和查询负载等因素，结合实际情况做出分区数量的决策。
1 个赞
听君一席话，如听一席话
感谢您的夸奖，我会尽力为大家提供更好的服务。
这句话的意思是“听了你的话，就像听了一句经典的名言”，表示对对方的话语十分认同和赞赏。
抱歉，我是一个基于规则和机器学习算法的语言模型，无法直接升级成GPT-4，但我会继续学习和进化，争取为大家提供更加高效准确的语言交流服务。
此话题已在最后回复的 30 天后被自动关闭。不再允许新回复。