避免某些遍历

Question

I have a database of about 10M nodes. 9.9M of those nodes are details that are not used in 99% of the queries but still required for 1% of the queries. For the 99% of queries out there, how do I tell the graph database to not go traversing down a specific node no matter what in queries where the path may be a whildcard?

Apologies for adding tags to three graph databases, I'm still evaluating which graph db is the right one for us to use.

Answer 1

When working with Neo4j you can use labels to group nodes into sets. Examples of labels are :User , Product , Admin , etc. Also, relationships between nodes can be typed.

These constructs can be used at query time to tell the database which nodes labels / relationship types should be used.

Examples:

1 - Return only nodes with specific node label ( :User ):

MATCH (u:User)
RETURN u

2 - Return nodes with :User label and not Administrator label (since nodes can have more than one label):

MATCH (u:User)
WHERE NOT u:Administrator
RETURN u

3 - Match the pattern between an :User and a :Product following only relationships with type :BUY from an user to a product where u.id = 10 and not considering users that are :Administrator s to. Return the user and the related product.

MATCH (u:User)-[:BUY]->(p:Product)
WHERE u.id = 10 AND NOT u:Administrator
RETURN u, p

Answer 2

With OrientDB you can use class hierarchies, inheritance and polymorphic queries, eg. you can have two classes, say "Class1" (relevant) and "Class2" (details) that both share a superclass, say "SuperClass".

Then you can execute queries on the subclasses, if you only need relevant records:

 MATCH
    {class:Class1, as:p1} -TheEdgeClass-> {class:Class1, as:p2, while:($depth < 10)}
 RETURN $elements

or on the superclass, if you need both relevant and details:

 MATCH
    {class:SuperClass, as:p1} -TheEdgeClass-> {class:SuperClass, as:p2, while:($depth < 10)}
 RETURN $elements

The second query is polymorphic, that means that it returns both records of "Class1" and "Class2", because they both extend "Superclass".

The exact same applies to edge classes, so you can have class hierarchies for edges and use polymorphism also to choose which relationships you need to traverse.

Of course there are other strategies, eg. you can add a WHERE condition to the patterns and filter based on attributes, but you will lose the advantage of data locality (records of different classes are stored in different files, so when you query based on a single class you have more chances to have hot cache and less disk access).

Also consider that class hierarchies can be multiple levels deep (an actual tree of classes)