2016-09-21 21 views
6

Trong biểu đồ ArangoDB của tôi, tôi có chủ đề, chuỗi thư được liên kết với chủ đề đó và thư bên trong các chuỗi thư đó. Tôi muốn duyệt qua biểu đồ theo cách mà tôi trả về dữ liệu liên quan đến chuỗi tin nhắn cũng như số lượng tin nhắn bên trong chuỗi tin nhắn.ArangoDB: Tổng hợp số lượng thông qua biểu đồ traversal

Dữ liệu được cấu trúc khá đơn giản: Tôi có nút chủ đề, cạnh mở rộng đến nút chuỗi có ngày và danh mục được liên kết và cạnh từ nút chuỗi đến nút thông báo.

Tôi muốn trả lại dữ liệu được lưu trữ trong nút chuỗi và số lượng tin nhắn được đính kèm vào chuỗi.

Tôi không chắc chắn cách thực hiện điều này với cú pháp for v, e, p in 1..2 outbound. Tôi có nên làm for v, e, p in outbound với biểu đồ lồng nhau bên trong nó không? Đó có phải là người biểu diễn không?

Trả lời

7

Xin lỗi vì sự chậm trễ, chúng tôi đang nỗ lực trên 3.1 phát hành;)

Tôi nghĩ rằng bạn đã ở giải pháp đúng: Nó không phải là dễ dàng thể hiện những gì bạn muốn đạt được trong một tuyên bố 1..2 OUTBOUND . Cách dễ dàng hơn để xây dựng trong hai câu lệnh 1..1 OUTBOUND.

Từ lời giải thích của bạn tôi nghĩ rằng các truy vấn sau đây là những gì bạn sẽ sử dụng:

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 
    } 

Đối với một số lời giải thích: tôi lần đầu tiên chọn các chủ đề liên quan. Tiếp theo, tôi thực hiện truy vấn phụ để chỉ đơn giản là có thể gửi tin nhắn cho một chuỗi. Cuối cùng tôi trả lại thông tin tôi cần.

Về mặt hiệu suất: Về mặt truy cập dữ liệu (rất có thể là hoạt động "nút cổ chai"), không có sự khác biệt trong FOR x IN 1..2 OUTBOUND [...]FOR x IN 1 OUTBOUND [...] FOR y IN 1 OUTBOUND x [...] cả hai đều phải xem chính xác cùng một tài liệu. Tối ưu hóa truy vấn có thể chậm hơn một chút trong trường hợp sau, nhưng sự khác biệt là cách dưới 1ms.

+0

Điều này có hiệu quả những gì nhóm của tôi đã và đang làm. Ngay bây giờ, các kết hợp này mất khoảng 5 giây mỗi lần, mặc dù khi sáu được chạy cùng một lúc, máy chủ chậm lại đáng kể và các truy vấn bắt đầu mất 30-40 giây. Điều này là cho khoảng 60 chủ đề với lên đến 70.000 tin nhắn. Có lẽ khi chúng tôi đi đến một cụm, chúng tôi sẽ thấy điều này quay trở lại khoảng 5 giây, nhưng chúng tôi thực sự muốn làm cho nó nhanh hơn. –

+0

Ok hiểu;) Có thể bạn có thể cung cấp cho chúng tôi một số tập dữ liệu ẩn danh để chúng tôi có thể cố gắng tối ưu hóa những gì đang diễn ra? Đối với chúng tôi, dữ liệu "thực sự" luôn dễ dàng hơn nếu chúng tôi tạo ra. Chúng tôi sẵn sàng ký một NDA cho điều đó (tôi không được thông báo chi tiết với tất cả các thông tin liên lạc đang diễn ra, vì vậy nếu chúng tôi đã có một tập dữ liệu từ bạn, tôi sẽ nắm lấy nó và truy vấn nhanh hơn) Tôi cũng không hài lòng với mọi thứ trên 1 giây. – mchacki

+0

Nhóm của tôi đang làm việc để thiết lập điều đó! –

Các vấn đề liên quan