home

หน้าแรก
 Computer >> บทช่วยสอนคอมพิวเตอร์ >  >> การเขียนโปรแกรม >> ฐานข้อมูล

ทำไม MongoDB จึงเพิ่มประสิทธิภาพ Adobe Experience Manager: คู่มือปฏิบัติ

MongoDB คืออะไร?

MongoDB เป็น Document-oriented NoSQL Database ไม่ใช้ Relational Model แทนด้วย Flexible, Horizontally Scaling Model สำหรับ Data Management และ Organization

MongoDB ทำงานกับ AEM อย่างไร?

Integrate กับ Adobe Experience Manager (AEM) ผ่าน crx3mongo Runmode และ JVM Options: -Doak.mongo.uri และ -Doak.mongo.db

ทำไมต้อง MongoDB?

หลัก: ให้ Alternate HA Configuration แทน CRX Cluster Configuration เก่า จริงๆ Architecture ใกล้เคียง Shared Catalog บน NFS หรือ NetApp มากกว่า True Clustering Authors และ Publishers ที่ใช้ MongoDB ไม่จำเป็นต้อง Aware ของกันและกัน

ปัญหา CRX Clustering

CRX Clustering Track Record ไม่สะอาด Local-only Object Catalog ที่ Scale ใหญ่ Single Catalog ให้ Benefits:

  • ลด Data Duplication
  • Concentrated Scope สำหรับ Performance Analysis/Tuning
  • HA Availability โดยไม่ต้อง Multi-node Interaction
  • Horizontal Scaling สำหรับ Redundancy และ Performance

CRX Cluster ที่ทำงานสมบูรณ์ก็ไม่ Address Benefits นี้ → Shared Data Tier Era

Shared NFS (Pre-5.6.1)

Mount Object Repository เป็น Shared NFS Protocol/NFS Server ให้ Locking Support Multi-write Behavior Low Collision ยังเป็น Option ที่ viable แต่ Single Point of Failure ใน Controller/Data Tier บล็อก n*9 Architecture

MongoDB Microkernel ใน AEM 6.x

Architecture เดียวกันแต่ด้วย Database ที่ Buzzword-heavy กว่า Primary Use-case: AEM Author Instances Active User Limit (~25-30) Horizontal Scaling ต้องแก้ Concurrency Issue ก่อน Shared Data Tier ส่องสว่าง: Performance อันดับ 2 Scale/Consistency อันดับ 1 Eliminate Node-to-node Communication

Publishers Join แบบเดียวกันได้ แต่ Benefits น้อยกว่า (No Concurrency Issue - เพิ่ม Publishers ก็ Scale ได้) และ Performance Penalty ของ Non-local Catalog

ปัญหา: Multi-site Deployment และ Oplog

Single-site MongoDB Scale ได้ดี (Fast-access Data, In-line Networking) แต่ Multi-site: MongoDB Replica Sets Communicate Across Data Centers → Operations Log (Oplog) เป็นปัญหา

Oplog = Intermediary สำหรับ Replicas Sync ให้ Delta Operations Applied In-order คล้าย Database Cluster Configs อื่นๆ

Optimized Operation:

Oplog Executed ใกล้ Real-time กับ Primary MongoDB Permit Drift

Multi-site Operation Challenges:

  • Wire Latency + Operation Latency = Greater Drift
  • Oplog = Stack of Commands (First-in, First-out)
  • Next Push Overwrite Un-popped Record = Data Loss

MongoDB จัดการ: Replica Halt, Rebuild, Sync Forward จาก New Oplog หลัง Rebuild

ปัญหา Rebuild Loop:

  1. Rebuild: Wipe Data, Pull Fresh Copy จาก Primary
  2. Copy Data Volume Across Latent Wire = Drift ก่อน Import เสร็จ
  3. Original Replication Lag Cause ยังคงอยู่ → Secondary ถูก Force Rebuild ซ้ำ
  4. Unending Loop: Replication Lag → Rebuild → Drift → Rebuild → Remote Secondaries ไม่เคย Functional State

สำหรับ AEM: ใช้ MongoDB Replicas เป็น Primary Data Source สำหรับ Cross-site Authoring → Remote Authors อยู่ในความเสี่ยงสูง

สรุป

MongoDB ให้ HA Alternative สำหรับ AEM Authors ดี แต่ Multi-site Deployments ต้องระวัง Oplog Replication Lag และ Rebuild Loops ที่ทำให้ Remote Secondaries ไม่ Functional วางแผน Architecture ให้เหมาะสมกับ Use Case และ Geography