การเปรียบเทียบ DAG ที่มีประสิทธิภาพผ่านเครือข่าย


11

ในระบบควบคุมเวอร์ชันแบบกระจาย (เช่นMercurialและGit ) มีความจำเป็นที่จะต้องเปรียบเทียบกราฟ acyclic (DAG) ที่มีประสิทธิภาพโดยตรง ฉันเป็นนักพัฒนา Mercurial และเราสนใจฟังเรื่องทฤษฎีที่พูดถึงเรื่องเวลาและความซับซ้อนของเครือข่ายในการเปรียบเทียบ DAG สองตัว

DAG ที่เป็นปัญหาจะเกิดขึ้นจากการแก้ไขที่บันทึกไว้ การแก้ไขจะถูกระบุโดยค่าแฮช แต่ละการแก้ไขขึ้นอยู่กับศูนย์ (การกระทำเริ่มต้น), หนึ่ง (การกระทำปกติ) หรือมากกว่า (รวมการกระทำ) ของการแก้ไขก่อนหน้านี้ นี่คือตัวอย่างที่การแก้ไขaจะeทำทีละอย่าง:

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

การเปรียบเทียบกราฟเข้ามาในรูปภาพเมื่อมีบางส่วนของประวัติและต้องการเรียกคืนส่วนที่ขาด ลองนึกภาพผมมีaที่จะcทำxและyขึ้นอยู่กับc:

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

ใน Mercurial ฉันจะทำhg pullและดาวน์โหลดdและe:

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

เป้าหมายคือการระบุdและeมีประสิทธิภาพเมื่อกราฟมีโหนดจำนวนมาก (พูดมากกว่า 100,000 โหนด) ประสิทธิภาพเกี่ยวข้องกับทั้งสองอย่าง

  • ความซับซ้อนของเครือข่าย:จำนวนไบต์ที่ถ่ายโอนและจำนวนเครือข่ายไปกลับที่จำเป็น
  • ความซับซ้อนของเวลา:จำนวนการคำนวณที่กระทำโดยเซิร์ฟเวอร์สองเครื่องที่แลกเปลี่ยนเซ็ตการแก้ไข

กราฟทั่วไปจะแคบลงพร้อมกับแทร็กขนานสองสามรายการดังกล่าว โดยทั่วไปจะมีเพียงโหนดโหนดหนึ่งกำมือเท่านั้น (เราเรียกว่าหัวเป็น Mercurial) เหมือนeและyเหนือ ท้ายที่สุดเมื่อมีการใช้เซิร์ฟเวอร์กลางลูกค้ามักจะมีชุดการเปลี่ยนแปลงสองชุดที่ไม่ได้อยู่บนเซิร์ฟเวอร์ในขณะที่เซิร์ฟเวอร์สามารถมีชุดการเปลี่ยนแปลงใหม่กว่า 100+ ชุดขึ้นอยู่กับผู้ใช้ที่ดึงลูกค้าจากเซิร์ฟเวอร์มานานแล้ว . วิธีการแก้ปัญหาที่ไม่สมมาตรเป็นที่ต้องการ: เซิร์ฟเวอร์ส่วนกลางควรทำคำนวณเล็ก ๆ น้อย ๆ ในการเปรียบเทียบกับลูกค้าของตน


การอภิปรายได้อย่างต่อเนื่องเล็ก ๆ น้อย ๆใน Google Plus
Martin Geisler

คำตอบ:


13

ในบริบทนี้โหนดกราฟมีตัวระบุเฉพาะ (แฮชหรือเช็คซัม) ใช่ไหม ดังนั้นคุณไม่จำเป็นต้องทำการทดสอบมอร์ฟอร์มอร์ฟิซึ่มชนิดใดเลยเพียงแค่ต้องการรายการของโหนดที่แตกต่างกันระหว่างสองเวอร์ชั่นของคุณและขอบไม่ได้มีประโยชน์เลยสำหรับขั้นตอนนี้ กระดาษ SIGCOMM 2011 ของฉัน " ความแตกต่างคืออะไรการกระทบยอดชุดที่มีประสิทธิภาพโดยไม่มีบริบทก่อน"(กับ Goodrich, Uyeda และ Varghese) พิจารณาปัญหานี้อย่างแน่ชัด: ปรากฎว่าคุณสามารถกำหนดตัวตนของโหนดที่ถูกครอบครองโดยหนึ่ง แต่ไม่ใช่ทั้งสองเซิร์ฟเวอร์สื่อสารโดยใช้ปริมาณการสื่อสารที่เป็นสัดส่วนเท่านั้น ถึงจำนวนของโหนดที่เปลี่ยนแปลงและใช้เพียงการไปกลับเดียวเมื่อคุณมีข้อมูลนั้นมันง่ายที่จะดึงการเปลี่ยนแปลงในรอบที่สองด้วยการสื่อสารที่ดีที่สุดอีกครั้ง


เอ่อสิ่งนี้ฟังดูน่าสนใจ! คุณถูกต้องที่การเปรียบเทียบโดยตรงของ ID การเปลี่ยนแปลง (ใช่พวกเขาคือค่าแฮช) จะใช้งานได้ เราแค่พยายามใช้โครงสร้างกราฟเช่นกัน: ถ้าเราทั้งคู่รู้จัก X ดังนั้นฉันก็รู้ว่าคุณรู้ว่าบรรพบุรุษของ X ทั้งหมดดูเหมือนว่าเป็นข้อมูลสำคัญ แต่อาจไม่ใช่ ฉันจะอ่านกระดาษของคุณตอนนี้ขอบคุณสำหรับตัวชี้!
Martin Geisler

@ David: ความแม่นยำ (ฉันเป็นหนึ่งในผู้เขียนอัลกอริทึมที่ Mercurial ใช้อยู่ในปัจจุบัน) เราสนใจเกี่ยวกับชุดของโหนด "ทั่วไป" ไม่จำเป็นต้องรู้คุณค่าของโหนดที่หายไป
tonfa

1
หากคุณรู้ว่ามีอะไรที่แตกต่างกันคุณก็รู้ว่ามีอะไรที่เหมือนกัน: มันคือทุกสิ่งที่คุณมีสำเนาที่ไม่ได้เป็นส่วนหนึ่งของความแตกต่าง แต่โดยทั่วไปแล้วความแตกต่างควรจะค่อนข้างเล็กแม้ว่าเมื่อส่วนทั่วไปมีขนาดใหญ่ดังนั้นการสื่อสารเพียงจำนวนข้อมูลที่ได้สัดส่วนกับความแตกต่างจึงดีกว่าการสื่อสารทั้งประวัติ DAG หรือส่วนทั่วไป
David Eppstein

@ David: เนื่องจากความสัมพันธ์ของบรรพบุรุษเราจึงคำนวณส่วนหัว (โหนดปม) ของพื้นที่ทั่วไป ดังนั้นยังคงเป็นข้อมูลจำนวนเล็กน้อยแม้ว่าจะมีประวัติที่ใช้ร่วมกันขนาดใหญ่
Martin Geisler

ฉันอัปเดตคำตอบของฉันเพื่อรวมจำนวนการเดินทางไปกลับที่ใช้ (ซึ่งกลายเป็นน้อยมาก)
David Eppstein

3

ในการแก้ปัญหาที่เรานำมาใช้กับ Mercurial ข้อกังวลอีกอย่างก็คือความไม่สมดุล: ภาระของเซิร์ฟเวอร์ควรจะลดลงทั้งแบนด์วิดท์ขาออกและเวลา CPU ในต้นทุนของการโหลดไคลเอ็นต์


1
ขอบคุณฉันได้อัปเดตคำถามเล็กน้อยเพื่อทราบสิ่งนี้
Martin Geisler

0

ฟังดูเหมือนกระบวนการสองขั้นตอนสำหรับฉัน

  1. ถามลูกค้าทั้งหมดว่าพวกเขามีข้อผูกพันที่ผู้ปกครองเป็นค
  2. ถ้าเป็นเช่นนั้นค้นหา childs ทั้งหมดของ c

งานของ 1 ฉันคิดว่าส่วนใหญ่จะถูกประมวลผลทางฝั่งไคลเอ็นต์และไคลเอนต์ทั้งหมดต้องการแฮชการคอมมิชชันผ่านเน็ต


คุณอธิบายสถานการณ์อะไร กรณีที่ผมทำxและyและจำเป็นที่จะต้องดึงeและdจากเซิร์ฟเวอร์? ปัญหา inital มีคือว่าผม (เป็นลูกค้า) ไม่ทราบจุด c"สาขา"
Martin Geisler
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.