Change Password

Please enter the password.
Please enter the password. Between 8-64 characters. Not identical to your email address. Contain at least 3 of: uppercase, lowercase, numbers, and special characters.
Please enter the password.
Submit

Change Nickname

Current Nickname:
Submit

Apply New License

License Detail

Please complete this required field.

  • Ultipa Graph V4

Standalone

Please complete this required field.

Please complete this required field.

The MAC address of the server you want to deploy.

Please complete this required field.

Please complete this required field.

Cancel
Apply
ID
Product
Status
Cores
Applied Validity Period(days)
Effective Date
Excpired Date
Mac Address
Apply Comment
Review Comment
Close
Profile
  • Full Name:
  • Phone:
  • Company:
  • Company Email:
  • Country:
  • Language:
Change Password
Apply

You have no license application record.

Apply
Certificate Issued at Valid until Serial No. File
Serial No. Valid until File

Not having one? Apply now! >>>

Product Created On ID Amount (USD) Invoice
Product Created On ID Amount (USD) Invoice

No Invoice

v4.5
Search
    Français
    v4.5

      UQL Query

      Cette page démontre plusieurs types de requêtes graphiques sur la façon dont elles sont composées en UQL et à quoi ressemble le résultat de la requête dans Ultipa Manager.

      GraphSet utilisé dans cet article :

      Pour ceux qui n'ont pas d'environnement serveur Ultipa :

      • Cliquez sur le bouton 'Exécuter' en haut de chaque boîte de code pour vérifier le résultat de la requête
      • Ou 'Copiez' le code et exécutez-le dans Ultipa Playground contre le graph 'Démarrage Rapide'

      Requêtes de Base

      Requête de Node

      La requête pour les nodes est comparable à la requête de table dans les bases de données relationnelles. Essayez de comprendre le UQL ci-dessous :

      find().nodes() as myFirstQuery
      return myFirstQuery{*} limit 10
      

      Sa signification littérale est 'trouver des nodes et les nommer comme myFirstQuery, revenir myFirstQuery, en limitez 10', ce qui est assez proche s'il est ajouté avec quelques explications :

      • L'instruction de chaîne find().nodes() initie une requête de node
      • Alias myFirstQuery défini pour le résultat de cette requête de node est appelé par une instruction ultérieure return
      • Le symbole {*} suivant l'alias de node porte toutes les propriétés du node

      L'objectif de l'UQL ci-dessus est 'trouver 10 différents nodes et retourner toutes leurs propriétés'. Exécutez cet UQL dans Ultipa Manager :

      Le fait que myFirstQuery sont tous des nodes du schema @customer est une coïncidence, ou plus précisément, dépend de la séquence d'insertion des nodes et du comportement de calcul concurrent.

      Pour interroger des nodes d'un schema spécifique, comme merchant par exemple, décrivez dans nodes() comme ci-dessous :

      find().nodes({@merchant}) as mySecondQuery
      return mySecondQuery{*} limit 10
      

      Ci-dessous se trouve le résultat d'exécution de cet UQL :

      Requête d'Edge

      Dans le modèle de graph actuel, des edges de @transfer existent à partir de nodes de @customer vers des nodes de @merchant :

      La requête pour les edges est assez similaire à celle pour les nodes, mais utilise edges() pour contenir la condition de filtrage des edges :

      find().edges({_from == "60017791850"}) as payment
      return payment{*} limit 10
      

      Les payment sont 10 différents edges du client Chen** (ID: 60017791850) vers d'autres nodes, le _to de payment sont les IDs des marchands qui reçoivent ces paiements. Combinez cette requête d'edge avec une requête de node qui appelle les IDs de ces marchands :

      find().edges({_from == "60017791850"}) as payment
      find().nodes({_id == payment._to}) as merchant
      return merchant{*} limit 10
      
      • Le ._id suivant l'alias de node appelle la propriété _id du node

      Le UQL ci-dessus renvoie toutes les propriétés de ces 10 marchands qui reçoivent des transactions de Chen** (ID: 60017791850) :

      Des valeurs répétées apparaissent dans le résultat, qui sont des marchands avec _uuid '117' et '119' qui apparaissent chacun deux fois, car chacun reçoit deux transactions de Chen**.

      Ceci est un scénario typique de multi-graph, dans lequel plus d'un edge existe entre deux nodes. La vue 2D dans Ultipa Manager peut mieux afficher ce type de scénario.

      Spread

      spread().src({_id == "60017791850"}).depth(1) as transaction
      return transaction{*} limit 10
      

      Sa signification littérale : étendre à partir d'une source dont l'ID est 60017791850, à une profondeur de 1, retourner toutes les propriétés de 10 enregistrements tels.

      • La commande spread() initie une requête pour les edges à partir d'un node central src(), de manière BFS
      • Le paramètre depth() définit la profondeur maximale que la recherche BFS parcourt
      • L'alias transaction représente les chemins d'un pas des edges trouvés, à savoir le 'node de début, edge, node de fin'
      • Le symbole {*} suivant l'alias de chemin porte toutes les propriétés des nodes et edges du chemin

      L'objectif de l'UQL ci-dessus est 'trouver 10 différents edges du client Chen** vers les marchands et retourner toutes les propriétés de Chen**, edges et marchands' :

      Le résultat de la requête des chemins est automatiquement visualisé en vue 2D dans Ultipa Manager, où les multiples transactions entre Chen** et les deux marchands '117' et '119' sont intuitivement observées.

      Pour obtenir un nombre exact de marchands distincts de fin de node via la requête spread(), une opération de déduplication peut être impliquée avant de retourner le résultat final. Une autre option est d'utiliser une différente commande de requête qui, par conception, recherche de manière BFS mais renvoie des nodes.

      K-Hop

      khop().src({_id == "60017791850"}).depth(1) as merchant
      return merchant{*} limit 10
      

      Sa signification littérale : sauter K fois à partir d'une source dont l'ID est 60017791850, à une profondeur de 1, retourner toutes les propriétés de 10 enregistrements tels.

      • La commande khop() initie une requête pour les nodes depuis un node central src(), de manière BFS
      • L'alias merchant représente les nodes

      L'objectif de l'UQL ci-dessus est 'trouver 10 différents marchands qui reçoivent des paiements de Chen** et retourner toutes les propriétés de ces marchands:

      Deux marchands supplémentaires '110' et '118' sont trouvés par khop(), en plus de ces 8 marchands trouvés par spread().

      Penser en "Template"

      La requête modèle est un type avancé de requête graph en décrivant avec précision chaque node et edge dans un chemin. Elle utilise les paramètres n(), e() et nf() mentionnés dans Données Graphiques.

      Chaînes

      n({_id == "60017791850"}).e().n() as transaction
      return transaction{*} limit 10
      

      Sa signification littérale : trouver des chemins d'un pas à partir du node dont l'ID est 60017791850 et renvoyer toutes les informations de 10 tels chemins :

      Cela atteint le même résultat que la requête précédente utilisant spread(), car les deux requêtes recherchent des chemins d'un pas à partir du client Chen**.

      Considérons maintenant un chemin qui commence à partir de Chen** et atteint un marchand via 3 edges, tous les edges doivent avoir un montant de transaction supérieur à 70000 :

      n({_id == "60017791850"}).e({tran_amount > 70000})[3].n() as transChain
      return transChain{*} limit 10
      
      • Le symbole [3] suivant e() indique le nombre d'edges dans le chemin (même objectif que depth())
      Cercle vert : node initial Chen** ; cercles bleus : nodes terminaux (marchands)

      Ces 10 chemins divergent à partir du 2ème node dans chacun le leur, le marchand '111', en 3 branches, et divergent plus loin de ces trois clients Zheng**, Qian** et Chu** en 10 branches, qui atteignent finalement 8 différents marchands.

      Si les comportements d'achat de Chen**, Zheng**, Qian** et Chu**, ceux qui achètent tous des produits du marchand '111', sont considérés comme similaires, alors il est raisonnable de recommander certains de ces 8 marchands au node terminal au client Chen**, ce qui est un scénario typique de recommandation de produits et de marchands.

      La vue 2D d'Ultipa Manager ne re-rend pas le même node ou edge pour un chemin différent. Quand tous les 10 chemins commencent par Chen**, passent l'edge '60' et atteignent le marchand '111', ces 3 métadonnées sont partagées dans la vue 2D. Une vue de liste montrera clairement toutes les métadonnées de chaque chemin :

      Cercles

      Les edges dans un chemin ne se répètent jamais, mais les nodes le font parfois, ce qui induit des cercles dans le chemin.

      n({@customer} as start).e({tran_date > "2020-1-1 0:0:0"})[4].n(start) as transRing
      return transRing{*} limit 10
      
      • Le dernier n() appelle l'alias start défini dans le premier n(), donc le node initial et le node terminal du chemin deviennent le même node

      L'objectif de l'UQL ci-dessus est 'trouver 10 chemins à quatre étapes commençant par un node @customer et revenant à ce node à la fin, où chaque transaction a lieu après 2020-1-1 0:0:0, retourner toutes les propriétés des nodes et edges dans ces chemins' :

      La vue liste du résultat de la requête :

      Dans ces cercles à quatre étapes, les clients Chu** et Ou** achètent des produits des marchands '110' et '108', cela fournit des preuves de certaines similitudes entre ces deux clients.

      Chemins les Plus Courts

      n({_id == "60017791850"}).e()[:5].n(115) as transRange
      return transRange{*} limit 1
      
      • La valeur :5 dans la parenthèse peut également être écrite 1:5, ce qui spécifie une plage flexible de longueur de chemin au lieu d'un nombre fixe
      • Le nombre '115' dans le dernier n() est un format abrégé de {_uuid == 115}

      L'objectif de l'UQL ci-dessus est 'trouver un chemin de Chen** au node dont l'UUID est 115, avec une longueur ne dépassant pas 5, retourner toutes les propriétés des nodes et des edges du chemin' :

      Par hasard, le chemin trouvé a exactement 5 edges.

      Une légère révision apportée à la longueur du chemin pourrait complètement changer la cible de requête de l'UQL :

      n({_id == "60017791850"}).e()[*:5].n(115) as transShortest
      return transShortest{*} limit 1
      
      • En ajoutant une étoile *, la valeur *:5 transforme le modèle en un chemin le plus court avec une longueur ne dépassant pas 5

      L'objectif de l'UQL ci-dessus est 'trouver un chemin le plus court de Chen** au node dont l'UUID est 115, avec une longueur ne dépassant pas 5, retourner toutes les propriétés des nodes et des edges du chemin' :

      Le chemin le plus court suggère la connexion la plus directe entre deux nodes. En général, plus le chemin est court, plus sa connectivité est grande, et plus il est intéressant à analyser. Pour cette raison, les entités du monde réel cachent parfois intentionnellement leurs connexions à une distance excessivement longue (20~30 étapes) d'une autre entité. Pour découvrir ces entités suspectes, une DBMS à haute performance avec capacité HTAP, ultra-profonde de traversée de graph, et une réactivité exceptionnelle est nécessaire.

      Calculs Communs

      L'UQL peut effectuer une variété de calculs après avoir trouvé des nodes, edges et chemins, via des fonctions et des clauses. Cette section présente certains des plus fréquemment utilisés, veuillez vous référer au manuel UQL pour plus de détails.

      Dédupliquer

      Revisitez le premier exemple démontré dans la section Chaînes pour trouver ces 8 marchands distincts sur 10 au total :

      n({_id == "60017791850"}).e().n(as payee) limit 10
      with distinct payee as payeeDedup
      return payeeDedup{*}
      
      • L'opérateur distinct déduplique payee basé sur l'ID du node
      • L'opération de déduplication est composée dans with
      • L'instruction limit 10 est exécutée avant with, toutes les instructions UQL sont exécutées dans l'ordre où elles sont composées

      Compter

      Revisitez l'exemple précédent pour calculer le nombre de marchands distincts :

      n({_id == "60017791850"}).e().n(as payee) limit 10
      with count(distinct payee) as cardinality
      return cardinality
      
      • La fonction count() calcule le nombre de distinct payee, count() et distinct sont parfois utilisés conjointement

      Ordonner par

      Revisitez le premier exemple démontré dans la section Requête d'Edge pour retourner ces 10 edges en ordre décroissant de leur montant de transaction :

      find().edges({_from == "60017791850"}) as payment limit 10
      order by payment.tran_amount desc
      return payment{*}
      
      • Le mot-clé de clause order by trie payment par sa propriété tran_amount
      • Le mot-clé desc à la fin de la clause order by signifie trier par ordre décroissant

      Groupe par

      Revisitez le deuxième exemple démontré dans la section Chaînes pour regrouper ces chemins de 3 étapes par leur 3ème node, et compter le nombre de chemins dans chaque groupe :

      n({_id == "60017791850"}).e({tran_amount > 70000})[2].n(as third).e({tran_amount > 70000}).n() limit 10
      group by third
      return table(third.cust_name, count(third))
      
      • Pour exprimer le 3ème node dans le chemin, le modèle original n().e()[3].n() est transformé en n().e()[2].n().e().n()
      • Le mot-clé de clause group by divise third basé sur l'ID du node
      • La fonction count() est exécutée contre third dans chaque groupe
      • La fonction table() fusionne third.cust_name et count(third) dans une table pour les rendre plus pratiques à vérifier
      Please complete the following information to download this book
      *
      公司名称不能为空
      *
      公司邮箱必须填写
      *
      你的名字必须填写
      *
      你的电话必须填写