MongoDB là gì?
MongoDB, trong số những điều khác, là một document-oriented NoSQL database (cơ sở dữ liệu NoSQL hướng tài liệu). Điều này có nghĩa là nó lệch khỏi mô hình quan hệ truyền thống để trình bày một mô hình linh hoạt, mở rộng ngang (horizontally scaling) cho quản lý và tổ chức dữ liệu.
MongoDB làm việc với AEM như thế nào?
MongoDB tích hợp với Adobe Experience Manager (AEM) thông qua crx3mongo runmode và JVM options: -Doak.mongo.uri và -Doak.mongo.db
Tại sao tôi lại dùng MongoDB?
Chủ yếu MongoDB cung cấp một cấu hình HA (High Availability) thay thế cho cấu hình CRX cluster cũ hơn. Thực tế, kiến trúc này giống hơn với shared catalog trên NFS hoặc NetApp hơn là true clustering (clustering thực sự). Các author và publisher dùng MongoDB không nhất thiết nhận biết nhau.
Hãy nói rõ - CRX clustering không có track record (lịch sử) hoàn hảo. Một trong những thách thức cố hữu của local-only object catalog là ở quy mô lớn, một catalog đơn lẻ trình bày một số lợi ích:
- Giảm trùng lặp dữ liệu
- Phạm vi tập trung cho phân tích và tuning hiệu suất
- HA availability (sẵn sàng cao) không yêu cầu multi-node interaction
- Mở rộng ngang (horizontal scaling) cho redundancy và hiệu suất
Ngay cả với một CRX cluster hoạt động hoàn hảo, không có lợi ích nào trên được giải quyết. Chào đón những ngày cũ của shared data tier (tier dữ liệu chia sẻ).
Với 5.6.1 và trước đó, các triển khai lớn và đang phát triển có thể mount object repository của họ như shared NFS, nơi protocol hoặc NFS server cung cấp locking support cho multi-write behavior với low collision (va chạm thấp). Đây vẫn là một lựa chọn khả thi, nhưng trừ khi dùng NetApp, thường có rủi ro single point of failure (điểm lỗi đơn lẻ) ở controller, hoặc data tier, giữ lại kiến trúc n*9.
Sự giới thiệu của MongoDB microkernel vào AEM 6.x cung cấp về cơ bản cùng kiến trúc với database nhiều buzzword hơn mà chúng ta yêu thích.
Use-case (trường hợp sử dụng) chính cho MongoMK là với AEM author instances, nơi giới hạn active user (~25-30) có nghĩa là horizontal scaling phải giải quyết vấn đề concurrency (đồng thời) trước. Tại đây, shared data tier sáng rực nhất vì hiệu suất nhường chỗ cho scale và consistency trong khi đồng thời loại bỏ nhu cầu node-to-node communication.
Chắc chắn có thể vẫn join publishers theo cách tương tự, tuy nhiên, lợi ích giảm do thiếu vấn đề concurrency (ví dụ: chỉ thêm publishers cho scale hơn) và performance penalty (phạt hiệu suất) của non-local catalog.
Vậy là xong! Scale đến vô tận và xa hơn!
Chậm lại, Buzz Lightyear, có một vấn đề. Single-site MongoDB được kỳ vọng scale rất hiệu quả nhờ tùy chọn fast-access data và in-line networking. Ở đây, bầu trời có thể là giới hạn. Cân nhắc, tuy nhiên, một multi-site deployment nơi MongoDB replica sets phải giao tiếp qua các data centers khác nhau và dặm fiber optic không xác định. Chào operations log (oplog).
Oplog là trung gian cho replicas để giữ synchronized (đồng bộ); về cơ bản cung cấp một chuỗi delta operations được áp dụng theo thứ tự. Điều này khá tương tự một số cấu hình database cluster khác.
Trong optimized operation, oplog được thực thi gần realtime với primary nhất có thể, mặc dù MongoDB cho phép drift (trôi). Trong multi-site operation, tuy nhiên, wire latency và operation latency có thể chồng chất (stack) để giới thiệu drift lớn hơn và trình bày các thách thức sau cho cấu hình này:
- Oplog về chức năng là một stack của commands.
- Giống nhiều stack, nó là first-in - first-out.
- Hành vi stack quy định rằng, khi next push sẽ ghi đè un-popped record, data loss (mất dữ liệu) sẽ xảy ra.
Các lập trình viên MongoDB đã chọn bắt (catch) và giải quyết tình huống này bằng cách khiến replica halt (dừng), rebuild (tái xây dựng), và sync forward từ (new) oplog sau khi rebuild.
Trên bề mặt, không có gì exotic (đặc biệt) hoặc dangerous (nguy hiểm) về operation này. Cân nhắc trước rebuild operation, xóa tất cả dữ liệu và sau đó pull bản sao mới từ primary known-good. Ngay cả khi export mất 0 giây để hoàn thành, bản sao data volume qua latent wire sẽ inherent (tự nhiên) giới thiệu drift trước khi remote replica thậm chí hoàn thành import. Giả sử wire latency là thách thức duy nhất, nên sau rebuild, oplog chỉ chứa drift do rebuild giới thiệu. Vấn đề gốc gây replication lag vẫn còn, nên có thể kỳ vọng rằng, theo thời gian, secondary mới xây dựng sẽ bị buộc phải rebuild lại.
Trong một số trường hợp, hành vi này tiến vào vòng lặp không kết thúc của replication lag và rebuild, dẫn đến remote secondaries không bao giờ ở trạng thái functional.
Đối với AEM, điều này có nghĩa là việc dùng MongoDB replicas làm primary data source cho cross-site authoring đặt remote authors ở rủi ro đáng kể.