ArangoDB: Mengumpulkan jumlah melalui traversal grafik

Dalam grafik ArangoDB saya, saya memiliki subjek, rangkaian pesan yang terkait dengan subjek tersebut, dan pesan di dalam rangkaian pesan tersebut. Saya ingin melintasi grafik sedemikian rupa sehingga saya mengembalikan data yang terkait dengan utas pesan serta jumlah pesan di dalam utas pesan.

Struktur datanya cukup sederhana: Saya memiliki simpul subjek, tepi yang meluas ke simpul utas dengan tanggal dan kategori terkait, dan tepi dari simpul utas ke simpul pesan.

Saya ingin mengembalikan data yang disimpan di simpul utas dan jumlah pesan yang dilampirkan ke utas.

Saya tidak yakin bagaimana melakukan ini dengan sintaks for v, e, p in 1..2 outbound. Haruskah saya melakukan for v, e, p in outbound dengan grafik bersarang di dalamnya? Apakah itu masih berkinerja?


traversal graph-databases aql arangodb
person Nate Gardner    schedule 21.09.2016    source sumber

Jawaban (1)


arrow_upward
7
arrow_downward

Maaf atas keterlambatannya, kami sedang bekerja keras pada rilis 3.1 ;)

Saya rasa Anda sudah mendapatkan solusi yang tepat: Tidak mudah untuk mengungkapkan apa yang ingin Anda capai dalam pernyataan 1..2 OUTBOUND. Jauh lebih mudah untuk merumuskannya dalam dua pernyataan 1..1 OUTBOUND.

Dari penjelasan Anda, saya pikir pertanyaan berikut adalah apa yang akan Anda gunakan:

FOR thread IN 1 OUTBOUND @start @@threadEdges
  LET nr = COUNT(FOR message IN 1 OUTBOUND thread @@messageEdges RETURN 1)
  RETURN {
    date: thread.date,
    category: thread.category,
    messages: nr
  }

Untuk beberapa penjelasan: pertama-tama saya memilih utas terkait. Selanjutnya saya melakukan subquery untuk sekadar mengirim pesan untuk satu utas. Akhirnya saya mengembalikan informasi yang saya butuhkan.

Dalam hal kinerja: Dalam hal akses data (yang kemungkinan besar merupakan operasi "hambatan") tidak ada perbedaan dalam FOR x IN 1..2 OUTBOUND [...] dan FOR x IN 1 OUTBOUND [...] FOR y IN 1 OUTBOUND x [...] keduanya harus melihat dokumen yang persis sama. Pengoptimalan kueri mungkin sedikit lebih lambat pada kasus selanjutnya, namun perbedaannya jauh di bawah 1ms.

person mchacki    schedule 21.10.2016
comment
Ini secara efektif adalah apa yang telah dilakukan tim saya. Saat ini, agregasi ini masing-masing membutuhkan waktu sekitar 5 detik, meskipun ketika enam agregasi dijalankan sekaligus, server melambat secara signifikan dan kueri mulai memakan waktu 30-40 detik. Ini untuk sekitar 60 rangkaian pesan dengan hingga 70.000 pesan. Agaknya ketika kita pergi ke sebuah cluster, kita akan melihat ini kembali ke sekitar 5 detik, tapi kami benar-benar ingin mendapatkannya lebih cepat. - person Nate Gardner; 28.10.2016
comment
Oke, mengerti ;) Mungkinkah Anda memberi kami kumpulan data anonim sehingga kami dapat mencoba mengoptimalkan apa yang sedang terjadi? Bagi kami, menggunakan kumpulan data nyata selalu lebih mudah dibandingkan jika kami membuatnya. Kami bersedia menandatangani NDA untuk itu (saya tidak diberitahu secara rinci tentang semua komunikasi yang terjadi, jadi jika kami sudah mendapatkan kumpulan data tersebut dari Anda, saya akan mengambilnya dan menjawab pertanyaan Anda lebih cepat) Saya juga tidak senang dengan semuanya di atas 1s. - person mchacki; 29.10.2016