การประชุม HighLoad++ ครั้งต่อไปจะจัดขึ้นในวันที่ 6 และ 7 เมษายน 2020 ที่เซนต์ปีเตอร์สเบิร์ก
รายละเอียดและตั๋ว . HighLoad++ Siberia 2019 ฮอลล์ "ครัสโนยาสค์" วันที่ 25 มิถุนายน เวลา 12 น. วิทยานิพนธ์และ .
ข้อกำหนดในทางปฏิบัติขัดแย้งกับทฤษฎี โดยไม่ได้คำนึงถึงประเด็นสำคัญสำหรับผลิตภัณฑ์เชิงพาณิชย์ การบรรยายนี้นำเสนอกระบวนการในการเลือกและผสมผสานแนวทางต่างๆ เพื่อสร้างองค์ประกอบความสอดคล้องเชิงสาเหตุโดยอิงจากการวิจัยทางวิชาการตามความต้องการของผลิตภัณฑ์เชิงพาณิชย์ ผู้ฟังจะได้เรียนรู้เกี่ยวกับวิธีการทางทฤษฎีที่มีอยู่สำหรับนาฬิกาแบบลอจิคัล การติดตามการพึ่งพา ความปลอดภัยของระบบ การซิงโครไนซ์นาฬิกา และสาเหตุที่ MongoDB ตัดสินใจเลือกโซลูชันบางอย่าง
มิคาอิล ทูเลเนฟ (ต่อไปนี้จะเรียกว่า MT): – ฉันจะพูดเกี่ยวกับความสอดคล้องเชิงสาเหตุ - นี่คือฟีเจอร์ที่เราพัฒนาใน MongoDB ฉันทำงานในกลุ่มระบบแบบกระจาย เราทำเมื่อประมาณสองปีที่แล้ว
ในกระบวนการนี้ ฉันต้องทำความคุ้นเคยกับงานวิจัยทางวิชาการมากมาย เนื่องจากคุณลักษณะนี้ได้รับการศึกษาค่อนข้างดี ปรากฎว่าไม่มีบทความใดที่เหมาะกับสิ่งที่จำเป็นในฐานข้อมูลการผลิต เนื่องจากมีข้อกำหนดเฉพาะเจาะจงมากที่อาจปรากฏอยู่ในแอปพลิเคชันการผลิตใดๆ
ฉันจะพูดถึงวิธีที่เราในฐานะผู้บริโภคงานวิจัยเชิงวิชาการเตรียมบางสิ่งบางอย่างจากการวิจัยเพื่อนำเสนอต่อผู้ใช้เป็นอาหารสำเร็จรูปที่สะดวกและปลอดภัยต่อการใช้งาน
ความสอดคล้องเชิงสาเหตุ เรามากำหนดแนวคิดกัน
อันดับแรก ฉันต้องการพูดในแง่ทั่วไปว่าความสอดคล้องเชิงสาเหตุคืออะไร มีตัวละครสองตัวคือ Leonard และ Penny (ละครโทรทัศน์เรื่อง The Big Bang Theory):
สมมติว่าเพนนีอยู่ในยุโรปและลีโอนาร์ดต้องการจัดงานปาร์ตี้เซอร์ไพรส์ให้เธอ และเขาคิดอะไรไม่ออกนอกจากการตัดเธอออกจากรายชื่อเพื่อน โดยส่งการอัปเดตให้เพื่อน ๆ ทุกคนบนฟีด: “มาทำให้เพนนีมีความสุขกันเถอะ!” (เธออยู่ในยุโรป ขณะที่เธอหลับ เธอไม่เห็นทั้งหมดนี้และไม่สามารถมองเห็นได้ เพราะเธอไม่อยู่ที่นั่น) ในที่สุดเธอก็ลบโพสต์นี้ ลบออกจากฟีด และคืนค่าการเข้าถึง เพื่อไม่ให้เธอสังเกตเห็นสิ่งใดๆ และไม่มีเรื่องอื้อฉาว
ทั้งหมดนี้ถือว่าดีและดี แต่สมมติว่าระบบมีการกระจายและเกิดข้อผิดพลาดเล็กน้อย ตัวอย่างเช่น อาจเกิดขึ้นได้ว่าการจำกัดการเข้าถึงของ Penny เกิดขึ้นหลังจากที่โพสต์นี้ปรากฏขึ้น หากเหตุการณ์ไม่เกี่ยวข้องกันตามเหตุและผล จริงๆ แล้ว นี่เป็นตัวอย่างเมื่อจำเป็นต้องมีความสอดคล้องเชิงสาเหตุเพื่อทำหน้าที่ทางธุรกิจ (ในกรณีนี้)
ในความเป็นจริงสิ่งเหล่านี้เป็นคุณสมบัติที่ไม่เล็กน้อยของฐานข้อมูล - มีคนเพียงไม่กี่คนที่สนับสนุนคุณสมบัติเหล่านี้ มาดูโมเดลกันดีกว่า
แบบจำลองความสม่ำเสมอ
โมเดลความสอดคล้องในฐานข้อมูลคืออะไรกันแน่? สิ่งเหล่านี้คือการรับประกันบางส่วนที่ระบบแบบกระจายให้เกี่ยวกับข้อมูลที่ลูกค้าสามารถรับได้และในลำดับใด
โดยหลักการแล้ว โมเดลความสอดคล้องทั้งหมดขึ้นอยู่กับความคล้ายคลึงของระบบแบบกระจายกับระบบที่ทำงาน เช่น บนโหนดเดียวบนแล็ปท็อป และนี่คือความคล้ายคลึงของระบบที่ทำงานบน "โหนด" ที่กระจายทางภูมิศาสตร์นับพันรายการกับแล็ปท็อป ซึ่งคุณสมบัติทั้งหมดเหล่านี้จะดำเนินการโดยอัตโนมัติตามหลักการ
ดังนั้น โมเดลความสอดคล้องจึงใช้กับระบบแบบกระจายเท่านั้น ระบบทั้งหมดที่มีอยู่ก่อนหน้านี้และดำเนินการในระดับแนวตั้งเดียวกันไม่เคยประสบปัญหาดังกล่าว มีแคชบัฟเฟอร์หนึ่งตัว และทุกอย่างจะถูกอ่านจากแคชนั้นเสมอ
รุ่นแรง
จริงๆ แล้วโมเดลแรกสุดคือ Strong (หรือแนวความสามารถในการเพิ่มขึ้นอย่างที่มักเรียกกันว่า) นี่คือโมเดลความสอดคล้องที่ทำให้แน่ใจว่าทุกการเปลี่ยนแปลงเมื่อได้รับการยืนยันว่าเกิดขึ้นแล้ว ผู้ใช้ทุกคนของระบบจะมองเห็นได้
สิ่งนี้จะสร้างลำดับสากลของเหตุการณ์ทั้งหมดในฐานข้อมูล นี่เป็นคุณสมบัติที่มีความสม่ำเสมอที่แข็งแกร่งมากและโดยทั่วไปจะมีราคาแพงมาก แต่ก็ได้รับการสนับสนุนเป็นอย่างดี มันแพงมากและช้า - แค่ไม่ค่อยได้ใช้ นี้เรียกว่าความสามารถในการเพิ่มขึ้น
มีคุณสมบัติอื่นที่แข็งแกร่งกว่าซึ่งได้รับการสนับสนุนใน Spanner - เรียกว่าความสม่ำเสมอภายนอก เราจะพูดถึงเรื่องนี้อีกสักหน่อย
เกี่ยวกับสาเหตุ
สิ่งต่อไปคือ Causal ซึ่งตรงกับสิ่งที่ฉันกำลังพูดถึง มีระดับย่อยอีกหลายระดับระหว่าง Strong และ Causal ที่ฉันจะไม่พูดถึง แต่ทั้งหมดจะลงไปที่ Causal นี่เป็นโมเดลที่สำคัญเนื่องจากเป็นโมเดลที่แข็งแกร่งที่สุดในบรรดาโมเดลทั้งหมด และมีความสอดคล้องที่แข็งแกร่งที่สุดเมื่อมีเครือข่ายหรือพาร์ติชัน
จริงๆ แล้ว สาเหตุคือสถานการณ์ที่เหตุการณ์ต่างๆ เชื่อมโยงกันด้วยความสัมพันธ์ระหว่างเหตุและผล บ่อยครั้งที่พวกเขาถูกมองว่าอ่านสิทธิ์ของคุณจากมุมมองของลูกค้า หากลูกค้าสังเกตค่าบางอย่างแล้ว เขาจะไม่สามารถมองเห็นค่าในอดีตได้ เขาเริ่มเห็นการอ่านคำนำหน้าแล้ว ทุกอย่างลงมาเพื่อสิ่งเดียวกัน
สาเหตุในฐานะแบบจำลองความสอดคล้องคือการเรียงลำดับเหตุการณ์บางส่วนบนเซิร์ฟเวอร์ ซึ่งเหตุการณ์จากไคลเอ็นต์ทั้งหมดจะถูกสังเกตในลำดับเดียวกัน ในกรณีนี้ ลีโอนาร์ดและเพนนี
ในที่สุด
แบบที่สามคือความสอดคล้องในที่สุด นี่คือสิ่งที่ระบบแบบกระจายทั้งหมดรองรับ ซึ่งเป็นโมเดลขั้นต่ำที่สมเหตุสมผล หมายถึงสิ่งต่อไปนี้: เมื่อเรามีการเปลี่ยนแปลงข้อมูล เมื่อถึงจุดหนึ่งการเปลี่ยนแปลงก็จะมีความสอดคล้องกัน
ในขณะนี้เธอไม่พูดอะไรเลย ไม่เช่นนั้นเธอจะกลายเป็นความสอดคล้องภายนอก - มันจะเป็นเรื่องราวที่แตกต่างไปจากเดิมอย่างสิ้นเชิง อย่างไรก็ตามนี่เป็นรุ่นที่ได้รับความนิยมมากซึ่งเป็นเรื่องธรรมดาที่สุด ตามค่าเริ่มต้น ผู้ใช้ทั้งหมดของระบบแบบกระจายจะใช้ความสอดคล้องในขั้นสุดท้าย
ฉันต้องการยกตัวอย่างเปรียบเทียบ:
ลูกศรเหล่านี้หมายถึงอะไร?
- เวลาในการตอบสนอง เมื่อความสม่ำเสมอเพิ่มขึ้น ความสอดคล้องก็จะใหญ่ขึ้นด้วยเหตุผลที่ชัดเจน นั่นคือ คุณต้องสร้างบันทึกเพิ่มเติม ได้รับการยืนยันจากโฮสต์และโหนดทั้งหมดที่มีส่วนร่วมในคลัสเตอร์ว่ามีข้อมูลอยู่แล้ว ดังนั้น ความสอดคล้องในที่สุดจึงมีคำตอบที่เร็วที่สุด เพราะตามกฎแล้ว คุณสามารถฝากไว้ในความทรงจำได้ และตามหลักการแล้ว ความตั้งใจนี้ก็เพียงพอแล้ว
- ความพร้อมใช้งาน หากเราเข้าใจว่านี่เป็นความสามารถของระบบในการตอบสนองเมื่อมีเครือข่ายพัง พาร์ติชัน หรือความล้มเหลวบางประเภท ความทนทานต่อข้อผิดพลาดจะเพิ่มขึ้นเมื่อโมเดลความสอดคล้องลดลง เนื่องจากเพียงพอสำหรับเราที่โฮสต์หนึ่งอาศัยอยู่และในเวลาเดียวกัน เวลาจะผลิตข้อมูลบางอย่าง ความสอดคล้องในที่สุดไม่ได้รับประกันสิ่งใดเกี่ยวกับข้อมูลเลย - อาจเป็นอะไรก็ได้
- ความผิดปกติ ในขณะเดียวกัน จำนวนความผิดปกติก็เพิ่มขึ้นอย่างแน่นอน ในความสม่ำเสมอที่แข็งแกร่ง สิ่งเหล่านี้แทบจะไม่ควรมีเลย แต่ในความสม่ำเสมอในท้ายที่สุด พวกเขาสามารถเป็นอะไรก็ได้ คำถามเกิดขึ้น: เหตุใดผู้คนจึงเลือกความสม่ำเสมอในขั้นสุดท้ายถ้ามันมีความผิดปกติ? คำตอบก็คือ โมเดลความสอดคล้องในขั้นสุดท้ายสามารถใช้ได้และมีความผิดปกติเกิดขึ้น เช่น ในระยะเวลาอันสั้น คุณสามารถใช้ตัวช่วยสร้างเพื่ออ่านและอ่านข้อมูลที่สอดคล้องกันไม่มากก็น้อย มักจะเป็นไปได้ที่จะใช้แบบจำลองที่มีความสอดคล้องสูง ในทางปฏิบัติวิธีนี้ได้ผล และบ่อยครั้งจำนวนความผิดปกติมักมีจำกัดในเวลา
ทฤษฎีบทแคป
เมื่อคุณเห็นคำว่าความสม่ำเสมอ ความพร้อมใช้งาน – คุณนึกถึงอะไร? ถูกต้อง - ทฤษฎีบท CAP! ตอนนี้ฉันต้องการปัดเป่าตำนาน... ไม่ใช่ฉัน - มันคือ Martin Kleppmann ผู้เขียนบทความที่ยอดเยี่ยม หนังสือที่ยอดเยี่ยม
ทฤษฎีบท CAP เป็นหลักการที่กำหนดขึ้นในทศวรรษ 2000 ว่าความสอดคล้อง ความพร้อมใช้งาน พาร์ติชัน: เลือกสองอันใดอันหนึ่ง แต่คุณไม่สามารถเลือกสามอันได้ มันเป็นหลักการที่แน่นอน ได้รับการพิสูจน์ว่าเป็นทฤษฎีบทในไม่กี่ปีต่อมาโดยกิลเบิร์ตและลินช์ จากนั้นสิ่งนี้ก็เริ่มใช้เป็นมนต์ - ระบบเริ่มแบ่งออกเป็น CA, CP, AP เป็นต้น
ทฤษฎีบทนี้ได้รับการพิสูจน์แล้วจริง ๆ ในกรณีต่อไปนี้... ประการแรก ความพร้อมใช้งานถูกพิจารณาว่าไม่ใช่ค่าต่อเนื่องตั้งแต่ศูนย์ถึงร้อย (0 - ระบบ "ตาย", 100 - ตอบสนองอย่างรวดเร็ว เราคุ้นเคยกับการพิจารณาเช่นนั้น) แต่เป็นคุณสมบัติของอัลกอริทึม ซึ่งรับประกันว่าสำหรับการประมวลผลทั้งหมด อัลกอริธึมจะส่งคืนข้อมูล
ไม่มีคำพูดเกี่ยวกับเวลาตอบสนองเลย! มีอัลกอริธึมที่ส่งคืนข้อมูลหลังจาก 100 ปีซึ่งเป็นอัลกอริธึมที่ยอดเยี่ยมอย่างยิ่งซึ่งเป็นส่วนหนึ่งของทฤษฎีบท CAP
ประการที่สอง: ทฤษฎีบทได้รับการพิสูจน์แล้วสำหรับการเปลี่ยนแปลงค่าของคีย์เดียวกันแม้ว่าการเปลี่ยนแปลงเหล่านี้จะปรับขนาดได้ก็ตาม ซึ่งหมายความว่าในความเป็นจริงแล้ว พวกเขาไม่ได้ใช้งานจริง เนื่องจากแบบจำลองมีความแตกต่างกันในท้ายที่สุด สอดคล้องกันอย่างมาก (อาจจะ)
ทั้งหมดนี้เพื่ออะไร? ยิ่งไปกว่านั้น ทฤษฎีบท CAP ในรูปแบบที่ได้รับการพิสูจน์แล้วนั้นไม่สามารถนำไปใช้ได้จริงและไม่ค่อยมีใครใช้ ในรูปแบบทางทฤษฎี มันจำกัดทุกอย่าง ปรากฎหลักการบางอย่างที่ถูกต้องโดยสัญชาตญาณ แต่โดยทั่วไปยังไม่ได้รับการพิสูจน์
ความสอดคล้องเชิงสาเหตุเป็นรูปแบบที่แข็งแกร่งที่สุด
สิ่งที่เกิดขึ้นตอนนี้คือคุณสามารถได้รับทั้งสามสิ่งนี้: ความสม่ำเสมอ ความพร้อมใช้งานโดยใช้พาร์ติชัน โดยเฉพาะอย่างยิ่ง ความสอดคล้องเชิงสาเหตุเป็นรูปแบบความสอดคล้องที่แข็งแกร่งที่สุด ซึ่งยังคงใช้งานได้เมื่อมีพาร์ติชันอยู่ (ตัวแบ่งในเครือข่าย) นั่นคือเหตุผลว่าทำไมจึงได้รับความสนใจอย่างมาก และนั่นคือสาเหตุที่เรารับมันไป
ประการแรก มันทำให้การทำงานของนักพัฒนาแอพพลิเคชั่นง่ายขึ้น โดยเฉพาะอย่างยิ่งการมีอยู่ของการสนับสนุนที่ดีเยี่ยมจากเซิร์ฟเวอร์: เมื่อบันทึกทั้งหมดที่เกิดขึ้นภายในไคลเอนต์หนึ่งได้รับการรับรองว่าจะมาถึงในลำดับเดียวกันบนไคลเอนต์อื่น ประการที่สอง ทนทานต่อการแบ่งพาร์ติชัน
ครัวภายใน MongoDB
จำได้ว่าใกล้จะเที่ยงแล้วจึงย้ายไปเข้าครัว ฉันจะบอกคุณเกี่ยวกับรูปแบบระบบคือ MongoDB คืออะไรสำหรับผู้ที่ได้ยินเกี่ยวกับฐานข้อมูลดังกล่าวเป็นครั้งแรก
MongoDB (ต่อไปนี้จะเรียกว่า “MongoDB”) เป็นระบบแบบกระจายที่รองรับการปรับขนาดแนวนอน นั่นคือ การแบ่งส่วน และภายในแต่ละส่วนยังรองรับข้อมูลซ้ำซ้อน ซึ่งก็คือการจำลองแบบ
การแบ่งส่วนใน MongoDB (ไม่ใช่ฐานข้อมูลเชิงสัมพันธ์) ดำเนินการปรับสมดุลอัตโนมัติ กล่าวคือ แต่ละคอลเลกชันของเอกสาร (หรือ "ตาราง" ในแง่ของข้อมูลเชิงสัมพันธ์) จะถูกแบ่งออกเป็นส่วนๆ และเซิร์ฟเวอร์จะย้ายเอกสารเหล่านั้นระหว่างส่วนต่างๆ โดยอัตโนมัติ
Query Router ซึ่งกระจายคำขอสำหรับไคลเอนต์คือไคลเอนต์บางตัวที่มันใช้งานได้ ระบบรู้อยู่แล้วว่าข้อมูลอยู่ที่ไหนและอยู่ที่ไหน และนำคำขอทั้งหมดไปยังส่วนข้อมูลที่ถูกต้อง
จุดสำคัญอีกประการหนึ่ง: MongoDB เป็นต้นแบบเดียว มีหนึ่งรายการหลัก - สามารถรับบันทึกที่รองรับคีย์ที่มีอยู่ได้ คุณไม่สามารถเขียนแบบมัลติมาสเตอร์ได้
เราเปิดตัว 4.2 - มีสิ่งที่น่าสนใจใหม่ ๆ ปรากฏขึ้นที่นั่น โดยเฉพาะอย่างยิ่งพวกเขาแทรก Lucene - การค้นหา - นั่นคือจาวาที่เรียกใช้งานได้โดยตรงใน Mongo และเป็นไปได้ที่จะทำการค้นหาผ่าน Lucene เช่นเดียวกับใน Elastica
และพวกเขาได้สร้างผลิตภัณฑ์ใหม่ - แผนภูมิ ซึ่งมีอยู่ใน Atlas ด้วย (คลาวด์ของ Mongo เอง) พวกเขามี Free Tier - คุณสามารถเล่นกับมันได้ ฉันชอบ Charts มาก - การแสดงข้อมูลเป็นภาพ ใช้งานง่ายมาก
ส่วนผสม ความสม่ำเสมอเชิงสาเหตุ
ฉันนับบทความประมาณ 230 บทความที่ได้รับการตีพิมพ์ในหัวข้อนี้ - จาก Leslie Lampert ตอนนี้จากความทรงจำของฉันฉันจะถ่ายทอดบางส่วนของเนื้อหาเหล่านี้ให้คุณฟัง
เรื่องราวทั้งหมดเริ่มต้นด้วยบทความของ Leslie Lampert ซึ่งเขียนขึ้นในปี 1970 อย่างที่คุณเห็น การวิจัยบางส่วนในหัวข้อนี้ยังคงดำเนินอยู่ ขณะนี้ความสม่ำเสมอเชิงสาเหตุกำลังประสบกับความสนใจในการพัฒนาระบบแบบกระจาย
ข้อ จำกัด
มีข้อจำกัดอะไรบ้าง? นี่เป็นหนึ่งในประเด็นหลักจริงๆ เนื่องจากข้อจำกัดที่ระบบการผลิตกำหนดนั้นแตกต่างอย่างมากจากข้อจำกัดที่มีอยู่ในบทความทางวิชาการ พวกมันมักจะค่อนข้างเป็นของเทียม
- ประการแรก “MongoDB” เป็นปรมาจารย์คนเดียวอย่างที่ฉันพูดไปแล้ว (สิ่งนี้ช่วยลดความซับซ้อนลงอย่างมาก)
- เราเชื่อว่าระบบควรรองรับชิ้นส่วนประมาณ 10 ชิ้น เราไม่สามารถทำการตัดสินใจทางสถาปัตยกรรมใดๆ ที่จะจำกัดคุณค่านี้อย่างชัดเจน
- เรามีคลาวด์ แต่เราคิดว่าบุคคลนั้นควรยังคงมีโอกาสเมื่อเขาดาวน์โหลดไบนารี่ รันมันบนแล็ปท็อปของเขา และทุกอย่างก็ทำงานได้ดี
- เราถือว่าบางสิ่งที่ Research ไม่ค่อยจะถือว่า: ลูกค้าภายนอกสามารถทำสิ่งที่พวกเขาต้องการได้ MongoDB เป็นโอเพ่นซอร์ส ด้วยเหตุนี้ ลูกค้าจึงฉลาดและโกรธมาก - พวกเขาต้องการทำลายทุกสิ่ง เราคาดเดาว่า Byzantine Feilors อาจกำเนิด
- สำหรับไคลเอ็นต์ภายนอกที่อยู่นอกขอบเขต มีข้อจำกัดที่สำคัญ: หากปิดใช้งานคุณลักษณะนี้ ก็ไม่ควรสังเกตประสิทธิภาพที่ลดลง
- โดยทั่วไปอีกประเด็นหนึ่งคือการต่อต้านทางวิชาการ: ความเข้ากันได้ของเวอร์ชันก่อนหน้าและเวอร์ชันในอนาคต ไดรเวอร์เก่าต้องรองรับการอัปเดตใหม่และฐานข้อมูลต้องรองรับไดรเวอร์เก่า
โดยทั่วไปแล้ว ทั้งหมดนี้ทำให้เกิดข้อจำกัด
องค์ประกอบความสม่ำเสมอเชิงสาเหตุ
ตอนนี้ฉันจะพูดถึงส่วนประกอบบางอย่าง หากเราพิจารณาความสอดคล้องเชิงสาเหตุโดยทั่วไป เราสามารถเลือกบล็อกได้ เราเลือกจากผลงานที่เป็นของบล็อกใดบล็อกหนึ่ง: การติดตามการพึ่งพา การเลือกนาฬิกา วิธีซิงโครไนซ์นาฬิกาเหล่านี้ระหว่างกัน และวิธีที่เรารับรองความปลอดภัย - นี่คือโครงร่างคร่าว ๆ ของสิ่งที่ฉันจะพูดถึง:
การติดตามการพึ่งพาแบบเต็ม
เหตุใดจึงจำเป็น? ดังนั้นเมื่อมีการจำลองข้อมูล แต่ละบันทึก การเปลี่ยนแปลงข้อมูลแต่ละครั้งจะมีข้อมูลเกี่ยวกับการเปลี่ยนแปลงที่ขึ้นอยู่กับ การเปลี่ยนแปลงแรกสุดและไร้เดียงสาคือเมื่อแต่ละข้อความที่มีบันทึกประกอบด้วยข้อมูลเกี่ยวกับข้อความก่อนหน้า:
ในตัวอย่างนี้ ตัวเลขในวงเล็บปีกกาคือหมายเลขเรกคอร์ด บางครั้งบันทึกที่มีค่าเหล่านี้อาจถูกถ่ายโอนทั้งหมดด้วยซ้ำ บางครั้งบางเวอร์ชันก็ถูกถ่ายโอนด้วยซ้ำ สิ่งที่สำคัญที่สุดคือการเปลี่ยนแปลงแต่ละครั้งมีข้อมูลเกี่ยวกับการเปลี่ยนแปลงก่อนหน้า (เห็นได้ชัดว่ามีทั้งหมดนี้อยู่ภายในตัวมันเอง)
เหตุใดเราจึงตัดสินใจไม่ใช้แนวทางนี้ (การติดตามแบบเต็ม) เห็นได้ชัดว่าเนื่องจากแนวทางนี้ไม่สามารถทำได้: การเปลี่ยนแปลงใด ๆ ในเครือข่ายโซเชียลนั้นขึ้นอยู่กับการเปลี่ยนแปลงก่อนหน้าทั้งหมดบนเครือข่ายโซเชียลนั้น ๆ การถ่ายโอน เช่น Facebook หรือ VKontakte ในทุกการอัปเดต อย่างไรก็ตาม มีการวิจัยมากมายเกี่ยวกับ Full Dependency Tracking ซึ่งเป็นเครือข่ายก่อนสังคมออนไลน์ สำหรับบางสถานการณ์ก็ใช้งานได้จริง
การติดตามการพึ่งพาที่ชัดเจน
อันถัดไปมีจำกัดมากขึ้น ที่นี่ยังพิจารณาการถ่ายโอนข้อมูลด้วย แต่เฉพาะสิ่งที่ขึ้นอยู่กับอย่างชัดเจนเท่านั้น ขึ้นอยู่กับสิ่งที่แอปพลิเคชันกำหนดตามกฎ เมื่อมีการจำลองข้อมูล แบบสอบถามจะส่งกลับเฉพาะการตอบสนองเมื่อการขึ้นต่อกันก่อนหน้านี้ได้รับการตอบสนองแล้วเท่านั้น ซึ่งก็คือ ดังที่แสดงไว้ นี่คือสาระสำคัญของความสอดคล้องเชิงสาเหตุทำงานอย่างไร
เธอเห็นว่าเรกคอร์ด 5 ขึ้นอยู่กับเรกคอร์ด 1, 2, 3, 4 ดังนั้น เธอจึงรอก่อนที่ไคลเอ็นต์จะสามารถเข้าถึงการเปลี่ยนแปลงที่ทำโดยการตัดสินใจเข้าถึงของ Penny เมื่อการเปลี่ยนแปลงก่อนหน้านี้ทั้งหมดได้ผ่านฐานข้อมูลไปแล้ว
สิ่งนี้ก็ไม่เหมาะกับเราเช่นกัน เนื่องจากยังมีข้อมูลมากเกินไป และจะทำให้สิ่งต่างๆ ช้าลง มีอีกแนวทางหนึ่ง...
นาฬิกาแลมพอร์ต
พวกเขาแก่มาก Lamport Clock หมายความว่าการขึ้นต่อกันเหล่านี้ถูกรวมเข้ากับฟังก์ชันสเกลาร์ ซึ่งเรียกว่า Lamport Clock
ฟังก์ชันสเกลาร์คือจำนวนนามธรรม มักเรียกว่าเวลาเชิงตรรกะ ในแต่ละเหตุการณ์ ตัวนับนี้จะเพิ่มขึ้น ตัวนับซึ่งปัจจุบันทราบกระบวนการนี้ จะส่งข้อความแต่ละข้อความ เป็นที่ชัดเจนว่ากระบวนการต่างๆ อาจไม่ซิงค์กัน อาจมีเวลาที่ต่างกันโดยสิ้นเชิง อย่างไรก็ตาม ระบบจะปรับสมดุลของนาฬิกาด้วยการส่งข้อความดังกล่าว จะเกิดอะไรขึ้นในกรณีนี้?
ฉันแบ่งส่วนใหญ่นั้นออกเป็นสองส่วนเพื่อให้ชัดเจน: เพื่อนสามารถอยู่ในโหนดเดียวซึ่งมีชิ้นส่วนของคอลเลกชัน และฟีดสามารถอยู่ในอีกโหนดหนึ่งซึ่งมีชิ้นส่วนของคอลเลกชันนี้ ชัดเจนไหมว่าพวกเขาจะออกจากแถวได้อย่างไร? ฟีดแรกจะพูดว่า: "จำลองแบบ" แล้วตามด้วยเพื่อน หากระบบไม่ได้รับประกันว่าฟีดจะไม่แสดงจนกว่าจะมีการส่งมอบการพึ่งพาของเพื่อนในคอลเลกชั่น Friends เราก็จะได้สถานการณ์ตามที่ฉันได้กล่าวไว้อย่างแน่นอน
คุณจะเห็นว่าเวลานับบนฟีดเพิ่มขึ้นอย่างมีเหตุผลอย่างไร:
ดังนั้นคุณสมบัติหลักของนาฬิกา Lamport และความสอดคล้องเชิงสาเหตุ (อธิบายผ่านนาฬิกา Lamport) คือ: หากเรามีเหตุการณ์ A และ B และเหตุการณ์ B ขึ้นอยู่กับเหตุการณ์ A* ดังนั้นเวลาตรรกะของเหตุการณ์ A น้อยกว่า LogicalTime จากเหตุการณ์ B
* บางครั้งพวกเขาก็บอกด้วยว่า A เกิดขึ้นก่อน B นั่นคือ A เกิดขึ้นก่อน B - นี่คือความสัมพันธ์บางอย่างที่สั่งการเหตุการณ์ทั้งหมดที่เกิดขึ้นโดยทั่วไปบางส่วน
ตรงกันข้ามไม่ถูกต้อง นี่เป็นหนึ่งในข้อเสียเปรียบหลักของนาฬิกา Lamport - การสั่งซื้อบางส่วน มีแนวคิดเกี่ยวกับเหตุการณ์ที่เกิดขึ้นพร้อมๆ กัน นั่นคือ เหตุการณ์ที่ไม่มีทั้ง (A เกิดขึ้นก่อน B) และ (A เกิดขึ้นก่อน B) ตัวอย่างอาจเป็นการที่ลีโอนาร์ดเพิ่มคนอื่นเป็นเพื่อนแบบคู่ขนาน (ไม่ใช่แม้แต่ลีโอนาร์ด แต่เป็นเชลดอนเป็นต้น)
นี่คือคุณสมบัติที่มักใช้เมื่อทำงานกับนาฬิกาของ Lamport โดยจะพิจารณาเฉพาะฟังก์ชันและสรุปได้ว่าบางทีเหตุการณ์เหล่านี้อาจขึ้นอยู่กับ เนื่องจากวิธีหนึ่งเป็นจริง: ถ้า LogicalTime A น้อยกว่า LogicalTime B แล้ว B จะไม่สามารถเกิดขึ้นก่อน A; และถ้ามากกว่านั้นอาจจะ
เว็กเตอร์คล็อก
การพัฒนาเชิงตรรกะของนาฬิกา Lamport คือนาฬิกาเวกเตอร์ ต่างกันตรงที่แต่ละโหนดที่อยู่ที่นี่มีนาฬิกาแยกกัน และพวกมันจะถูกส่งเป็นเวกเตอร์
ในกรณีนี้ คุณจะเห็นว่าดัชนีที่ศูนย์ของเวกเตอร์มีหน้าที่ฟีด และดัชนีแรกของเวกเตอร์นั้นมีไว้สำหรับเพื่อน (แต่ละโหนดเหล่านี้) และตอนนี้พวกมันจะเพิ่มขึ้น: ดัชนีศูนย์ของ "ฟีด" เพิ่มขึ้นเมื่อเขียน - 1, 2, 3:
ทำไม Vector Clock ถึงดีกว่า? เนื่องจากช่วยให้คุณทราบได้ว่าเหตุการณ์ใดเกิดขึ้นพร้อมกันและเกิดขึ้นเมื่อใดบนโหนดที่แตกต่างกัน นี่เป็นสิ่งสำคัญมากสำหรับระบบการแบ่งส่วนเช่น MongoDB อย่างไรก็ตาม เราไม่ได้เลือกสิ่งนี้ ถึงแม้จะเป็นสิ่งที่มหัศจรรย์ และใช้งานได้ดี และมันอาจจะเหมาะกับเรา...
หากเรามีชิ้นส่วน 10 ชิ้น เราจะไม่สามารถถ่ายโอนส่วนประกอบ 10 ชิ้นได้ แม้ว่าเราจะบีบอัดมันหรือคิดอย่างอื่นขึ้นมาก็ตาม - เพย์โหลดจะยังคงน้อยกว่าปริมาตรของเวกเตอร์ทั้งหมดนี้หลายเท่า ดังนั้นเราจึงกัดฟันสู้และละทิ้งแนวทางนี้และย้ายไปที่อื่น
ประแจ ทรูไทม์ นาฬิกาอะตอม
ฉันบอกว่าจะมีเรื่องราวเกี่ยวกับสแปนเนอร์ นี่เป็นสิ่งที่ยอดเยี่ยม ส่งตรงจากศตวรรษที่ XNUMX นาฬิกาอะตอม การซิงโครไนซ์ด้วย GPS
ความคิดคืออะไร? “Spanner” คือระบบของ Google ที่เพิ่งเปิดให้ใช้งานสำหรับผู้ใช้เมื่อไม่นานมานี้ (พวกเขาเพิ่ม SQL เข้าไปด้วย) แต่ละธุรกรรมมีการประทับเวลาอยู่บ้าง เนื่องจากเวลาซิงโครไนซ์* แต่ละเหตุการณ์จึงสามารถกำหนดเวลาที่เฉพาะเจาะจงได้ - นาฬิกาอะตอมมีเวลารอ หลังจากนั้นจะรับประกันเวลาที่แตกต่างกันว่าจะ "เกิดขึ้น"
ดังนั้น เพียงเขียนลงในฐานข้อมูลและรอสักระยะหนึ่ง ก็รับประกันความสามารถในการทำให้เป็นอนุกรมของเหตุการณ์ได้โดยอัตโนมัติ พวกเขามีแบบจำลองความสอดคล้องที่แข็งแกร่งที่สุดที่สามารถจินตนาการได้ในหลักการ - มันคือความสอดคล้องภายนอก
* นี่คือปัญหาหลักของนาฬิกา Lampart - ไม่เคยซิงโครไนซ์กับระบบแบบกระจาย พวกเขาสามารถแตกต่างออกไป แม้ว่าจะใช้ NTP ก็ยังทำงานได้ไม่ดีนัก "Spanner" มีนาฬิกาอะตอมและการซิงโครไนซ์ดูเหมือนว่าจะเป็นไมโครวินาที
ทำไมเราไม่เลือก? เราไม่คิดว่าผู้ใช้ของเรามีนาฬิกาอะตอมในตัว เมื่อนาฬิกาเหล่านี้ปรากฏขึ้น โดยถูกติดตั้งไว้ในแล็ปท็อปทุกเครื่อง จะมีการซิงโครไนซ์ GPS สุดเจ๋ง - ใช่แล้ว... แต่สำหรับตอนนี้สิ่งที่ดีที่สุดที่เป็นไปได้คือ Amazon สถานีฐาน - สำหรับผู้คลั่งไคล้... ดังนั้นเราจึงใช้นาฬิกาอื่น .
นาฬิกาไฮบริด
นี่คือสิ่งที่ทำเครื่องหมายใน MongoDB เมื่อมั่นใจในความสอดคล้องเชิงสาเหตุ พวกมันไฮบริดยังไงบ้าง? ไฮบริดเป็นค่าสเกลาร์ แต่มีสององค์ประกอบ:
- ยุคแรกคือยุค Unix (ผ่านไปกี่วินาทีนับตั้งแต่ "จุดเริ่มต้นของโลกคอมพิวเตอร์")
- อย่างที่สองคือการเพิ่มขึ้นบางส่วน รวมถึง int ที่ไม่ได้ลงชื่อแบบ 32 บิตด้วย
นั่นคือทั้งหมดจริงๆ มีแนวทางดังนี้ ส่วนที่รับผิดชอบเรื่องเวลาจะซิงโครไนซ์กับนาฬิกาตลอดเวลา ทุกครั้งที่มีการอัปเดต ส่วนนี้จะถูกซิงโครไนซ์กับนาฬิกาและปรากฎว่าเวลานั้นถูกต้องมากหรือน้อยเสมอ และการเพิ่มขึ้นทำให้คุณสามารถแยกแยะระหว่างเหตุการณ์ที่เกิดขึ้นในช่วงเวลาเดียวกันได้
เหตุใดสิ่งนี้จึงสำคัญสำหรับ MongoDB เนื่องจากช่วยให้คุณสร้างร้านอาหารสำรองบางประเภท ณ จุดใดจุดหนึ่งได้ กล่าวคือ กิจกรรมจะถูกจัดทำดัชนีตามเวลา นี่เป็นสิ่งสำคัญเมื่อจำเป็นต้องมีเหตุการณ์บางอย่าง สำหรับฐานข้อมูล เหตุการณ์คือการเปลี่ยนแปลงในฐานข้อมูลที่เกิดขึ้นในช่วงเวลาหนึ่ง
ฉันจะบอกเหตุผลที่สำคัญที่สุดให้คุณฟังเท่านั้น (โปรดอย่าบอกใครเลย)! เราทำสิ่งนี้เพราะนี่คือลักษณะข้อมูลที่จัดระเบียบและจัดทำดัชนีใน MongoDB OpLog OpLog เป็นโครงสร้างข้อมูลที่มีการเปลี่ยนแปลงทั้งหมดในฐานข้อมูล โดยไปที่ OpLog ก่อน จากนั้นจึงนำไปใช้กับ Storage เองในกรณีที่เป็นวันที่หรือชาร์ดที่จำลองแบบ
นี่คือเหตุผลหลัก ถึงกระนั้น ยังมีข้อกำหนดในทางปฏิบัติสำหรับการพัฒนาฐานข้อมูล ซึ่งหมายความว่าฐานข้อมูลควรจะเรียบง่าย - ใช้โค้ดเพียงเล็กน้อย มีสิ่งที่เสียหายน้อยที่สุดเท่าที่เป็นไปได้ซึ่งจำเป็นต้องเขียนใหม่และทดสอบ ความจริงที่ว่า oplogs ของเราได้รับการจัดทำดัชนีโดยนาฬิกาไฮบริดช่วยได้มากและทำให้เราสามารถตัดสินใจได้ถูกต้อง มันได้ผลจริงๆ และได้ผลอย่างมหัศจรรย์กับต้นแบบตัวแรกๆ มันเจ๋งมาก!
การซิงโครไนซ์นาฬิกา
มีวิธีการซิงโครไนซ์หลายวิธีที่อธิบายไว้ในวรรณกรรมทางวิทยาศาสตร์ ฉันกำลังพูดถึงการซิงโครไนซ์เมื่อเรามีชาร์ดที่แตกต่างกันสองอัน หากมีชุดเรพลิกาชุดเดียว ก็ไม่จำเป็นต้องมีการซิงโครไนซ์ใดๆ นี่คือ "ต้นแบบเดียว"; เรามี OpLog ซึ่งการเปลี่ยนแปลงทั้งหมดจะเกิดขึ้น - ในกรณีนี้ ทุกอย่างได้รับการเรียงลำดับตามลำดับใน "Oplog" เอง แต่ถ้าเรามีสองชิ้นส่วนที่แตกต่างกัน การประสานเวลาเป็นสิ่งสำคัญที่นี่ นี่คือจุดที่นาฬิกาเวกเตอร์ช่วยได้มากกว่า! แต่เราไม่มีพวกเขา
อันที่สองเหมาะ - นี่คือ "การเต้นของหัวใจ" สามารถแลกเปลี่ยนสัญญาณบางอย่างที่เกิดขึ้นทุกหน่วยเวลาได้ แต่ Heartbeats ช้าเกินไป เราไม่สามารถให้เวลาแฝงแก่ลูกค้าของเราได้
แน่นอนว่าเวลาจริงคือสิ่งมหัศจรรย์ แต่อีกครั้ง นี่อาจเป็นอนาคต... แม้ว่าจะสามารถทำได้ใน Atlas แล้ว แต่ก็มีการซิงโครไนซ์เวลา "Amazon" ที่รวดเร็วอยู่แล้ว แต่คงใช้ไม่ได้กับทุกคน
การนินทาคือการที่ข้อความทั้งหมดมีเวลา นี่คือสิ่งที่เราใช้โดยประมาณ ทุกข้อความระหว่างโหนด ไดรเวอร์ เราเตอร์โหนดข้อมูล ทุกอย่างสำหรับ MongoDB ล้วนเป็นองค์ประกอบบางประเภท ซึ่งเป็นส่วนประกอบของฐานข้อมูลที่มีนาฬิกาที่ทำงาน พวกเขามีความหมายของเวลาไฮบริดทุกที่ที่มีการถ่ายทอด 64 บิต? สิ่งนี้ทำให้สิ่งนี้เป็นไปได้
มันทำงานร่วมกันได้อย่างไร?
ที่นี่ ฉันกำลังดูชุดแบบจำลองหนึ่งชุดเพื่อทำให้ง่ายขึ้นนิดหน่อย มีประถมศึกษาและมัธยมศึกษา รองทำการจำลองแบบและไม่ได้ซิงโครไนซ์กับหลักเสมอไป
การแทรกจะเกิดขึ้นใน "Primery" ด้วยค่าเวลาที่แน่นอน ส่วนแทรกนี้จะเพิ่มจำนวนภายใน 11 หากเป็นจำนวนสูงสุด หรือจะตรวจสอบค่านาฬิกาและซิงค์กับนาฬิกาหากค่านาฬิกามากกว่า ซึ่งช่วยให้คุณสามารถจัดระเบียบตามเวลาได้
หลังจากที่เขาบันทึกเสียงแล้ว ช่วงเวลาสำคัญก็เกิดขึ้น นาฬิกาอยู่ใน "MongoDB" และเพิ่มขึ้นเฉพาะในกรณีที่เขียนไปที่ "Oplog" นี่คือเหตุการณ์ที่เปลี่ยนแปลงสถานะของระบบ ในบทความคลาสสิกทั้งหมด เหตุการณ์จะถือเป็นเมื่อมีข้อความถึงโหนด: ข้อความมาถึงแล้ว ซึ่งหมายความว่าระบบได้เปลี่ยนสถานะแล้ว
เนื่องจากในระหว่างการวิจัยยังไม่ชัดเจนว่าข้อความนี้จะถูกตีความอย่างไร เรารู้แน่ว่าหากไม่ได้สะท้อนให้เห็นใน "Oplog" ก็จะไม่ถูกตีความในทางใดทางหนึ่ง และการเปลี่ยนแปลงสถานะของระบบเป็นเพียงรายการใน "Oplog" สิ่งนี้ทำให้ทุกอย่างง่ายขึ้นสำหรับเรา: โมเดลทำให้มันง่ายขึ้น และช่วยให้เราจัดระเบียบมันภายในชุดแบบจำลองเดียว และสิ่งที่มีประโยชน์อื่น ๆ อีกมากมาย
ค่าที่เขียนไปยัง "Oplog" แล้วจะถูกส่งกลับ - เรารู้ว่า "Oplog" มีค่านี้อยู่แล้ว และเวลาของมันคือ 12 ตอนนี้สมมติว่าการอ่านเริ่มต้นจากโหนดอื่น (รอง) และส่ง afterClusterTime ใน ข้อความ. เขาพูดว่า: “ฉันต้องการทุกสิ่งที่เกิดขึ้นอย่างน้อยหลัง 12 น. หรือระหว่าง XNUMX น.” (ดูภาพด้านบน)
นี่คือสิ่งที่เรียกว่า Causal a Constable (CAT) มีแนวคิดในทางทฤษฎีที่ว่านี่คือเสี้ยวหนึ่งของเวลาซึ่งมีความสม่ำเสมอในตัวเอง ในกรณีนี้เราสามารถพูดได้ว่านี่คือสถานะของระบบที่ถูกสังเกต ณ เวลา 12
ขณะนี้ยังไม่มีสิ่งใดที่นี่ เนื่องจากประเภทนี้จะจำลองสถานการณ์เมื่อคุณต้องการให้ Secondary จำลองข้อมูลจาก Primary เขารอ... และตอนนี้ข้อมูลมาถึงแล้ว - เขาส่งคืนค่าเหล่านี้กลับมา
นั่นเป็นวิธีการทำงานทั้งหมด เกือบ.
“เกือบ” หมายความว่าอย่างไร? สมมติว่ามีบางคนที่ได้อ่านและเข้าใจว่าทั้งหมดนี้ทำงานอย่างไร ฉันตระหนักว่าทุกครั้งที่ ClusterTime เกิดขึ้น นาฬิกาจะอัปเดตนาฬิกาลอจิคัลภายใน จากนั้นรายการถัดไปจะเพิ่มขึ้นทีละรายการ ฟังก์ชันนี้ใช้เวลา 20 บรรทัด สมมติว่าบุคคลนี้ส่งหมายเลข 64 บิตที่ใหญ่ที่สุด ลบหนึ่ง
ทำไมต้อง "ลบหนึ่ง"? เนื่องจากนาฬิกาภายในจะถูกแทนที่เป็นค่านี้ (เห็นได้ชัดว่านี่เป็นค่าที่ใหญ่ที่สุดที่เป็นไปได้และมากกว่าเวลาปัจจุบัน) จากนั้นรายการจะเกิดขึ้นใน "Oplog" และนาฬิกาจะเพิ่มขึ้นอีกหน่วยหนึ่ง - และจะมีอยู่แล้ว เป็นค่าสูงสุด (มีเพียงทุกหน่วย ไม่มีที่อื่นให้ไป) , ints ที่ไม่ศักดิ์สิทธิ์)
เป็นที่ชัดเจนว่าหลังจากนี้ระบบจะไม่สามารถเข้าถึงได้โดยเด็ดขาด สามารถขนถ่ายและทำความสะอาดได้เท่านั้น - เป็นงานที่ต้องทำด้วยตนเองจำนวนมาก ความพร้อมเต็มรูปแบบ:
นอกจากนี้ หากมีการจำลองแบบที่อื่น คลัสเตอร์ทั้งหมดก็จะพังลง สถานการณ์ที่ยอมรับไม่ได้อย่างยิ่งที่ใครๆ ก็สามารถจัดการได้อย่างรวดเร็วและง่ายดาย! ดังนั้นเราจึงถือว่าช่วงเวลานี้เป็นหนึ่งในช่วงเวลาที่สำคัญที่สุด จะป้องกันได้อย่างไร?
วิธีของเราคือการลงนามในคลัสเตอร์Time
นี่คือวิธีการส่งข้อความ (ก่อนข้อความสีน้ำเงิน) แต่เราก็เริ่มสร้างลายเซ็นด้วย (ข้อความสีน้ำเงิน):
ลายเซ็นถูกสร้างขึ้นโดยคีย์ที่เก็บอยู่ภายในฐานข้อมูล ภายในขอบเขตที่ปลอดภัย มีการสร้างและอัปเดตตัวเอง (ผู้ใช้ไม่เห็นอะไรเกี่ยวกับมัน) แฮชจะถูกสร้างขึ้น และแต่ละข้อความจะถูกเซ็นชื่อเมื่อสร้างและตรวจสอบเมื่อได้รับ
คำถามอาจเกิดขึ้นในใจผู้คน: “สิ่งนี้ช้าลงมากแค่ไหน?” ฉันบอกคุณแล้วว่าควรทำงานได้อย่างรวดเร็ว โดยเฉพาะอย่างยิ่งในกรณีที่ไม่มีฟีเจอร์นี้
การใช้ความสม่ำเสมอเชิงสาเหตุในกรณีนี้หมายความว่าอย่างไร นี่คือการแสดงพารามิเตอร์ afterClusterTime หากไม่มีสิ่งนี้ มันก็จะส่งผ่านค่าต่างๆ ต่อไป การนินทาตั้งแต่เวอร์ชัน 3.6 จะใช้ได้ผลเสมอ
หากเราปล่อยการสร้างลายเซ็นอย่างต่อเนื่อง ระบบจะทำให้ระบบช้าลงแม้ว่าจะไม่มีฟีเจอร์ซึ่งไม่ตรงตามแนวทางและข้อกำหนดของเราก็ตาม แล้วเราทำอะไร?
ทำอย่างรวดเร็ว!
มันค่อนข้างง่าย แต่เคล็ดลับก็น่าสนใจ ฉันจะแชร์ เผื่อมีคนสนใจ
เรามีแฮชที่จัดเก็บข้อมูลที่ลงนาม ข้อมูลทั้งหมดผ่านแคช แคชไม่ได้ลงนามในเวลาที่กำหนด แต่เป็นช่วง เมื่อค่าบางค่ามาถึง เราจะสร้าง Range ปิดบัง 16 บิตสุดท้าย และลงนามค่านี้:
เมื่อได้รับลายเซ็นดังกล่าวเราจะเร่งความเร็วของระบบ (ค่อนข้าง) 65 ครั้ง มันใช้งานได้ดี: เมื่อเราทำการทดลอง เวลาจริงลดลง 10 เท่าเมื่อเรามีการอัปเดตตามลำดับ เห็นได้ชัดว่าเมื่อพวกเขาขัดแย้งกัน สิ่งนี้ไม่ได้ผล แต่ในกรณีที่ใช้งานได้จริงส่วนใหญ่จะใช้งานได้ การรวมกันของลายเซ็น Range ร่วมกับลายเซ็นช่วยแก้ปัญหาด้านความปลอดภัยได้
เราได้เรียนรู้อะไรบ้าง?
บทเรียนที่เราเรียนรู้จากสิ่งนี้:
- เราจำเป็นต้องอ่านสื่อ เรื่องราว บทความ เพราะเรามีสิ่งที่น่าสนใจมากมาย เมื่อเราทำงานกับฟีเจอร์บางอย่าง (โดยเฉพาะตอนนี้ ตอนที่เราทำธุรกรรม ฯลฯ) เราจำเป็นต้องอ่านและทำความเข้าใจ ต้องใช้เวลา แต่จริงๆ แล้วมีประโยชน์มาก เพราะมันทำให้ชัดเจนว่าเราอยู่ที่ไหน ดูเหมือนเราไม่ได้คิดอะไรใหม่ๆ เลย เราแค่หยิบส่วนผสมมาเท่านั้น
โดยทั่วไป การคิดจะมีความแตกต่างกันเมื่อมีการประชุมทางวิชาการ (เช่น Sigmon) ทุกคนมุ่งเน้นไปที่แนวคิดใหม่ๆ มีอะไรใหม่เกี่ยวกับอัลกอริทึมของเรา? ไม่มีอะไรใหม่เป็นพิเศษที่นี่ ความแปลกใหม่ค่อนข้างอยู่ที่วิธีที่เราผสมผสานแนวทางที่มีอยู่เข้าด้วยกัน ดังนั้นสิ่งแรกคือการอ่านหนังสือคลาสสิกโดยเริ่มจากแลมพาร์ต
- ในการผลิตมีข้อกำหนดแตกต่างอย่างสิ้นเชิง ฉันมั่นใจว่าพวกคุณหลายๆ คนไม่ต้องเผชิญกับฐานข้อมูล "ทรงกลม" ในสุญญากาศแบบนามธรรม แต่ต้องเผชิญกับสิ่งปกติที่เป็นของจริงที่มีปัญหาเกี่ยวกับความพร้อมใช้งาน เวลาแฝง และความทนทานต่อข้อผิดพลาด
- สิ่งสุดท้ายคือเราต้องดูแนวคิดที่แตกต่างกันและรวมบทความที่แตกต่างกันโดยสิ้นเชิงหลายบทความเข้าด้วยกันเป็นแนวทางเดียว ตัวอย่างเช่น แนวคิดเกี่ยวกับการลงนามโดยทั่วไปมาจากบทความที่พิจารณาโปรโตคอล Paxos ซึ่งสำหรับผู้ที่ไม่ใช่ Byzantine Failors อยู่ภายในโปรโตคอลการอนุญาต สำหรับ Byzantine - นอกโปรโตคอลการอนุญาต... โดยทั่วไป นี่คือสิ่งที่เรา จบลงด้วยการทำ
ไม่มีอะไรใหม่ที่นี่อย่างแน่นอน! แต่พอผสมทุกอย่างเข้าด้วยกัน...ก็เหมือนกับที่บอกว่าสูตรสลัดโอลิเวียร์ไร้สาระเพราะไข่ มายองเนส และแตงกวาถูกคิดค้นขึ้นมาแล้ว...ก็เรื่องเดียวกัน
ฉันจะจบเรื่องนี้ ขอบคุณ!
คำถาม
คำถามจากผู้ฟัง (ต่อไปนี้จะเรียกว่า ข): – ขอบคุณมิคาอิลสำหรับรายงาน! หัวข้อเรื่องเวลาก็น่าสนใจ คุณกำลังใช้การนินทา พวกเขาบอกว่าทุกคนมีเวลาของตัวเอง ทุกคนรู้เวลาท้องถิ่นของตัวเอง ตามที่ฉันเข้าใจ เรามีไดรเวอร์ - อาจมีลูกค้าจำนวนมากที่มีไดรเวอร์ ผู้วางแผนแบบสอบถามด้วย ชาร์ดด้วย... และระบบจะเสียหายอะไรหากเราเกิดความคลาดเคลื่อนกะทันหัน: มีคนตัดสินใจว่ามีไว้สำหรับ นาทีข้างหน้า มีคนช้ากว่านาทีหนึ่งเหรอ? เราจะจบลงที่ไหน?
มอนแทนา: – เป็นคำถามที่ดีจริงๆ! ฉันแค่อยากจะพูดคุยเกี่ยวกับเศษ ถ้าฉันเข้าใจคำถามถูกต้อง เราจะพบสถานการณ์ต่อไปนี้: มีชาร์ด 1 และชาร์ด 2 การอ่านเกิดขึ้นจากชาร์ดทั้งสองนี้ - พวกมันมีความคลาดเคลื่อน พวกมันไม่มีปฏิสัมพันธ์ซึ่งกันและกัน เพราะเวลาที่พวกมันรู้แตกต่างกัน โดยเฉพาะเวลาที่มีอยู่ใน oplogs
สมมติว่าชาร์ด 1 สร้างบันทึกได้ล้านรายการ ชาร์ด 2 ไม่ได้ทำอะไรเลย และคำขอมาถึงสองชาร์ด และอันแรกมี afterClusterTime มากกว่าล้าน ตามที่ฉันอธิบายในสถานการณ์เช่นนี้ ส่วนที่ 2 จะไม่ตอบสนองเลย
ที่: – ฉันต้องการทราบว่าพวกเขาซิงโครไนซ์และเลือกเวลาตรรกะได้อย่างไร
มอนแทนา: - ง่ายมากในการซิงโครไนซ์ Shard เมื่อ afterClusterTime มาหาเขาและเขาไม่พบเวลาใน "Oplog" ก็เริ่มไม่ได้รับการอนุมัติ นั่นคือเขายกเวลาด้วยมือของเขาให้มีค่านี้ ซึ่งหมายความว่าไม่มีเหตุการณ์ที่ตรงกับคำขอนี้ เขาสร้างเหตุการณ์นี้ขึ้นมาอย่างไม่ตั้งใจและด้วยเหตุนี้จึงมีความสอดคล้องเชิงสาเหตุ
ที่: – จะเป็นอย่างไรถ้าหลังจากนี้ มีเหตุการณ์อื่นเกิดขึ้นกับเขาโดยที่หายไปที่ไหนสักแห่งในเครือข่าย?
มอนแทนา: – Shard ได้รับการออกแบบในลักษณะที่จะไม่กลับมาอีก เนื่องจากเป็นปรมาจารย์เพียงคนเดียว ถ้าเขาสมัครแล้วจะไม่มาแต่จะมาทีหลัง เป็นไปไม่ได้ที่จะมีบางอย่างติดอยู่ที่ไหนสักแห่ง จากนั้นเขาก็ไม่เขียน จากนั้นเหตุการณ์เหล่านี้ก็มาถึง - และความสอดคล้องเชิงสาเหตุก็พังทลาย เมื่อเขาไม่เขียน พวกเขาทั้งหมดควรจะมาถัดไป (เขาจะรอพวกเขา)
ที่: – ฉันมีคำถามหลายข้อเกี่ยวกับคิว ความสอดคล้องเชิงสาเหตุถือว่ามีลำดับการดำเนินการเฉพาะที่จำเป็นต้องดำเนินการ จะเกิดอะไรขึ้นหากหนึ่งในแพ็คเกจของเราหายไป? มาแล้ววันที่ 10, 11... วันที่ 12 หายไปแล้ว และคนอื่นๆ ก็รอให้มันเกิดขึ้นจริง แล้วจู่ๆ รถเราก็ดับ เราทำอะไรไม่ได้เลย มีความยาวสูงสุดของคิวที่สะสมก่อนดำเนินการหรือไม่? ความล้มเหลวร้ายแรงใดเกิดขึ้นเมื่อสถานะใดสถานะหนึ่งสูญหาย? ยิ่งไปกว่านั้น ถ้าเราเขียนลงไปว่ามีสถานะก่อนหน้าอยู่บ้าง เราควรเริ่มจากมันด้วยวิธีใด? แต่พวกเขาไม่ได้ผลักเขาออกไป!
มอนแทนา: – เป็นคำถามที่ดีเช่นกัน! เรากำลังทำอะไรอยู่? MongoDB มีแนวคิดเรื่องการเขียนองค์ประชุม การอ่านองค์ประชุม ข้อความอาจสูญหายได้ในกรณีใดบ้าง? เมื่อการเขียนไม่ครบองค์ประชุมหรือเมื่อการอ่านไม่ครบองค์ประชุม (ขยะบางชนิดอาจติด)
ในส่วนของความสอดคล้องเชิงสาเหตุนั้นมีการทดสอบทดลองขนาดใหญ่ ซึ่งผลก็คือในกรณีที่การเขียนและการอ่านไม่ครบองค์ประชุม การละเมิดความสอดคล้องเชิงสาเหตุจะเกิดขึ้น ตรงตามที่คุณพูด!
คำแนะนำของเรา: ใช้การอ่านองค์ประกอบอย่างน้อยเมื่อใช้ความสอดคล้องเชิงสาเหตุ ในกรณีนี้ จะไม่มีอะไรสูญหาย แม้ว่าบันทึกองค์ประชุมจะหายไป... นี่คือสถานการณ์มุมฉาก: หากผู้ใช้ไม่ต้องการให้ข้อมูลสูญหาย เขาจำเป็นต้องใช้บันทึกองค์ประชุม ความสอดคล้องเชิงสาเหตุไม่ได้รับประกันความทนทาน รับประกันความทนทานด้วยการจำลองแบบและเครื่องจักรที่เกี่ยวข้องกับการจำลองแบบ
ที่: – เมื่อเราสร้างอินสแตนซ์ที่ดำเนินการแบ่งส่วนให้เรา (ไม่ใช่ต้นแบบ แต่เป็นทาส ตามลำดับ) มันจะขึ้นอยู่กับเวลา Unix ของเครื่องของตัวเองหรือตามเวลาของ “ต้นแบบ” มันซิงค์เป็นครั้งแรกหรือเป็นระยะ?
มอนแทนา: – ฉันจะชี้แจงตอนนี้ Shard (เช่น พาร์ติชั่นแนวนอน) – จะมีพาร์ติชั่นหลักอยู่ที่นั่นเสมอ และชิ้นส่วนสามารถมี "ผู้เชี่ยวชาญ" และอาจมีแบบจำลองได้ แต่ชาร์ดรองรับการบันทึกเสมอ เนื่องจากต้องรองรับบางโดเมน (ชาร์ดนั้นมีหลัก)
ที่: – ดังนั้นทุกอย่างขึ้นอยู่กับ “เจ้านาย” ล้วนๆ เลยเหรอ? เวลาหลักถูกใช้เสมอหรือไม่?
มอนแทนา: - ใช่. คุณสามารถพูดเป็นรูปเป็นร่างได้ว่า: นาฬิกากำลังฟ้องเมื่อมีการเข้าสู่ "ปรมาจารย์" เข้าสู่ "Oplog" เกิดขึ้น
ที่: – เรามีลูกค้าที่เชื่อมต่อและไม่จำเป็นต้องรู้อะไรเกี่ยวกับเวลาเลย?
มอนแทนา: – คุณไม่จำเป็นต้องรู้อะไรเลย! หากเราพูดถึงวิธีการทำงานบนไคลเอนต์: เมื่อลูกค้าต้องการใช้ความสอดคล้องเชิงสาเหตุ เขาจะต้องเปิดเซสชัน ตอนนี้ทุกอย่างก็พร้อมแล้ว: ธุรกรรมในเซสชัน และการดึงสิทธิ์... เซสชันคือการเรียงลำดับเหตุการณ์เชิงตรรกะที่เกิดขึ้นกับไคลเอนต์
หากเขาเปิดเซสชันนี้และบอกว่าต้องการความสอดคล้องเชิงสาเหตุ (หากเซสชันรองรับความสอดคล้องเชิงสาเหตุตามค่าเริ่มต้น) ทุกอย่างจะทำงานโดยอัตโนมัติ คนขับจะจดจำเวลานี้และจะเพิ่มขึ้นเมื่อได้รับข้อความใหม่ จะจดจำการตอบสนองก่อนหน้านี้ที่ส่งคืนจากเซิร์ฟเวอร์ที่ส่งคืนข้อมูล คำขอถัดไปจะมี afterCluster ("เวลาที่มากกว่านี้")
ลูกค้าไม่จำเป็นต้องรู้อะไรเลย! นี่เป็นสิ่งที่ทึบแสงสำหรับเขาโดยสิ้นเชิง หากผู้คนใช้ฟีเจอร์เหล่านี้ พวกเขาสามารถทำอะไรได้บ้าง? ขั้นแรก คุณสามารถอ่านเนื้อหารองได้อย่างปลอดภัย คุณสามารถเขียนถึงประถมศึกษา และอ่านจากเนื้อหารองที่จำลองตามภูมิศาสตร์ได้ และตรวจสอบให้แน่ใจว่าใช้งานได้ ในเวลาเดียวกัน เซสชันที่บันทึกไว้ในระดับประถมศึกษาสามารถโอนไปยังเซสชันรองได้ กล่าวคือ คุณสามารถใช้ได้มากกว่าหนึ่งเซสชัน แต่หลายเซสชัน
ที่: – เลเยอร์ใหม่ของวิทยาการคอมพิวเตอร์ – ประเภทข้อมูล CRDT (Conflict-free Replicated Data Types) – เกี่ยวข้องอย่างยิ่งกับหัวข้อของความสอดคล้องในที่สุด คุณได้พิจารณาที่จะรวมข้อมูลประเภทนี้เข้ากับฐานข้อมูลแล้วและคุณสามารถพูดอะไรเกี่ยวกับมันได้บ้าง?
มอนแทนา: - คำถามที่ดี! CRDT สมเหตุสมผลสำหรับข้อขัดแย้งในการเขียน: ใน MongoDB, single master
ที่: – ฉันมีคำถามจาก Devops ในโลกแห่งความเป็นจริงมีสถานการณ์นิกายเยซูอิตเมื่อเกิดความล้มเหลวของไบเซนไทน์และผู้ชั่วร้ายภายในขอบเขตที่ได้รับการคุ้มครองเริ่มที่จะยื่นเข้าไปในระเบียบการส่งพัสดุภัณฑ์ด้วยวิธีพิเศษ?
มอนแทนา: – คนชั่วร้ายที่อยู่รอบนอกก็เหมือนม้าโทรจัน! คนชั่วที่อยู่รอบนอกสามารถทำเรื่องเลวร้ายได้มากมาย
ที่: – เห็นได้ชัดว่าการจากไป หรือพูดคร่าวๆ ก็คือหลุมในเซิร์ฟเวอร์ที่คุณสามารถดันสวนสัตว์ช้างและยุบกลุ่มทั้งหมดไปตลอดกาล... มันต้องใช้เวลาในการกู้คืนด้วยตนเอง... พูดง่ายๆ ก็คือ ผิด. ในทางกลับกัน สิ่งนี้น่าสนใจ: ในชีวิตจริง ในทางปฏิบัติ มีสถานการณ์ที่การโจมตีภายในที่คล้ายกันโดยธรรมชาติเกิดขึ้นหรือไม่
มอนแทนา: – เนื่องจากฉันไม่ค่อยพบกับการละเมิดความปลอดภัยในชีวิตจริง ฉันจึงไม่สามารถบอกได้ว่ามันเกิดขึ้นหรือไม่ แต่ถ้าเราพูดถึงปรัชญาการพัฒนา เราก็คิดแบบนี้: เรามีขอบเขตที่ให้คนที่รักษาความปลอดภัย - นี่คือปราสาท กำแพง; และภายในขอบเขตคุณสามารถทำอะไรก็ได้ที่คุณต้องการ เห็นได้ชัดว่ามีผู้ใช้ที่สามารถดูได้เท่านั้น และมีผู้ใช้ที่สามารถลบไดเร็กทอรีได้
ความเสียหายที่ผู้ใช้สามารถทำได้อาจเป็นเมาส์หรือช้างก็ได้ ทั้งนี้ขึ้นอยู่กับสิทธิ์ เป็นที่ชัดเจนว่าผู้ใช้ที่มีสิทธิ์เต็มที่สามารถทำอะไรได้เลย ผู้ใช้ที่มีสิทธิจำกัดสามารถก่อให้เกิดอันตรายน้อยลงอย่างมาก โดยเฉพาะไม่สามารถทำลายระบบได้
ที่: – ในขอบเขตที่ได้รับการป้องกัน มีคนพยายามสร้างโปรโตคอลที่ไม่คาดคิดสำหรับเซิร์ฟเวอร์เพื่อทำลายเซิร์ฟเวอร์โดยสิ้นเชิง และหากคุณโชคดี คลัสเตอร์ทั้งหมด... มันเคย “ดี” ขนาดนั้นหรือไม่?
มอนแทนา: “ฉันไม่เคยได้ยินเรื่องแบบนี้มาก่อน” ความจริงที่ว่าคุณสามารถทำให้เซิร์ฟเวอร์เสียหายได้ด้วยวิธีนี้นั้นไม่เป็นความลับ ล้มเหลวภายใน มาจากโปรโตคอล เป็นผู้ใช้ที่ได้รับอนุญาตซึ่งสามารถเขียนข้อความลักษณะนี้ลงในข้อความ... อันที่จริง มันเป็นไปไม่ได้ เพราะจะยังคงได้รับการตรวจสอบ เป็นไปได้ที่จะปิดการใช้งานการรับรองความถูกต้องนี้สำหรับผู้ใช้ที่ไม่ต้องการ - นั่นคือปัญหาของพวกเขา พูดคร่าวๆ ก็คือ ทำลายกำแพงด้วยตัวเอง และคุณสามารถดันช้างเข้าไป ซึ่งจะเหยียบย่ำ... แต่โดยทั่วไป คุณสามารถแต่งตัวเป็นช่างซ่อม มาดึงมันออกมาได้!
ที่: – ขอบคุณสำหรับรายงาน. เซอร์เกย์ (ยานเดกซ์) มีค่าคงที่ใน Mong ที่จำกัดจำนวนสมาชิกที่ลงคะแนนในชุดแบบจำลอง และค่าคงที่นี้คือ 7 (เจ็ด) เหตุใดจึงเป็นค่าคงที่ เหตุใดจึงไม่ใช่พารามิเตอร์บางประเภท
มอนแทนา: – เรามีชุดแบบจำลองที่มี 40 โหนด มีเสียงส่วนใหญ่อยู่เสมอ ไม่รู้ว่ารุ่นไหน...
ที่: – ใน Replica Set คุณสามารถเรียกใช้สมาชิกที่ไม่ได้ลงคะแนนได้ แต่มีสมาชิกที่ลงคะแนนได้สูงสุด 7 คน เราจะรอดจากการปิดระบบในกรณีนี้ได้อย่างไรหากชุดแบบจำลองของเรากระจายอยู่ในศูนย์ข้อมูล 3 แห่ง ศูนย์ข้อมูลแห่งหนึ่งสามารถปิดได้อย่างง่ายดาย และเครื่องอีกเครื่องอาจหลุดออกมาได้
มอนแทนา: – นี่อยู่นอกเหนือขอบเขตของรายงานเล็กน้อยอยู่แล้ว นี่เป็นคำถามทั่วไป บางทีฉันอาจจะบอกคุณเกี่ยวกับเรื่องนี้ในภายหลัง
โฆษณาบางส่วน🙂
ขอบคุณที่อยู่กับเรา คุณชอบบทความของเราหรือไม่? ต้องการดูเนื้อหาที่น่าสนใจเพิ่มเติมหรือไม่ สนับสนุนเราโดยการสั่งซื้อหรือแนะนำให้เพื่อน , อะนาล็อกที่ไม่เหมือนใครของเซิร์ฟเวอร์ระดับเริ่มต้นซึ่งเราคิดค้นขึ้นเพื่อคุณ: (ใช้ได้กับ RAID1 และ RAID10 สูงสุด 24 คอร์ และสูงสุด 40GB DDR4)
Dell R730xd ถูกกว่า 2 เท่าในศูนย์ข้อมูล Equinix Tier IV ในอัมสเตอร์ดัม? ที่นี่ที่เดียวเท่านั้น ในเนเธอร์แลนด์! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - จาก $99! อ่านเกี่ยวกับ
ที่มา: will.com