MongoDB คืออะไร
MongoDB เป็นฐานข้อมูล NoSQL เชิงเอกสาร ซึ่งหมายความว่ามันเบี่ยงเบนจากโมเดลเชิงสัมพันธ์แบบดั้งเดิมเพื่อนำเสนอโมเดลการปรับขนาดแนวนอนที่ยืดหยุ่นสำหรับการจัดการข้อมูลและการจัดระเบียบ
MongoDB ทำงานกับ AEM อย่างไร
MongoDB ผสานรวมกับ Adobe Experience Manager (AEM) โดยใช้โหมดรัน crx3mongo และตัวเลือก JVM:-Doak.mongo.uri และ -Doak.mongo.db
ทำไมฉันต้อง MongoDB
หลัก MongoDB จัดเตรียมการกำหนดค่า HA สำรองให้กับการกำหนดค่าคลัสเตอร์ CRX ที่เก่ากว่า ในความเป็นจริง สถาปัตยกรรมคล้ายกับแค็ตตาล็อกที่ใช้ร่วมกันบน NFS หรือ NetApp มากกว่าการทำคลัสเตอร์จริง ผู้เขียนและผู้จัดพิมพ์ที่ใช้ MongoDB ไม่จำเป็นต้องรู้จักกัน
ออกไปให้พ้น - การทำคลัสเตอร์ CRX ไม่มีประวัติที่ชัดเจน ความท้าทายโดยธรรมชาติอย่างหนึ่งของแค็ตตาล็อกออบเจ็กต์เฉพาะในเครื่องคือ แคตตาล็อกเดียวมีประโยชน์หลายประการ:
- ลดความซ้ำซ้อนของข้อมูล
- ขอบเขตที่เข้มข้นสำหรับการวิเคราะห์และปรับแต่งประสิทธิภาพ
- ความพร้อมใช้งาน HA โดยไม่ต้องมีการโต้ตอบหลายโหนด
- การปรับขนาดแนวนอนเพื่อความซ้ำซ้อนและประสิทธิภาพ
แม้จะมีคลัสเตอร์ CRX ที่ทำงานได้อย่างสมบูรณ์ ประโยชน์เหล่านี้ไม่ได้รับการแก้ไข ป้อนวันที่เก่ามากของระดับข้อมูลที่แชร์
ด้วย 5.6.1 และรุ่นก่อนหน้า การปรับใช้ที่มีขนาดใหญ่และเติบโตสามารถเมานต์ objectrepository ของพวกเขาเป็น NFS ที่ใช้ร่วมกัน โดยที่โปรโตคอลหรือเซิร์ฟเวอร์ NFS ให้การสนับสนุนการล็อกสำหรับพฤติกรรมการเขียนหลายรายการที่มีการชนกันต่ำ นี่ยังคงเป็นตัวเลือกที่ใช้งานได้ แต่มักจะมีความเสี่ยงที่จะเกิดความล้มเหลวเพียงจุดเดียวในตัวควบคุม หรือระดับข้อมูล เว้นแต่ว่าจะใช้ NetApp ที่คอยยับยั้งสถาปัตยกรรม n*9
การแนะนำไมโครเคอร์เนล MongoDB ลงใน AEM 6.x ทำให้เกิดสถาปัตยกรรมเดียวกันกับฐานข้อมูลที่มีคำศัพท์มากมายที่เราชื่นชอบ
กรณีการใช้งานหลักสำหรับ MongoMK คือกับอินสแตนซ์ของผู้สร้าง AEM โดยที่ขีดจำกัดผู้ใช้ที่ใช้งานอยู่ (~25-30) หมายความว่าการปรับขนาดแนวนอนต้องแก้ไขปัญหาการทำงานพร้อมกันก่อน ในที่นี้ ระดับข้อมูลที่แชร์จะสว่างที่สุดเนื่องจากประสิทธิภาพเป็นปัจจัยรองในการปรับขนาดและความสม่ำเสมอในขณะเดียวกันก็ขจัดความจำเป็นในการสื่อสารระหว่างโหนดกับโหนด
เป็นไปได้อย่างแน่นอนที่จะยังคงเข้าร่วมกับผู้จัดพิมพ์ในลักษณะเดียวกัน อย่างไรก็ตาม ผลประโยชน์จะลดลงเนื่องจากไม่มีปัญหาการทำงานพร้อมกัน (เช่น เพียงเพิ่มผู้จัดพิมพ์มากขึ้นสำหรับขนาดที่มากขึ้น) และบทลงโทษด้านประสิทธิภาพของแค็ตตาล็อกที่ไม่ใช่ท้องถิ่น
แค่นั้นเอง! ขยายไปสู่ความไม่มีที่สิ้นสุด!
ช้าลงหน่อย Buzz Lightyear มีปัญหา คาดว่า MongoDB ไซต์เดียวจะปรับขนาดได้อย่างมีประสิทธิภาพมาก เนื่องจากมีตัวเลือกสำหรับข้อมูลที่เข้าถึงอย่างรวดเร็วและเครือข่ายอินไลน์ ที่นี่ท้องฟ้าอาจเป็นขีดจำกัด อย่างไรก็ตาม ให้พิจารณาถึงการปรับใช้แบบหลายไซต์ที่ MongoDB เรพลิกาต้องสื่อสารข้ามศูนย์ข้อมูลที่แตกต่างกันและไฟเบอร์ที่ไม่รู้จัก ป้อนบันทึกการดำเนินการ (oplog)
oplog เป็นตัวกลางสำหรับการจำลองที่ยังคงซิงโครไนซ์ โดยพื้นฐานแล้วให้ชุดของการดำเนินการเดลต้าเพื่อนำไปใช้ตามลำดับ ซึ่งค่อนข้างคล้ายกับการกำหนดค่าคลัสเตอร์ฐานข้อมูลอื่นบางอย่าง
ระหว่างการดำเนินการที่ปรับให้เหมาะสมที่สุด oplog จะดำเนินการใกล้เคียงกับเรียลไทม์โดยมีค่าหลักที่เป็นไปได้ แม้ว่า MongoDB จะอนุญาตให้ลอยได้ อย่างไรก็ตาม ระหว่างการดำเนินการแบบหลายไซต์ การบอกลวดและเวลาในการตอบสนองของการดำเนินการสามารถซ้อนกันเพื่อทำให้เกิดการเบี่ยงเบนที่มากขึ้น และนำเสนอความท้าทายต่อไปนี้ในการกำหนดค่านี้:
- oplog เป็นชุดคำสั่งตามหน้าที่
- เหมือนหลายๆ กอง เข้าก่อน-ออกก่อน
- พฤติกรรมของสแต็กกำหนดว่าเมื่อการกดครั้งต่อไปจะเขียนทับเร็กคอร์ดที่ไม่ได้เปิด การสูญหายของข้อมูลจะเกิดขึ้น
โปรแกรมเมอร์ MongoDB ได้เลือกที่จะตรวจจับและจัดการกับสถานการณ์นี้โดยให้เรพลิคาฮอลท์ สร้างใหม่ และซิงค์ไปข้างหน้าจาก oplog (ใหม่) หลังจากสร้างใหม่
บนพื้นผิว ไม่มีอะไรแปลกใหม่หรืออันตรายเกี่ยวกับการดำเนินการนี้ พิจารณาก่อนสร้างการดำเนินการ ซึ่งจะล้างข้อมูลทั้งหมดแล้วดึงสำเนาใหม่จากที่รู้จัก goodprimary แม้ว่าการส่งออกจะใช้เวลาศูนย์วินาทีในการดำเนินการให้เสร็จสมบูรณ์ สำเนาของปริมาณข้อมูลในสายแฝงจะทำให้เกิดการเลื่อนโดยเนื้อแท้ก่อนที่แบบจำลองระยะไกลจะนำเข้าเสร็จเท่ากัน สมมติว่าเวลาแฝงของสายเป็นความท้าทายเพียงอย่างเดียว ดังนั้น Afterrebuild oplog จะมีเฉพาะการดริฟท์ที่แนะนำโดยการสร้างใหม่เท่านั้น ปัญหาเดิมที่ทำให้เกิดความล่าช้าในการจำลองแบบยังคงอยู่ ดังนั้น เมื่อเวลาผ่านไป ตัวรองที่สร้างขึ้นใหม่จะถูกบังคับให้สร้างใหม่อีกครั้ง
ในบางกรณี ลักษณะการทำงานนี้จะเข้าสู่ลูปของการจำลองแบบที่ล่าช้าและสร้างใหม่อย่างไม่รู้จบ ซึ่งส่งผลให้รีโมตรองซึ่งไม่เคยอยู่ในสถานะใช้งานได้
สำหรับ AEM นี่หมายความว่าการใช้แบบจำลอง MongoDB เป็นแหล่งข้อมูลหลักสำหรับการเขียนข้ามไซต์ทำให้ผู้เขียนระยะไกลมีความเสี่ยงสูง
