ทุกที่ที่ฉันมองฉันเห็นว่า MongoDB คือ CP แต่เมื่อฉันขุดลงไปฉันเห็นว่ามันสอดคล้องกันในที่สุด CP เมื่อคุณใช้ปลอดภัย = จริงหรือไม่? ถ้าเป็นเช่นนั้นหมายความว่าเมื่อฉันเขียนด้วย safe = true แบบจำลองทั้งหมดจะได้รับการอัปเดตก่อนที่จะได้รับผลลัพธ์หรือไม่
ทุกที่ที่ฉันมองฉันเห็นว่า MongoDB คือ CP แต่เมื่อฉันขุดลงไปฉันเห็นว่ามันสอดคล้องกันในที่สุด CP เมื่อคุณใช้ปลอดภัย = จริงหรือไม่? ถ้าเป็นเช่นนั้นหมายความว่าเมื่อฉันเขียนด้วย safe = true แบบจำลองทั้งหมดจะได้รับการอัปเดตก่อนที่จะได้รับผลลัพธ์หรือไม่
คำตอบ:
MongoDB มีความสอดคล้องกันอย่างมากโดยค่าเริ่มต้น - หากคุณเขียนแล้วทำการอ่านโดยสมมติว่าการเขียนประสบความสำเร็จคุณจะสามารถอ่านผลลัพธ์ของการเขียนที่คุณเพิ่งอ่านได้เสมอ เนื่องจาก MongoDB เป็นระบบ single-master และการอ่านทั้งหมดจะไปที่ primary ตามค่าเริ่มต้น หากคุณเลือกที่จะเปิดใช้งานการอ่านจากลำดับที่สอง MongoDB จะสอดคล้องกันในที่สุดซึ่งเป็นไปได้ที่จะอ่านผลลัพธ์ที่ล้าสมัย
MongoDB ยังมีความพร้อมใช้งานสูงผ่านการล้มเหลวอัตโนมัติในชุดจำลอง: http://www.mongodb.org/display/DOCS/Replica+Sets
ฉันเห็นด้วยกับโพสต์ของ Luccas คุณไม่สามารถพูดได้ว่า MongoDB คือ CP / AP / CA เพราะจริงๆแล้วมันเป็นการแลกเปลี่ยนระหว่าง C, A และ P ขึ้นอยู่กับทั้งการกำหนดค่าฐานข้อมูล / ไดรเวอร์และประเภทของภัยพิบัตินี่คือภาพสรุปและด้านล่าง คำอธิบายโดยละเอียดเพิ่มเติม
Scenario | Main Focus | Description
---------------------------|------------|------------------------------------
No partition | CA | The system is available
| | and provides strong consistency
---------------------------|------------|------------------------------------
partition, | AP | Not synchronized writes
majority connected | | from the old primary are ignored
---------------------------|------------|------------------------------------
partition, | CP | only read access is provided
majority not connected | | to avoid separated and inconsistent systems
MongoDB มีความสอดคล้องอย่างมากเมื่อคุณใช้การเชื่อมต่อเดียวหรือระดับข้อกังวลในการเขียน / อ่านที่ถูกต้อง( ซึ่งจะทำให้คุณเสียค่าความเร็วในการดำเนินการ ) ทันทีที่คุณไม่ปฏิบัติตามเงื่อนไขเหล่านั้น (โดยเฉพาะเมื่อคุณกำลังอ่านจากแบบจำลองรอง) MongoDB จะสอดคล้องกันในที่สุด
MongoDB ได้รับการว่างสูงผ่านแบบจำลองชุด ทันทีที่หลักหยุดทำงานหรือไม่สามารถใช้งานได้อย่างอื่นหน่วยรองจะกำหนดหลักใหม่ให้พร้อมใช้งานอีกครั้ง มีข้อเสียสำหรับสิ่งนี้: การเขียนทุกครั้งที่ดำเนินการโดยหลักเก่า แต่ไม่ได้ซิงโครไนซ์กับลำดับที่สองจะถูกย้อนกลับและบันทึกลงในไฟล์ย้อนกลับทันทีที่เชื่อมต่อกับชุดอีกครั้ง (หลักเก่าเป็นตัวรอง ตอนนี้) ดังนั้นในกรณีนี้ความสม่ำเสมอบางอย่างจึงถูกเสียสละเพื่อความพร้อมใช้งาน
ผ่านการใช้งานของแบบจำลองกล่าวว่าชุด MongoDB ยังประสบความสำเร็จในความอดทนพาร์ทิชัน: ตราบเท่าที่มากกว่าครึ่งหนึ่งของเซิร์ฟเวอร์ของแบบจำลองชุดที่เชื่อมต่อกับแต่ละอื่น ๆหลักใหม่สามารถเลือก ทำไม? เพื่อให้แน่ใจว่าสองเครือข่ายที่แยกจากกันไม่สามารถเลือกเครือข่ายหลักใหม่ได้ เมื่อเชื่อมต่อกันไม่เพียงพอคุณยังคงสามารถอ่านได้ (แต่ไม่มั่นใจว่าสอดคล้องกัน) แต่ไม่สามารถเขียนได้ ชุดนี้ไม่สามารถใช้งานได้จริงเนื่องจากความสม่ำเสมอ
เมื่อมีบทความใหม่ที่ยอดเยี่ยมปรากฏขึ้นและการทดลองที่ยอดเยี่ยมของ Kyleในสาขานี้คุณควรระมัดระวังในการติดป้าย MongoDB และฐานข้อมูลอื่น ๆ เช่น C หรือ A
แน่นอนว่า CAP ช่วยในการติดตามโดยไม่ต้องใช้คำพูดมากนักว่าฐานข้อมูลมีความสำคัญอย่างไร แต่คนมักลืมไปว่า C ใน CAP หมายถึงความสอดคล้องของอะตอม (linearizability) เป็นต้น และสิ่งนี้ทำให้ฉันรู้สึกเจ็บปวดมากที่ต้องเข้าใจเมื่อพยายามจัดประเภท ดังนั้นนอกจาก MongoDB จะให้ความสม่ำเสมอที่แข็งแกร่งแล้วนั่นไม่ได้หมายความว่านั่นคือ C ด้วยวิธีนี้หากมีการจัดประเภทนี้ฉันขอแนะนำให้เจาะลึกมากขึ้นว่ามันใช้งานได้จริงอย่างไรเพื่อไม่ทิ้งความสงสัย
ใช่มันเป็น CP safe=trueเมื่อใช้ นี่หมายความว่าข้อมูลที่ส่งไปยังมาสเตอร์ดิสก์ หากคุณต้องการให้แน่ใจว่ามันมาถึงแบบจำลองบางตัวด้วยให้ดูที่พารามิเตอร์ 'w = N' โดยที่ N คือจำนวนของแบบจำลองที่ข้อมูลจะต้องถูกบันทึกไว้
ฉันไม่แน่ใจเกี่ยวกับ P สำหรับ Mongo ลองนึกภาพสถานการณ์:
ปัญหาคือขนาดไฟล์ดัมพ์มี จำกัด และหากคุณมีพาร์ติชั่นเป็นเวลานานคุณจะสูญเสียข้อมูลของคุณไปตลอดกาล
คุณสามารถพูดได้ว่ามันไม่น่าจะเกิดขึ้น - ใช่เว้นแต่ในระบบคลาวด์ซึ่งเป็นเรื่องธรรมดามากกว่าที่คิด
ตัวอย่างนี้เป็นเหตุผลว่าทำไมฉันจึงต้องระมัดระวังอย่างมากก่อนที่จะมอบหมายจดหมายใด ๆ ให้กับฐานข้อมูลใด ๆ มีหลายสถานการณ์และการใช้งานที่ไม่สมบูรณ์แบบ
หากใครทราบว่าสถานการณ์นี้ได้รับการแก้ไขใน Mongo รุ่นต่อ ๆ ไปหรือไม่โปรดแสดงความคิดเห็น! (ฉันไม่ได้ติดตามทุกอย่างที่เกิดขึ้นมาระยะหนึ่งแล้ว .. )
Mongodb ไม่อนุญาตให้เขียนถึงมัธยมศึกษา อนุญาตให้อ่านเพิ่มเติมจากรอง แต่ไม่สามารถเขียนได้ ดังนั้นหากหลักของคุณลดลงคุณจะไม่สามารถเขียนได้จนกว่ามัธยมศึกษาจะกลายเป็นหลักอีกครั้ง นั่นคือวิธีที่คุณเสียสละความพร้อมใช้งานสูงในทฤษฎีบท CAP การทำให้การอ่านของคุณเป็นเพียงการอ่านหลักเท่านั้นคุณสามารถมีความสม่ำเสมอที่ดีได้
MongoDB เลือก Consistency over Availability ทุกครั้งที่มี Partition ความหมายคือเมื่อมีพาร์ติชัน (P) จะเลือก Consistency (C) เหนือ Availability (A)
เพื่อให้เข้าใจสิ่งนี้เรามาทำความเข้าใจกันว่า MongoDB ใช้ชุดการจำลองอย่างไร Replica Set มีโหนดหลักเดียว วิธีเดียวที่ "ปลอดภัย" ในการคอมมิตข้อมูลคือการเขียนไปยังโหนดนั้นจากนั้นรอให้ข้อมูลนั้นส่งไปยังโหนดส่วนใหญ่ในชุด (คุณจะเห็นแฟล็กนั้นสำหรับ w = ส่วนใหญ่เมื่อส่งการเขียน)
พาร์ติชันสามารถเกิดขึ้นได้ในสองสถานการณ์ดังนี้:
โดยทั่วไปเมื่อใดก็ตามที่พาร์ติชันเกิดขึ้นและ MongoDB จำเป็นต้องตัดสินใจว่าจะทำอย่างไรมันจะเลือก Consistency over Availability ระบบจะหยุดยอมรับการเขียนลงในระบบจนกว่าจะเชื่อว่าสามารถดำเนินการเขียนเหล่านั้นได้อย่างปลอดภัย
MongoDB ให้สอดคล้องและพาร์ทิชันอดทน
ในบริบทของฐานข้อมูลแบบกระจาย (NoSQL) หมายความว่าจะมีการแลกเปลี่ยนระหว่างความสอดคล้องและความพร้อมใช้งานอยู่เสมอ เนื่องจากระบบแบบกระจายจำเป็นต้องมีความทนทานต่อพาร์ติชันเสมอ (กล่าวคือจะไม่เป็นฐานข้อมูลแบบกระจายหากไม่สามารถใช้งานพาร์ติชันได้)
ความสม่ำเสมอ - ระบบจะกลายเป็นความสอดคล้องกันในที่สุด ข้อมูลจะแพร่กระจายไปยังทุกที่ที่ควรไม่ช้าก็เร็ว แต่ระบบจะยังคงรับข้อมูลเข้าและไม่ได้ตรวจสอบความสอดคล้องของทุกธุรกรรมก่อนที่จะย้ายไปยังรายการถัดไป
ความพร้อมใช้งาน - โดยค่าเริ่มต้น Mongo DB Client (ไดรเวอร์ MongoDB) จะส่งคำขออ่าน / เขียนทั้งหมดไปยังผู้นำ / โหนดหลัก ทำให้ระบบมีความสอดคล้องกัน แต่ไม่สามารถใช้งานได้เนื่องจาก - หากผู้นำตัดการเชื่อมต่อจากคลัสเตอร์จะใช้เวลาสองสามวินาทีในการเลือกผู้นำคนใหม่ ดังนั้นจึงทำให้ไม่สามารถเขียนและอ่านได้ในช่วงเวลาดังกล่าว