NoSQL database design: graph, documents, edges..?

Question

I am trying to design a NoSQL database for the first time and I am confused about some things.

I can create collections that contains documents and also collections that contains edges. On the other hand I can create graphs that connects documents through edges.

My idea was to connect the different collections through edges (I don't know if there are other ways for connecting different collections).

So I don't know if I should build my database as a graph or just as collections (of type document) and collections (of type edge).

The documents within my collections contains lots of objects and lists, and when I search for graphs database examples I usually see that Nodes within a graph contains just few information (such as name, adge, city), so I don't know then if creating a graph with complex documents is a good idea. I need the graph because I want to do a transversal such as friend of,friend of, friend of...

Answer 1

Finally I am using documents and edges without building graphs as I saw that ArangoDB let me do traversals without having any graph. See https://docs.arangodb.com/3.11/aql/graphs/traversals/#working-with-collection-sets

Answer 2

Speaking for ArangoDB as Multi model database - it does allow you to choose whatever suits your data model the best. ArangoDB and its AQL allows you to do joins over collections. Joins offer the best scalability to bigger quantities. Joins are ruled out if you have properties attached to the relations of two documents.

Choosing between inline attributes and attributes on secondary collections you join in after executing the graph query depends on your data amount in relation to the size of your machines. Graph algorithms perform better when run on a single server instance - thus limiting the amount of data in the graph is a valid concern. Otoh if you know that the graph will most probably not outgrow one machine joining in the data in after traversing the graph involves additional cost.

In ArangoDB edges are implemented as documents with predefined _from and _to attributes - so you can attach any document structure to it you like.

In the end the advantage of document stores is, that you can freely combine structured data that you often need combined.