Selecting a vertex that contains lots of edges does not return all edges in the ODocument field
When querying a vertex using database.Select or database.Query, the resulting ODocument does not contains any in or out edges if the vertex has many edges. (1000+)
Hi @holocentric-bmsnext
This is due to the fact that, after a threshold (40 edges by default), edge pointers are stored in a specific structure (called SBTreeBonsai) that is not supported by the .NET driver.
My short-term advice here is to set the ridBag.embeddedToSbtreeBonsaiThreshold (that represents that threshold) on the server to a very high value, so that Bonsai structures are never used
You can do it adding the following option to the command line:
-DridBag.embeddedToSbtreeBonsaiThreshold=100000000
If you already have a DB and you want convert Bonsai structure to regular (embedded) pointers, you can also set the following:
-DridBag.sbtreeBonsaiToEmbeddedToThreshold=100000000
(set it to the same value as the previous one)
and then run an UPDATE V REMOVE nonexistingproperty, this will force an update of all the vertices and will trigger the conversion of the data structures
I hope it helps
Thanks
Luigi
Hi Luigi,
Thanks for the quick response. May I know what are the difference between the Bonsai structure and regular embedded pointers? Will there be any impact on performance and memory usage for using the regular pointers? Will the update, traverse operations be slower?
Thanks
Hi @holocentric-bmsnext
With Embedded Ridbags, all the edge RIDs are stored in the vertex record.
With SBTreeBonsai Ridbags, edge rids are stored in a tree structure, that is saved on a separate file (*.sbc files) and the vertex just contains a pointer to that structure.
Advantages and disadvantages:
- the embedded structure is a bit smaller in terms of disk usage.
- the Bonsai structure allows concurrent updates (ie. no ConcurrentModificationException when adding edges in concurrently, the version number of the vertex record is not updated when you add an edge), while the emdedded structure follows the normal optimistic locking mechanisms used when you update records
- the embedded structure makes vertices bigger, so when you fetch a vertex to the client you also fetch all the edge RIDs (for the edges connected to that specific vertex of course)
- the traverse performance is definitely comparable
Thanks
Luigi