Wie ArangoDB Foxx Deadlocking Probleme lösen?

Question

Unter Tests gerät unsere Foxx-App in "Deadlock-Erkennung" -Probleme. Diese scheinen durch Traversalabfragen verursacht zu sein. Apriori, es ist schwierig, wenn nicht unmöglich zu wissen, welche Tabellen während des Traversierens verwendet werden. Allerdings habe ich einen speziellen Fall genommen, bei dem ich die Anzahl der Tabellen ermitteln und die AQL in eine Transaktion zum Testen einbinden konnte:

var result = db._executeTransaction ({"Sammlungen": {"read": ["pmlibrary "," pmvartype "," pmvariant "," pmproject "," pmsite "," pmpath "," pmattic "]}," action ":" funktion() {var db = require (\ "@ arangodb \"). db; var res = db._query ("FOR o IN ['pmlibrary/199340787']] FÜR v, e, p IN 0..7 INBOUND o pm_child RETURN p.vertices \"; return res.toArray()} "});

FYI, die Liste der Tabellen in den Sammlungen enthält keine Kantentabellen.

Die Deadlocks in dieser Anweisung werden jedoch fortgesetzt. Ich bin mir nicht sicher, was ich als nächstes versuchen soll. Vielen Dank.

Answer 1

Die richtige Lösung bestand darin, eine WITH-Klausel anstelle einer Transaktion zu verwenden.

Answer 2

Ich bin kein Indexing/Performance-Experte mit ArangoDB, aber ich hatte vor kurzem einige Probleme mit Deadlocking und durch Rekonstruieren und Umformen der Abfragen hatte enorme Leistungsgewinne, manchmal dauerte Abfragen 120 Sekunden dauerte dann 0,2 Sekunden.

Eine wichtige Sache, die ich tat, war zu versuchen, ArangoDB zu helfen, wann man einen Index benutzt, und sicherzustellen, dass der Index dort benutzt werden soll.

In Ihrem Beispiel Abfrage, gibt es ein Problem, das ArangoDB aus dem Wissen, einen Index hält auftritt:

FOR o IN ['pmlibrary/199340787'] 
FOR v,e,p IN 0..7 INBOUND o pm_child 
    RETURN p.vertices 

Die zentrale Frage dabei ist, dass Sie Ihre Original-FOR-Schleife einen Wert aus einem Array verwendet, die kann ArangoDB daran hindern, einen Index zu identifizieren. Sie können Ihr O leicht durch einen Parameter ersetzen und Ihren 'pmlibrary/199340787' Wert direkt eingeben und mit der Erklärungsschaltfläche sehen, ob es einen Index verwenden kann.

Ein Problem, das ich fand, war es, super klar zu machen, einen Index zu verwenden, der manchmal zusätzliche Befehle bedeutete, ArangoDB zu ermöglichen, den Inhalt von Arrays zu erstellen, und dann scheint es zu wissen, welchen Index besser zu verwenden.

Wenn Sie waren die Leistung der Abfrage oben zu testen, im Vergleich zu so etwas wie:

LET my_targets = (FOR o IN pmlibrary FILTER o._key == '199340787' RETURN o._id) 

FOR o IN my_targets 
FOR v,e,p IN 0..7 INBOUND o._id pm_child 
    RETURN p.vertices 

Es kann unlogisch erscheinen, aber mit Test ich erstaunliche Leistungssteigerungen gefunden durch Abfragen auseinander brechen ArangoDB merkt es zu helfen könnte einen Index verwenden.

Wenn Abfragen die Werte innerhalb von Arrays betreffen oder wenn Sie dynamische Attributnamen verwenden, wird nicht immer ein Index verwendet, auch wenn ein solcher existiert.

Auch ich fand, dass der Server Antwort für Abfragen Cache, also, wenn Sie Änderungen an einer lang laufenden Abfrage testen wollen und Cache-Treffer auf Ihre zweite + Abfragen zu vermeiden, musste ich den arangodb3-Dienst stoppen und neu starten.

Ich hoffe, dass hilft Ihnen, ein Ziel für das Shuffling um Ihre Abfrage mit Indizes zu arbeiten.

Denken Sie daran, dass Sie bereits eingebaute Indizes für _id, _key, _from, _to haben. Sie müssen also versuchen, sicherzustellen, dass andere Indizes verwendet werden, die Ihre Abfrage beschleunigen können.