So sánh DAG hiệu quả qua mạng


11

Trong các hệ thống kiểm soát phiên bản phân tán (như MercurialGit ), cần phải so sánh hiệu quả các đồ thị chu kỳ có hướng (DAG). Tôi là một nhà phát triển Mercurial và chúng tôi sẽ rất thích nghe về công việc lý thuyết thảo luận về sự phức tạp về thời gian và mạng lưới của việc so sánh hai DAG.

Các DAG trong câu hỏi được hình thành bởi các phiên bản được ghi lại. Các sửa đổi được xác định duy nhất bởi một giá trị băm. Mỗi phiên bản phụ thuộc vào số không (cam kết ban đầu), một (cam kết bình thường) trở lên (cam kết hợp nhất) của các phiên bản trước. Dưới đây là một ví dụ trong đó sửa đổi ađể eđược thực hiện lần lượt nhau:

a --- b --- c --- d --- e

So sánh biểu đồ đi vào hình ảnh khi ai đó chỉ có một phần của lịch sử và muốn lấy lại phần còn thiếu. Hãy tưởng tượng tôi đã ađến cvà làm xydựa trên c:

a --- b --- c --- x --- y

Trong Mercurial, tôi sẽ làm hg pullvà tải xuống de:

a --- b --- c --- x --- y
              \
                d --- e

Mục tiêu là xác định dehiệu quả khi biểu đồ có nhiều nút (giả sử, hơn 100.000). Hiệu quả liên quan đến cả

  • độ phức tạp của mạng: số byte được truyền và số lượng chuyến đi khứ hồi mạng cần thiết
  • độ phức tạp thời gian: số lượng tính toán được thực hiện bởi hai máy chủ trao đổi thay đổi

Các biểu đồ điển hình sẽ được thu hẹp với một vài rãnh song song như trên. Thông thường cũng sẽ chỉ có một số ít các nút lá (chúng tôi gọi chúng là các đầu trong Mercurial) như thế eyở trên. Cuối cùng, khi một máy chủ trung tâm được sử dụng, máy khách thường sẽ có một vài thay đổi không có trên máy chủ, trong khi máy chủ có thể có hơn 100 thay đổi mới cho các máy khách, tùy thuộc vào việc máy khách được kéo từ máy chủ từ lâu . Một giải pháp bất đối xứng được ưa thích: một máy chủ tập trung nên thực hiện ít tính toán so với các máy khách của nó.


Cuộc thảo luận đã tiếp tục một chút trên Google Plus .
Martin Geisler

Câu trả lời:


13

Trong ngữ cảnh này, các nút biểu đồ có một số loại định danh duy nhất (hàm băm hoặc tổng kiểm tra), phải không? Vì vậy, bạn không cần thực hiện bất kỳ loại thử nghiệm đẳng cấu đồ thị con nào, bạn chỉ cần một danh sách các nút khác nhau giữa hai phiên bản của bạn và các cạnh không thực sự hữu ích cho bước này. Bài viết SIGCOMM 2011 của tôi " Sự khác biệt là gì? Đặt hòa giải hiệu quả mà không cần bối cảnh trước"(với Goodrich, Uyeda và Varghese) xem xét chính xác vấn đề này: hóa ra bạn có thể xác định danh tính của các nút được giữ bởi một nhưng không phải cả hai máy chủ giao tiếp, sử dụng một lượng giao tiếp chỉ tỷ lệ thuận đến số lượng nút thay đổi và chỉ sử dụng một chuyến đi khứ hồi. Một khi bạn có thông tin đó, thật dễ dàng để tự thay đổi các chuyến đi trong chuyến đi khứ hồi thứ hai, một lần nữa với giao tiếp tối ưu.


Uh, điều này nghe có vẻ thú vị! Bạn đúng khi so sánh trực tiếp ID thay đổi (vâng, chúng là giá trị băm) sẽ hoạt động. Chúng tôi cũng luôn cố gắng sử dụng cấu trúc biểu đồ: nếu cả hai chúng tôi đều biết X, thì tôi cũng biết rằng bạn biết tất cả tổ tiên của X. Đó có vẻ như là thông tin quan trọng, nhưng có lẽ không phải vậy. Tôi sẽ đọc bài viết của bạn bây giờ, cảm ơn con trỏ!
Martin Geisler

@David: Một độ chính xác (Tôi là một trong những tác giả của thuật toán hiện đang được Mercurial sử dụng). Chúng tôi thực sự quan tâm đến tập hợp các nút "chung", không cần biết giá trị của nút bị thiếu.
tonfa

1
Nếu bạn biết những gì khác nhau, thì bạn cũng biết những điểm chung: đó là tất cả mọi thứ bạn có một bản sao không phải là một phần của sự khác biệt. Nhưng sự khác biệt thường tương đối nhỏ ngay cả khi phần chung lớn, do đó, chỉ truyền một lượng dữ liệu tỷ lệ với chênh lệch sẽ tốt hơn so với truyền toàn bộ lịch sử DAG hoặc phần chung.
David Eppstein

@David: vì mối quan hệ tổ tiên, chúng tôi thực sự tính toán các đầu (nút lá) của khu vực chung. Vì vậy, đó vẫn là một lượng nhỏ dữ liệu, ngay cả khi có một lịch sử chia sẻ khổng lồ.
Martin Geisler

Tôi đã cập nhật câu trả lời của mình để bao gồm cả số chuyến đi khứ hồi được sử dụng (hóa ra là rất nhỏ).
David Eppstein

3

Trong giải pháp chúng tôi triển khai cho Mercurial, một mối quan tâm khác là sự bất cân xứng: tải của máy chủ nên được giảm thiểu cho cả băng thông đi và thời gian CPU, với chi phí tải của khách hàng.


1
Cảm ơn, tôi đã cập nhật câu hỏi một chút để lưu ý điều này.
Martin Geisler

0

Âm thanh như một quá trình hai bước với tôi.

  1. hỏi tất cả khách hàng nếu họ có cam kết nơi cha mẹ là c
  2. nếu vậy, tìm tất cả con của c

Nhiệm vụ của 1. Tôi nghĩ chủ yếu được xử lý ở phía máy khách và tất cả các máy khách đều cần hàm băm cam kết qua mạng.


Kịch bản nào bạn đang mô tả? Các trường hợp tôi đã thực hiện xyvà cần phải kéo edtừ máy chủ? Vấn đề ban đầu là tôi (với tư cách là khách hàng) không biết "điểm nhánh" c.
Martin Geisler
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.