สถาปัตยกรรมฐานข้อมูล Master-master vs master-slave?

ฉันเคยได้ยินเกี่ยวกับสถาปัตยกรรมฐานข้อมูลสองประเภท

• ต้นแบบต้นแบบ

• master ทาส

master-master ไม่เหมาะกับเว็บในปัจจุบันมากกว่าเพราะมันเหมือนกับ Git ทุกหน่วยมีชุดข้อมูลทั้งหมดและถ้ามีใครลงไปก็ไม่สำคัญ

Master-slave ทำให้ฉันนึกถึง SVN (ซึ่งฉันไม่ชอบ) ที่คุณมีหน่วยกลางหนึ่งหน่วยที่จัดการสิ่งต่างๆ

คำถาม:

1. ข้อดีข้อเสียของแต่ละข้อคืออะไร?

2. หากคุณต้องการมีฐานข้อมูลท้องถิ่นในโทรศัพท์มือถือของคุณเช่น iPhone อันไหนเหมาะสมกว่ากัน?

3. การเลือกหนึ่งในปัจจัยเหล่านี้เป็นปัจจัยสำคัญที่ต้องพิจารณาอย่างละเอียดหรือไม่?

เรากำลังแลกเปลี่ยนความพร้อมความสม่ำเสมอและความซับซ้อน เพื่อตอบคำถามสุดท้ายก่อน: เรื่องนี้สำคัญหรือไม่? ใช่มาก! ตัวเลือกเกี่ยวกับวิธีจัดการข้อมูลของคุณเป็นพื้นฐานอย่างยิ่งและไม่มี "แนวทางปฏิบัติที่ดีที่สุด" หลบเลี่ยงการตัดสินใจ คุณต้องเข้าใจข้อกำหนดเฉพาะของคุณ

มีความตึงเครียดพื้นฐาน:

สำเนาเดียว: ความสม่ำเสมอเป็นเรื่องง่าย แต่ถ้าเกิดขึ้นทุกคนก็ไม่ได้อยู่ในน้ำและหากผู้คนอยู่ห่างไกลอาจต้องเสียค่าสื่อสารที่น่ากลัว นำอุปกรณ์พกพาซึ่งอาจต้องใช้งานโดยไม่ได้เชื่อมต่อเข้ามาในภาพและสำเนาหนึ่งชุดจะไม่ตัด

Master Slave: ความสอดคล้องนั้นไม่ยากเกินไปเพราะข้อมูลแต่ละชิ้นมีต้นแบบที่เป็นเจ้าของเพียงคนเดียว แต่แล้วจะทำยังไงถ้ามองไม่เห็นอาจารย์คนนั้นจำเป็นต้องเลื่อนงานออกไป

Master-Master: ถ้าคุณสามารถทำให้มันใช้งานได้ดูเหมือนว่าจะเสนอทุกอย่างไม่มีจุดล้มเหลวแม้แต่จุดเดียวทุกคนสามารถทำงานได้ตลอดเวลา ปัญหานี้คือมันยากมากที่จะรักษาความสม่ำเสมออย่างแท้จริง ดูบทความวิกิพีเดียสำหรับข้อมูลเพิ่มเติม

วิกิพีเดียดูเหมือนจะสรุปข้อดีและข้อเสียได้ดี

ข้อดี

• หากมาสเตอร์คนใดคนหนึ่งล้มเหลวมาสเตอร์คนอื่นจะอัปเดตฐานข้อมูลต่อไป

• ผู้เชี่ยวชาญสามารถอยู่ในไซต์ทางกายภาพหลายแห่งเช่นกระจายไปทั่วเครือข่าย

ข้อเสีย

• ระบบการจำลองแบบหลายหลักส่วนใหญ่มีความสอดคล้องกันอย่างหลวม ๆ เท่านั้นเช่นขี้เกียจและอะซิงโครนัสละเมิดคุณสมบัติของกรด

• ระบบการจำลองแบบกระตือรือร้นมีความซับซ้อนและทำให้เกิดความล่าช้าในการสื่อสาร

• ปัญหาต่างๆเช่นการแก้ไขข้อขัดแย้งอาจกลายเป็นเรื่องยากเมื่อจำนวนโหนดที่เกี่ยวข้องเพิ่มขึ้นและเวลาในการตอบสนองที่ต้องการจะลดลง

ในขณะที่ค้นคว้าสถาปัตยกรรมฐานข้อมูลต่างๆด้วย ฉันได้รวบรวมข้อมูลดีๆที่อาจเกี่ยวข้องกับคนอื่นที่กำลังค้นคว้าในอนาคต ฉันได้ข้ามผ่าน

1. การจำลองแบบ Master-Slave
2. การจำลองแบบ Master-Master
3. MySQL คลัสเตอร์

ฉันตัดสินใจที่จะใช้ MySQL Cluster สำหรับกรณีการใช้งานของฉัน อย่างไรก็ตามโปรดดูข้อดีข้อเสียต่างๆที่ฉันได้รวบรวมไว้ด้านล่าง

1. การจำลองแบบ Master-Slave

ข้อดี

• แอปพลิเคชันการวิเคราะห์สามารถอ่านจากทาสโดยไม่ส่งผลกระทบต่อต้นแบบ
• การสำรองฐานข้อมูลทั้งหมดที่ไม่มีผลกระทบต่อหลัก
• ทาสสามารถออฟไลน์และซิงค์กลับไปที่มาสเตอร์โดยไม่ต้องหยุดทำงานใด ๆ

จุดด้อย

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

2. การจำลองแบบ Master-Master

ข้อดี

• แอปพลิเคชันสามารถอ่านได้จากผู้เชี่ยวชาญทั้งสอง
• กระจายโหลดการเขียนบนโหนดหลักทั้งสอง
• ล้มเหลวง่ายอัตโนมัติและรวดเร็ว

จุดด้อย

• สม่ำเสมออย่างหลวม ๆ
• ไม่ง่ายเหมือน master-slave ในการกำหนดค่าและปรับใช้

3. MySQL คลัสเตอร์

เด็กใหม่ในเมืองจากการออกแบบคลัสเตอร์ MySQL คลัสเตอร์ MySQL ได้รับการพัฒนาโดยคำนึงถึงความพร้อมใช้งานและความสามารถในการปรับขนาดได้สูงและเป็นโซลูชันที่เหมาะสำหรับใช้กับสภาพแวดล้อมที่ไม่ต้องมีการหยุดทำงานความสามารถในการใช้งานสูงและความยืดหยุ่นในแนวนอน

ดูMySQL Cluster 101สำหรับข้อมูลเพิ่มเติม

ข้อดี

• (High Avalability) ไม่มีจุดล้มเหลวแม้แต่จุดเดียว
• ปริมาณงานสูงมาก
• เวลาทำงาน 99.99%
• Auto-sharding
• การตอบสนองตามเวลาจริง
• การดำเนินการออนไลน์ (การเปลี่ยนแปลงสคีมา ฯลฯ )
• การเขียนแบบกระจาย

จุดด้อย

• ดูข้อ จำกัด ที่ทราบ

คุณสามารถเยี่ยมชมรายละเอียดทั้งหมดในบล็อกของฉันรวมถึงไดอะแกรมสถาปัตยกรรมที่มีรายละเอียดเพิ่มเติมเกี่ยวกับสถาปัตยกรรมที่กล่าวถึง 3 แบบ