How may edges can a super node have before performance degrade?

[akhilravuri-tul-scm]

Hi All,

our data model is huge that our super node will have to 10 to 15 nodes which connects to 28k child nodes with 21 edges each between node and child node.

So we just wanted to know how may edges can a super node have before performance degrade?

One more question, Are VID's indexed by default?

Thanks,
Akhil

[wey-gu]

our data model is huge that our super node will have 10 to 15 nodes that connect to 28k child nodes with 21 edges each between node and child node.
So we just wanted to know how many edges can a super node have before performance degrade?

Dear @akhilravuri2 , I cannot provide a specific number(due to the spec of the machine, traffic pattern and the schema may all vary, like in some cases 1k isn't that super while for other cases it's a supernode already) on this but vertex with 28k connection will make query traversing to it quite expansive and resource-consuming. It'll be ideal for always there is a chance to mitigate this during the schema/ETL phase, when it's not avoidable, I will recommend leveraging storaged config: max_edge_returned_per_vertex, which will truncate the edge scanning per vertex in configured value, while, please be noted this means your query isn't logically correct due to this transaction.

So if the truncation on the supernode is accepted, you could try giving values to see what happens on your queries involving those supernodes.

ref:

• https://docs.nebula-graph.io/3.1.0/8.service-tuning/super-node/
• https://docs.nebula-graph.io/3.1.0/5.configurations-and-logs/1.configurations/4.storage-config/#for_super-large_vertices

One more question, Are VID's indexed by default?

Good question, yes, VID is indexed by default, it's because the data siting in the underlying RocksDB are in the format of

Where the vid of a vertex is in the key part, and it's sorted in RocksDB's LSM Tree, thus, seeking a vid is just a prefix seek.

ref:

• https://siwei.io/en/nebula-index-explained/
• https://nebula-graph.io/posts/nebula-graph-storage-engine-overview *

* the image and this post are based on nebula 1.0, there are changes on this since nebula graph 2.0, but it's relatively the same.

BR//Wey

[akhilravuri-tul-scm]

Good question, yes, VID is indexed by default, it's because the data siting in the underlying RocksDB are in the format of

If Yes then why we are unable to get the vertices using Match (v:player) return v without creating an index.

Thanks,
Akhil

[akhilravuri-tul-scm]

I will recommend leveraging storaged config: max_edge_returned_per_vertex, which will truncate the edge scanning per vertex in configured value,

I will not retrieve all the edges and nodes...In that big graph I will retrieve only one path.

[wey-gu]

If Yes then why we are unable to get the vertices using Match (v:player) return v without creating an index.

The index is about finding the starting point from properties as you don't know a VID, thus it will end up full-scan of the data, and nebula chose to prohibit this full-scan, but it's allowed when this query is sampling with a limit, thus Match (v: player) return v limit 100 is allowed even without index.

You could read more in my post: https://siwei.io/en/nebula-index-explained/