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

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

사람들은 어떤 대가를 치르더라도 두 번째 옵션을 피한다고 말했습니다. 내 인상은 이것이 데이터베이스 디자인의 특성으로 인해 내가 조사한 대부분의 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 이상인 데이터베이스가 점점 더 많아집니다. 효율성을 극대화하기 위해 디스크 공간을 사용할 수있는 모든 고객을 위해 여러 데이터베이스를 사용하는 것과 비교했을 때 이것이 엄청난 양의 디스크 공간을 사용한다는 사실을 발견했습니다.

Sharding will be on a per collection basis as standard which presents a problem where the collection never reaches the minimum size to start sharding, as is the case for quite a few of ours (e.g. collections just storing user login details). However, we have requested that this will also be able to be done on a per database level. See http://jira.mongodb.org/browse/SHARDING-41

There are no performance tradeoffs using lots of collections. See http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections

---

There is a reasonable article on MSDN about multi-tenant data architecture which you might wish to refer to. Some key topics touched on by this article:

• Economic considerations
• Security
• Tenant considerations
• Regulatory (legal)
• Skill set concerns

Also touched upon are some patterns for Software as a Service (SaaS) configuration.

Additionally, worth a gander is an interesting write-up from the SQL Anywhere guys.

My own personal take - unless you are certain of enforced security / trust, I would go with option 3, or if scalability concerns prohibit fallback to option 2 at a minimum. That said... I'm no pro with MongoDB. I get pretty nervous using a shared "schema" - but I will happily defer to more experienced practitioners.

---

I would go for option 2.

However you could set mongod.exe command line option --smallfiles. This means that the biggest file size of an extent will be 0.5 gigabyte and not 2 gigabyte. I tested this with mongo 1.42 . So option 3 is not impossible.

---

While the discussion here is on NoSQL and primarily MongoDB, we at Citus are using PostgreSQL and building a distributed/sharded multi-tenant database.

Our use-case guide walks through an example app, covering the schema and various multi-tenant specific features.

For more unstructured data, we use PostgreSQL's JSONB column to store such and tenant-specific data.

---

According to my research in MongoDB. Trucos y consejos. Aplicaciones multitenant. that option is not recommended if you do not know how many tenants you can have, it could be thousands and it would be complicated when it comes to sharding, also imagine having thousands of collections in a single database ... So in your case it is recommended to use option one. Now if you are going to have a limited number of users, it is already different and yes, you could use option two as you thought.

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