อีก 50 ปีต่อมา two-phase locking ยังเป็นสิ่งที่ดีที่สุดที่เราทำได้หรือไม่?

 (concurrencyfreaks.blogspot.com)
1 คะแนน โดย GN⁺ 2023-10-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • บทความนี้กล่าวถึงแนวคิด Two-Phase Locking (2PL) ซึ่งเป็นกลไกควบคุมภาวะพร้อมกันแบบทั่วไปที่ถูกคิดค้นขึ้นเมื่อราว 50 ปีก่อน
  • 2PL มอบระดับการแยกข้อมูลที่แข็งแกร่งกว่าอย่าง Serializability และ Opacity และใช้กับทรานแซ็กชันที่เกี่ยวข้องกับข้อมูลหลายรายการ
  • ผู้เขียนเน้นว่าความเรียบง่ายของ 2PL และระดับการแยกข้อมูลที่แข็งแกร่งคือข้อได้เปรียบหลัก
  • อย่างไรก็ตาม 2PL มีข้อเสียคือความสามารถในการขยายตัวด้านการอ่านต่ำ และมีปัญหาเรื่องการดำเนินต่อไปแบบ live-lock
  • ผู้เขียนแนะนำกลไกควบคุมภาวะพร้อมกันแบบใหม่ชื่อ Two-Phase Locking Starvation-Free (2PLSF) เพื่อแก้ปัญหาของ 2PL
  • 2PLSF ใช้ reader-writer lock ที่ดีกว่า และมอบการดำเนินของทรานแซ็กชันแบบปราศจาก starvation ซึ่งเป็นรูปแบบความก้าวหน้าในระบบบล็อกกิงระดับสูงสุด
  • 2PLSF มีประสิทธิภาพในการแก้ไขความขัดแย้งบางประเภท จึงสามารถขยายตัวได้แม้ยังมีความขัดแย้งบางส่วนเกิดขึ้น
  • ผู้เขียนสรุปว่า 2PLSF เป็นการปรับปรุงครั้งใหญ่เมื่อเทียบกับ 2PL และเปรียบความแตกต่างนี้เหมือนค้อนเจาะถนนกับเสียม
  • บทความนี้มีลิงก์ไปยังงานวิจัยและซอร์สโค้ดของอัลกอริทึม 2PLSF เพื่อใช้อ้างอิงสำหรับการศึกษาเพิ่มเติม

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-10-01
ความคิดเห็นจาก Hacker News
  • บทความเกี่ยวกับการอภิปรายเรื่อง two-phase locking (2PL) และความเกี่ยวข้องของมันหลังจากถูกพัฒนาขึ้นครั้งแรกเมื่อ 50 ปีก่อน
  • ผู้แสดงความคิดเห็นคนหนึ่งระบุว่าตนยังเป็นมือใหม่ในหัวข้อนี้ และกำลังมองหาโซลูชันด้านความสอดคล้องที่นำไปใช้งานได้ง่ายสำหรับสถาปัตยกรรมไมโครเซอร์วิสแบบกระจาย
  • ผู้แสดงความคิดเห็นคนเดิมได้แชร์โค้ด Python สำหรับทดสอบความไม่กำหนดแน่นอนในสภาพแวดล้อมมัลติโพรเซสซิงแบบหลายเธรด
  • ผู้แสดงความคิดเห็นอีกคนเสนอว่าควรพิจารณาก่อนว่าจำเป็นต้องใช้อัลกอริทึมการล็อกจริงหรือไม่ และแนะนำให้ประมวลผลคำขอแบบเป็นชุดเพื่อลด concurrency และการล็อก
  • มีการตั้งคำถามว่าแนวทางใหม่เมื่อเทียบกับ serializable snapshot isolation (SSI) ซึ่งถูกโฆษณาว่าเป็นเวอร์ชันปรับปรุงของ 2PL นั้นเป็นอย่างไร
  • ผู้แสดงความคิดเห็นคนหนึ่งเสนอว่าควรมีนโยบายใหม่ของ Hacker News ที่กำหนดให้ลิงก์ทั้งหมดที่เผยแพร่ต้องเป็น HTTPS
  • มีการแชร์ลิงก์ไปยังงานวิจัยของผู้เขียนเกี่ยวกับ 2PLSF ซึ่งผู้เขียนอ้างว่าเป็นสิ่งที่ 2PL ควรจะเป็นแต่แรก
  • มีข้อเสนอให้เพิ่มคิวแบบสุ่มเพื่อปรับปรุงความสามารถในการขยายตัวของงานแบบอะตอมมิก
  • มีการตั้งคำถามว่าในแนวทาง Wait-Or-Die จำเป็นต้องดึงและเพิ่ม transaction ID หรือไม่ โดยเสนอว่าอาจใช้ thread ID หรือเลขสุ่มแทนได้
  • ผู้แสดงความคิดเห็นคนหนึ่งไม่เข้าใจภาพสุดท้ายเกี่ยวกับต้นไม้ AVL แบบผ่อนปรนในบริบทของธุรกรรมแบบอ่านอย่างเดียว
  • มีการตั้งคำถามเกี่ยวกับความสามารถในการประยุกต์ใช้ 2PL ในบริบทของการเรียก API ที่เชื่อมโยงกันอย่างหลวม ๆ
  • มีการตั้งข้อสังเกตว่าธุรกรรมการเขียนส่วนใหญ่ต้องการการอ่านที่สอดคล้องกันสำหรับอ็อบเจ็กต์ที่มีการแข่งขันสูงจำนวนมาก แต่การเขียนจริงมักมีเพียงหนึ่งหรือสองอ็อบเจ็กต์ และตั้งคำถามว่า 2PL สามารถแก้ปัญหานี้ได้หรือไม่