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

MongoDB를 사용하여 다중 테넌트 앱을 만들려고합니다. 아직 얼마나 많은 테넌트가 있었는지 추측 할 수는 없지만 수천 명으로 확장 할 수 있기를 바랍니다.

세 가지 전략을 생각할 수 있습니다.

1. 보안을 위해 테넌트 별 필드를 사용하는 동일한 컬렉션의 모든 테넌트
2. 단일 공유 DB에서 테넌트 당 1 개의 컬렉션
3. 테넌트 당 데이터베이스 1 개

내 머릿속의 목소리는 내가 옵션 2로 가라는 것을 암시합니다.

생각과 함의, 누구?

해결해야 할 동일한 문제가 있으며 변형도 고려합니다. 수년간 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의 기본 보안 기능을 완전히 활용하려는 경우.
• 세입자 간에는 크기 문제에 큰 차이가 있습니다 (작은 세입자는 많고 매우 큰 세입자는 거의 없음).

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

이 링크의 의견에서 좋은 답변을 찾았습니다.

http://blog.boxedice.com/2010/02/28/notes-from-a-production-mongodb-deployment/

기본적으로 옵션 # 2가 가장 좋은 방법 인 것 같습니다.

David Mytton의 의견에서 인용 :

MongoDB가 데이터 파일을 할당하는 방식 때문에 고객 당 데이터베이스를 가지지 않기로 결정했습니다. 각 데이터베이스는 자체 파일 세트를 사용합니다.

데이터베이스의 첫 번째 파일은 dbname.0이고 dbname.1 등입니다. dbname.0은 64MB, dbname.1 128MB 등이며 최대 2GB입니다. 파일 크기가 2GB에 도달하면 연속되는 각 파일도 2GB가됩니다.

따라서 존재하는 마지막 데이터 파일이 1GB 인 경우 최근에 도달 한 경우 해당 파일은 90 % 비어있을 수 있습니다.

설명서에서.

사용자가 평가판에 등록하고 작업을 진행하면 데이터 파일 전체가 사용되지 않더라도 크기가 2GB 이상인 데이터베이스가 점점 더 많아집니다. 효율성을 극대화하기 위해 디스크 공간을 사용할 수있는 모든 고객을 위해 여러 데이터베이스를 사용하는 것과 비교했을 때 이것이 막대한 디스크 공간을 사용한다는 사실을 발견했습니다.

샤딩은 표준으로 컬렉션 단위로 이루어지며, 이는 상당수의 경우와 마찬가지로 컬렉션이 샤딩을 시작하기위한 최소 크기에 도달하지 않는 문제를 나타냅니다 (예 : 사용자 로그인 세부 정보 만 저장하는 컬렉션). 그러나 우리는 이것이 또한 데이터베이스 수준에서 수행 될 수 있도록 요청했습니다. http://jira.mongodb.org/browse/SHARDING-41 참조

많은 컬렉션을 사용하는 성능 균형은 없습니다. 참조 http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections를

이 멀티 테넌트 (multi-tenant) 데이터 아키텍처에 대한 MSDN에 합리적인 기사 당신이 참조 할 수 있습니다. 이 기사에서 다루는 몇 가지 주요 주제 :

• 경제적 고려 사항
• 보안
• 테넌트 고려 사항
• 규제 (법적)
• 스킬 세트 문제

SaaS (Software as a Service) 구성에 대한 몇 가지 패턴도 다룹니다.

또한 SQL Anywhere 녀석의 흥미로운 글이 있습니다.

내 개인적인 견해-강화 된 보안 / 신뢰에 대해 확신하지 않는 한, 옵션 3을 선택하거나 확장 성 문제로 인해 최소한 옵션 2 로의 대체가 금지되는 경우. 즉 ... 저는 MongoDB의 프로가 아닙니다. 공유 된 "스키마"를 사용하면 상당히 긴장되지만 더 경험이 많은 실무자에게 기꺼이 미루겠습니다.

옵션 2를 선택하겠습니다.

그러나 mongod.exe 명령 줄 옵션 --smallfiles를 설정할 수 있습니다. 즉, 익스텐트의 가장 큰 파일 크기는 2GB가 아니라 0.5GB입니다. 나는 이것을 mongo 1.42로 테스트했습니다. 따라서 옵션 3은 불가능하지 않습니다.

MongoDB 에 대한 내 연구에 따르면 . Trucos y consejos. Aplicaciones 멀티 테넌트. 이 옵션은 보유 할 수있는 테넌트 수를 모르는 경우 권장되지 않습니다. 수천 개가 될 수 있으며 분할과 관련하여 복잡 할 수 있습니다. 또한 단일 데이터베이스에 수천 개의 컬렉션이 있다고 상상해보십시오. 옵션 1을 사용하는 것이 좋습니다. 이제 제한된 수의 사용자를 가질 예정이라면 이미 다르며 네, 생각대로 옵션 2를 사용할 수 있습니다.

여기 토론 NoSQL에 주로 MongoDB를에있는 동안, 우리 Citus는 PostgreSQL의를 사용하여 분산 / 분산됩니다 멀티 테넌트 (multi-tenant) 데이터베이스를 구축하고있다.

우리의 사용 사례 가이드는 스키마와 다양한 멀티 테넌트 (multi-tenant)의 특정 기능을 포함, 예제 응용 프로그램을 통해 안내합니다.

더 많은 비정형 데이터의 경우 PostgreSQL의 JSONB 열을 사용하여 이러한 데이터와 테넌트 별 데이터를 저장합니다.