MongoDB란 무엇입니까?
MongoDB는 무엇보다도 문서 지향 NoSQL 데이터베이스입니다. 즉, 기존의 관계형 모델에서 벗어나 데이터 관리 및 구성을 위한 유연하고 수평적인 확장 모델을 제시합니다.
MongoDB는 AEM과 어떻게 작동합니까?
MongoDB는 crx3mongo runmode 및 JVM 옵션(-Doak.mongo.uri 및 -Doak.mongo.db
)을 통해 Adobe Experience Manager(AEM)와 통합됩니다.내가 MongoDB를 사용해야 하는 이유
주로 MongoDB는 이전 CRX 클러스터 구성에 대체 HA 구성을 제공합니다. 실제로 아키텍처는 실제 클러스터링보다 NFS 또는 NetApp의 공유 카탈로그와 더 유사합니다. MongoDB를 사용하는 저자와 게시자는 서로를 알 필요가 없습니다.
방해가 되지 않도록 합시다. CRX 클러스터링에는 흠잡을 데 없는 실적이 없습니다. 로컬 전용 개체 카탈로그의 고유한 문제 중 하나는 규모에 따라 단일 카탈로그가 다음과 같은 여러 이점을 제공한다는 것입니다.
- 데이터 중복 감소
- 성능 분석 및 조정을 위한 집중 범위
- 다중 노드 상호 작용이 필요 없는 HA 가용성
- 이중화 및 성능을 위한 수평적 확장
완벽하게 작동하는 CRX 클러스터가 있더라도 이러한 이점이 해결되지 않습니다. 공유 데이터 계층의 구시대를 맞이하십시오.
5.6.1 및 이전 버전에서는 대규모의 배포가 증가하는 경우 개체 저장소를 공유 NFS로 마운트할 수 있으며, 여기서 프로토콜 또는 NFS 서버는 충돌이 적은 다중 쓰기 동작에 대한 잠금 지원을 제공했습니다. 이것은 여전히 실행 가능한 옵션이지만 NetApp을 사용하지 않는 한 n*9 아키텍처를 억제하는 컨트롤러 또는 데이터 계층에서 단일 실패 지점의 위험이 있는 경우가 많습니다.
AEM 6.x에 MongoDB 마이크로커널을 도입함으로써 우리가 좋아하는 더 유행어가 많은 데이터베이스와 본질적으로 동일한 아키텍처를 제공합니다.
MongoMK의 주요 사용 사례는 AEM 작성자 인스턴스를 사용하는 것입니다. 여기서 활성 사용자 제한(~25-30)은 수평적 확장이 먼저 동시성 문제를 해결해야 함을 의미합니다. 여기서 공유 데이터 계층은 성능이 확장성과 일관성을 유지하는 동시에 노드 간 통신의 필요성을 제거하기 때문에 가장 빛을 발합니다.
여전히 유사한 방식으로 게시자에 합류하는 것이 가능하지만 동시성 문제가 부족하고(즉, 더 많은 규모를 위해 게시자를 추가하면 됨) 로컬 카탈로그가 아닌 경우 성능 저하로 인해 이점이 줄어듭니다.
그럼 그게 다야! 무한대 이상으로 확장하세요!
천천히 하세요, 버즈 라이트이어, 문제가 있습니다. 단일 사이트 MongoDB는 빠른 액세스 데이터 및 인라인 네트워킹 옵션을 고려할 때 매우 효과적으로 확장될 것으로 예상됩니다. 여기, 하늘이 한계일 수 있습니다. 그러나 MongoDB 복제본 세트가 서로 다른 데이터 센터와 알 수 없는 마일의 광섬유 간에 통신해야 하는 다중 사이트 배포를 고려하십시오. 작업 로그(oplog)를 입력합니다.
oplog는 복제본이 동기화된 상태를 유지하는 중개자입니다. 기본적으로 순서대로 적용할 일련의 델타 연산을 제공합니다. 이는 특정 다른 데이터베이스 클러스터 구성과 상당히 유사합니다.
최적화된 작업 동안, MongoDB는 드리프트를 허용하지만 oplog는 가능한 한 기본적으로 실시간에 가깝게 실행됩니다. 그러나 다중 사이트 작업 중에는 와이어 지연 시간과 작업 지연 시간이 누적되어 더 큰 드리프트가 발생하고 이 구성에 다음과 같은 문제가 발생할 수 있습니다.
- oplog는 기능적으로 명령 스택입니다.
- 많은 스택과 마찬가지로 선입선출 방식입니다.
- 스택 동작에 따라 다음 푸시가 팝되지 않은 레코드를 덮어쓸 때 데이터 손실이 발생합니다.
MongoDB 프로그래머는 재구축 후 (새) oplog에서 복제본을 중지, 재구축 및 동기화하여 이 상황을 포착하고 해결하기로 결정했습니다.
표면적으로는 이 작업에 대해 이국적이거나 위험한 것이 없습니다. 먼저 모든 데이터를 지우고 알려진 양호한 기본에서 새 복사본을 가져오는 다시 빌드 작업을 고려하십시오. 내보내기를 완료하는 데 0초가 걸리더라도 원격 복제본이 가져오기를 완료하기 전에 잠재 와이어를 통해 데이터 볼륨을 복사하면 본질적으로 드리프트가 발생합니다. 또한 유선 대기 시간이 유일한 문제라고 가정하여 재구축 후 oplog에는 재구축에 의해 도입된 드리프트만 포함됩니다. 복제 지연을 유발한 원래 문제가 남아 있으므로 시간이 지남에 따라 새로 구축된 보조 시스템이 강제로 다시 구축될 것으로 예상할 수 있습니다.
경우에 따라 이 동작은 복제 지연 및 재구축의 끝없는 루프에 들어가 원격 보조 장치가 작동 상태가 아닌 원격 보조 장치가 되는 경우가 있습니다.
AEM의 경우 이는 MongoDB 복제본을 교차 사이트 작성을 위한 기본 데이터 소스로 사용하면 원격 작성자가 심각한 위험에 처할 수 있음을 의미합니다.