MongoDB의 멀티 테넌트(Multi-tenant) 데이터베이스에 대해 권장되는 접근 방식은 무엇입니까?

MongoDB의 멀티 테넌트(Multi-tenant) 데이터베이스에 대해 권장되는 접근 방식은 무엇입니까?

MongoDB를 사용하여 멀티 테넌트(Multi-tenant) 앱을 만들려고 합니다.세입자가 몇 명이나 될지 아직 짐작이 가지 않지만, 수천 명까지 확장할 수 있으면 좋겠습니다.

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

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

머릿속의 목소리가 2번 옵션을 선택하라고 제안하고 있습니다.

생각이나 시사점은요?

저도 해결해야 할 같은 문제가 있고, 변종도 고려하고 있습니다.저는 SaaS 멀티 테넌트(Multi-tenant) 애플리케이션을 수년간 만들어 왔기 때문에 관계형 데이터베이스에 대한 이전의 경험을 바탕으로 두 번째 옵션을 선택하려고 했습니다.

조사 중에 mongodb 서포트 사이트에서 이 기사를 발견했습니다(사후 훨씬 이전부터 추가).https://web.archive.org/web/20140812091703/http : //support.mongohq.com/use-cases/multi-tenant.html

남자들은 두 번째 옵션은 무조건 피하라고 했는데, 제가 알기로는 특별히 mongodb에만 국한된 것은 아닙니다.제가 조사한 NoSQL dbs의 대부분(CoachDB, Cassandra, CouchBase Server 등)은 데이터베이스 설계의 특이성 때문에 해당됩니다.

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

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

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

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

다음과 같은 경우 Variant 3을 선택합니다.

• 적은 수의 세입자 명단(수 백 명)을 갖게 될 것입니다.
• 비즈니스 세부 사항에서는 테넌트별로 데이터베이스 구조의 큰 차이(서드파티 시스템과의 통합, 데이터 Import/export 등)를 지원할 수 있어야 합니다.
• 애플리케이션 설계에 따라 고객(테넌트)은 애플리케이션 런타임에 상당한 변경을 가할 수 있습니다(모듈 추가, 필드 맞춤 등).
• 새로운 하드웨어 노드로 신속하게 스케일아웃할 수 있는 리소스가 충분한 경우.
• 테넌트당 데이터 버전/백업을 유지해야 하는 경우복원도 간단합니다.
• 다른 데이터베이스(데이터센터까지)에 다른 테넌트를 보관해야 하는 법적/규제의 제약이 있습니다.
• 역할과 같은 mongodb의 기본 제공 보안 기능을 최대한 활용하려는 경우
• 세입자마다 크기 차이가 크다(소규모 세입자는 많고 매우 큰 세입자는 적다).

지원서에 대한 자세한 내용을 게시해 주시면 제가 더 자세한 조언을 해드릴 수 있을 것 같습니다.

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

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

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

David Mytton의 코멘트에서 인용:

MongoDB의 데이터 파일 할당 방식 때문에 고객 1인당 데이터베이스를 보유하지 않기로 했습니다.각 데이터베이스는 자체 파일 집합을 사용합니다.

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

따라서 마지막 데이터 파일이 1GB인 경우 최근에 도달한 경우 파일이 90% 비었을 수 있습니다.

매뉴얼을 참조해 주세요.

사용자가 평가판에 등록하고 작업을 시작하면 데이터 파일 전체를 사용하지 않더라도 최소 2GB 크기의 데이터베이스가 점점 더 많아질 것입니다.모든 고객을 위해 여러 데이터베이스를 사용하는 데 비해 디스크 공간을 최대한 효율적으로 사용할 수 있는 경우에는 디스크 공간이 매우 많이 사용되었습니다.

Sharding은 컬렉션별로 표준으로 제공되며, 이는 수집이 샤딩을 시작하기 위한 최소 크기에 도달하지 않는 문제를 야기합니다(예: 사용자 로그인 세부 정보를 저장하는 컬렉션).단, 데이터베이스 단위에서도 이 작업을 수행할 수 있도록 요청했습니다.http://jira.mongodb.org/browse/SHARDING-41 를 참조해 주세요.

많은 컬렉션을 사용하는 퍼포먼스 트레이드오프는 없습니다.http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections 를 참조해 주세요.

MSDN에는 멀티 테넌트(Multi-tenant) 데이터 아키텍처에 관한 타당한 기사가 있습니다.참조할 수 있습니다.이 기사에서 다룬 주요 토픽:

• 경제적 고려사항
• 보안.
• 세입자에 관한 고려 사항
• 법령 준수(법률)
• 스킬에 관한 문제

또, SaaS(Software as a Service) 설정의 패턴도 몇개인가 소개합니다.

게다가 SQL Anywhere의 흥미로운 기사도 볼만합니다.

개인적인 견해입니다.강제적인 보안/신뢰가 확실치 않다면 옵션 3으로 하겠습니다.또는 scalability 문제로 옵션2로의 폴백이 최소한 방해되는 경우는 옵션 3으로 하겠습니다.그 말은...난 MongoDB를 잘 몰라공유된 "스케마"를 사용하면 상당히 긴장되지만, 더 경험이 많은 실무자에게 기꺼이 복종할 것입니다.

저는 2번으로 하겠습니다.

하지만 당신은 mongod를 설정할 수 있습니다.exe 명령줄 옵션 --small files.즉, 익스텐트의 최대 파일 크기는 2기가바이트가 아니라 0.5기가바이트가 됩니다.저는 이것을 mongo 1.42로 테스트했습니다. 그래서 옵션 3이 불가능한 것은 아닙니다.

MongoDB에서 제가 조사한 바에 따르면 트루코스 이 콩세호스 아플리카시온 멀티테넌트이 옵션은 몇 개의 테넌트를 가질 수 있는지 모르는 경우에는 권장하지 않습니다.수천 개가 될 수 있고 샤딩에 관해서는 복잡합니다.또한 하나의 데이터베이스에 수천 개의 컬렉션이 있다고 상상해 보십시오.따라서 사용자의 경우 옵션 1을 사용하는 것이 좋습니다.사용자 수가 제한될 경우 이미 다르므로 옵션 2를 원하는 대로 사용할 수 있습니다.

여기서의 논의는 NoSQL과 주로 MongoDB에 관한 것이지만, Citus에서는 Postgre를 사용하고 있습니다.SQL 및 분산/샤드 멀티 테넌트 데이터베이스 구축.

사용 사례 가이드에서는 예제 앱에 대해 설명하고 스키마 및 다양한 멀티 테넌트(Multi-tenant)별 기능을 다룹니다.

더 많은 비정형 데이터에는 Postgre를 사용합니다.이러한 테넌트별 데이터를 저장하는 SQL의 JSONB 열.

언급URL : https://stackoverflow.com/questions/2748825/what-is-the-recommended-approach-towards-multi-tenant-databases-in-mongodb