[mongodb] MongoDB의 다중 테넌트 데이터베이스에 대해 권장되는 접근 방식은 무엇입니까?

해결해야 할 동일한 문제가 있으며 변형도 고려합니다. 수년간 SaaS 다중 테넌트 애플리케이션을 만든 경험이 있으므로 관계형 데이터베이스에 대한 이전 경험을 기반으로 두 번째 옵션을 선택하려고했습니다.

내 연구를하고있는 동안 나는 (방법은 다시는 사라 이후 추가) MongoDB를 지원 사이트에이 기사를 발견 :
https://web.archive.org/web/20140812091703/http://support.mongohq.com/use-cases/multi -tenant.html

사람들은 어떤 대가를 치르더라도 두 번째 옵션을 피하라고 말했는데, 내가 이해하는 것처럼 mongodb에만 국한되지 않습니다. 내 인상은 이것이 데이터베이스 설계의 특성으로 인해 내가 조사한 대부분의 NoSQL db (CoachDB, Cassandra, CouchBase Server 등)에 적용 가능하다는 것입니다.

컬렉션 (또는 버킷 또는 다른 DB에서 호출)은 좋은 테넌트 분리를 적용하는 데 쓸모가없는 문서의 컨테이너로 작동하지만 RDBMS의 보안 스키마와 동일하지 않습니다. 컬렉션에 따라 보안 제한을 적용 할 수있는 NoSQL 데이터베이스를 찾을 수 없습니다.

물론 mongodb 역할 기반 보안을 사용하여 데이터베이스 / 서버 수준에서 액세스를 제한 할 수 있습니다. ( http://docs.mongodb.org/manual/core/authorization/ )

다음과 같은 경우 첫 번째 옵션을 권장합니다.

• 이 시나리오의 설계, 구현 및 테스트의 복잡성을 처리 할 수있는 충분한 시간과 리소스가 있습니다.
• 다른 테넌트에 대한 데이터베이스의 구조와 기능에 큰 차이가 없을 경우.
• 애플리케이션 설계를 통해 테넌트는 런타임에 최소한의 사용자 지정 만 수행 할 수 있습니다.
• 공간을 최적화하고 하드웨어 리소스 사용을 최소화하려는 경우.
• 수천 명의 세입자가있을 경우.
• 빠르고 좋은 비용으로 확장하려는 경우.
• 테넌트를 기반으로 데이터를 백업하지 않을 경우 (각 테넌트에 대해 별도의 백업을 유지하십시오). 이 시나리오에서도 가능하지만 노력은 엄청날 것입니다.

다음과 같은 경우 변형 3을 사용합니다.

• 작은 세입자 목록 (수백 명)을 갖게 될 것입니다.
• 비즈니스의 특성상 서로 다른 테넌트에 대한 데이터베이스 구조의 큰 차이를 지원할 수 있어야합니다 (예 : 타사 시스템과의 통합, 데이터 가져 오기-내보내기).
• 애플리케이션 설계를 통해 고객 (테넌트)은 애플리케이션 런타임을 크게 변경할 수 있습니다 (모듈 추가, 필드 사용자 지정 등).
• 새 하드웨어 노드로 빠르게 확장 할 수있는 충분한 리소스가있는 경우.
• 테넌트 당 데이터 버전 / 백업을 유지해야하는 경우. 또한 복원이 쉽습니다.
• 다른 데이터베이스 (데이터 센터 포함)에 다른 테넌트를 유지하도록 강제하는 법적 / 규제 적 제한이 있습니다.
• 역할과 같은 mongodb의 기본 보안 기능을 완전히 활용하려는 경우.
• 세입자 간에는 크기 문제에 큰 차이가 있습니다 (작은 세입자는 많고 매우 큰 세입자는 거의 없음).

신청서에 대한 추가 정보를 게시하면 더 자세한 조언을 드릴 수 있습니다.