Performances DB Arango: edge par rapport à DOCUMENT()

Question

Je suis nouveau sur arangoDB avec des graphiques. Je veux simplement savoir s'il est plus rapide de construire des bords ou d'utiliser 'DOCUMENT()' pour des connexions 1: 1 très simples où une requête sur le graphe n'est pas nécessaire?

LET a = DOCUMENT(@from) 
FOR v IN OUTBOUND a 
CollectionAHasCollectionB 
RETURN MERGE(a,{b:v}) 

vs

LET a = DOCUMENT(@from) 
RETURN MERGE(a,{b:DOCUMENT(a.bId)} 

Answer 1

Une référence simple, vous pouvez essayer:

Créer les collections products, categories et une collection bord has_category. Ensuite, générer des données d'échantillon:

FOR i IN 1..10000 
    INSERT {_key: TO_STRING(i), name: CONCAT("Product ", i)} INTO products 

FOR i IN 1..10000 
    INSERT {_key: TO_STRING(i), name: CONCAT("Category ", i)} INTO categories 

FOR p IN products 
    LET random_categories = (
    FOR c IN categories 
     SORT RAND() 
     LIMIT 5 
     RETURN c._id 
    ) 
    LET category_subset = SLICE(random_categories, 0, RAND()*5+1) 

    UPDATE p WITH { 
     categories: category_subset, 
     categoriesEmbedded: DOCUMENT(category_subset)[*].name 
    } INTO products 

    FOR cat IN category_subset 
     INSERT {_from: p._id, _to: cat} INTO has_category 

Ensuite, comparez les temps de requête pour les différentes approches.

Graphique traversal (profondeur 1..1):

FOR p IN products 
    RETURN { 
     product: p.name, 
     categories: (FOR v IN OUTBOUND p has_category RETURN v.name) 
    } 

Look-up dans la collecte des catégories à l'aide DOCUMENT():

FOR p IN products 
    RETURN { 
     product: p.name, 
     categories: DOCUMENT(p.categories)[*].name 
    } 

En utilisant les noms des catégories directement intégrés:

FOR p IN products 
    RETURN { 
     product: p.name, 
     categories: p.categoriesEmbedded 
    } 

La traversée de graphe est la plus lente de toutes les 3, la recherche dans une autre collection est plus rapide que la traversée, mais par La requête la plus rapide est celle avec des noms de catégories incorporés. Cependant, si vous interrogez les catégories pour un ou plusieurs produits, les temps de réponse doivent être dans la zone inférieure à la milliseconde, quel que soit le modèle de données et l'approche de la requête, et ne posent donc aucun problème de performances.

L'approche graphique doit être choisie si vous avez besoin de rechercher des chemins avec une profondeur variable, des chemins longs, le chemin le plus court, etc. Pour votre cas d'utilisation, ce n'est pas nécessaire. Que ce soit l'approche intégrée convient ou non est quelque chose que vous devez décider:

• Est-il acceptable de dupliquer des informations, et potentiellement des incohérences dans les données?(Si vous souhaitez modifier le nom de la catégorie, vous devez le modifier dans tous les enregistrements de produit au lieu d'un seul document de catégorie auquel les produits peuvent se référer via l'ID immuable)

• Y at-il beaucoup d'informations supplémentaires par catégorie? ? Si oui, toutes ces données doivent être intégrées dans chaque document de produit qui a cette catégorie - essentiellement la mémoire de négociation/espace de stockage pour la performance

• Avez-vous besoin de récupérer une liste de toutes les catégories (distinctes) souvent? Vous pouvez faire ce type de requête vraiment pas cher avec la collection de catégories distinctes. Avec l'approche intégrée, il sera beaucoup moins efficace, car vous devez parcourir tous les produits et collecter les informations sur la catégorie.

Conclusion: choisissez le modèle de données et l'approche qui conviennent le mieux à votre cas d'utilisation. Grâce à la nature multimodèle d'ArangoDB, vous pouvez facilement essayer une autre approche si votre cas d'utilisation change ou si vous rencontrez des problèmes de performance.

Answer 2

Généralement parlé, cette dernière variante

LET a = DOCUMENT(@from) 
RETURN MERGE(a,{b:DOCUMENT(a.bId)} 

devraient avoir en tête inférieure à la variante traversal complet. C'est parce que la variante DOCUMENT fera une recherche de point d'un document alors que la variante de traversée est très générale: elle peut renvoyer zéro à plusieurs résultats d'un nombre variable de collections, doit garder la trace du chemin vu etc

Lorsque j'ai essayé les deux variantes dans un scénario de test local, la variante sans traversée était également beaucoup plus rapide, ce qui confirme cette affirmation.

Cependant, la variante basée sur la traversée est plus flexible: elle peut également être utilisée s'il y a plusieurs bords (pas de mappage 1: 1) et pour des chemins plus longs.