공유 테이블 구조로 다중 테넌트 데이터베이스를 작성하는 방법은 무엇입니까?

우리의 소프트웨어는 현재 MySQL에서 실행됩니다. 모든 테넌트의 데이터는 동일한 스키마에 저장됩니다. Ruby on Rails를 사용하므로 어떤 데이터가 어떤 테넌트에 속하는지 쉽게 결정할 수 있습니다. 그러나 데이터가 손상 될 우려가있는 일부 회사도 있으므로 다른 솔루션을 평가하고 있습니다.

지금까지 세 가지 옵션을 보았습니다.

• 다중 데이터베이스 (각 테넌트는 고유 한 것으로, 고객 당 1 대의 서버와 거의 동일)
• 다중 스키마 (MySQL에서는 사용할 수 없으며 각 테넌트는 공유 데이터베이스에서 자체 스키마를 가져옵니다)
• 공유 스키마 (현재 접근 방식, 각 열에 추가 식별 레코드가있을 수 있음)

다중 스키마는 내가 가장 좋아하는 비용입니다 (비용 고려). 그러나 모든 계정을 반복하고 테이블 / 열 / 정의를 변경해야하기 때문에 새 계정을 만들고 마이그레이션하는 것은 상당히 고통스러운 것 같습니다.

Q : Multi-Schema는 테넌트마다 약간 다른 테이블을 갖도록 디자인 된 것 같습니다. 원하지 않습니다. 테이블 구조가 모든 테넌트간에 공유되는 다중 스키마 다중 테넌트 솔루션을 사용할 수있는 RDBMS가 있습니까?

PS 멀티라는 것은 다중 멀티 (10.000+ 테넌트)와 같은 것을 의미합니다.

그러나 데이터가 손상 될 우려가있는 일부 회사도 있으므로 다른 솔루션을 평가하고 있습니다.

고객은 물리적 격리만으로도 충분한 보안을 제공 할 수 있다는 오해로 인해 어려움을 겪기 때문에 불행한 일입니다.

Multi-Tenant Data Architecture 라는 흥미로운 MSDN 기사 가 있습니다. 저자가 공유 접근법에 대한 오해를 해결 한 방법은 다음과 같습니다.

일반적인 오해는 물리적 격리 만이 적절한 수준의 보안을 제공 할 수 있다는 것입니다. 사실, 공유 접근 방식을 사용하여 저장된 데이터는 강력한 데이터 안전성을 제공 할 수 있지만보다 정교한 디자인 패턴을 사용해야합니다.

기술 및 비즈니스 고려 사항과 관련하여 기사에서는 특정 접근 방식이 다른 방법보다 더 적합한 위치에 대해 간략하게 분석합니다.

서비스를 제공 할 테넌트의 수, 특성 및 요구 사항은 모두 데이터 아키텍처 결정에 다른 방식으로 영향을 미칩니다. 다음 질문 중 일부는보다 고립 된 접근 방식으로 편향 될 수있는 반면, 다른 질문은보다 공유 된 접근 방식으로 편향 될 수 있습니다.

• 얼마나 많은 예비 테넌트를 목표로 삼을 것으로 예상하십니까? 권한을 가진 예상 사용을 추정 할 수있는 곳은 거의 없지만, 수백 명의 입주자를위한 신청서를 작성하고 있습니까? 수천? 수만의? 더? 테넌트 기반이 클수록 더 많은 공유 접근 방식을 고려할 가능성이 높습니다.

• 평균 테넌트 데이터가 얼마나 많은 스토리지 공간을 차지할 것으로 예상합니까? 일부 또는 모든 테넌트가 매우 많은 양의 데이터를 저장할 것으로 예상되는 경우 별도의 데이터베이스 접근 방식이 가장 좋습니다. 실제로 데이터 저장소 요구 사항으로 인해 별도의 데이터베이스 모델을 채택해야 할 수도 있습니다. 그렇다면 나중에 별도의 데이터베이스 접근 방식으로 이동하는 것보다 처음부터 그런 방식으로 응용 프로그램을 설계하는 것이 훨씬 쉽습니다.

• 평균 테넌트가 몇 명의 동시 최종 사용자를 지원할 것으로 예상하십니까? 숫자가 많을수록 최종 사용자 요구 사항을 충족시키는 것이 더욱 적절합니다.

• 테넌트 별 백업 및 복원 기능과 같은 테넌트 별 부가 가치 서비스를 제공 할 것으로 기대하십니까? 이러한 서비스는보다 고립 된 접근 방식을 통해 제공하기가 더 쉽습니다.

업데이트 : 예상 테넌트 수에 대한 추가 정보.

예상되는 테넌트 수 (10k)는 대부분의 경우 모든 시나리오가 아닌 경우 다중 데이터베이스 접근 방식을 제외해야합니다. 10,000 개의 데이터베이스 인스턴스를 유지 관리하고 매일 수백 개의 새로운 인스턴스를 생성해야한다는 아이디어를 좋아하지 않을 것이라고 생각합니다.

이 매개 변수만으로는 공유 데이터베이스 단일 스키마 접근 방식이 가장 적합합니다. 테넌트 당 약 50MB를 저장하고 테넌트 추가 기능이 없기 때문에이 접근 방식이 더 적합합니다.

위에서 인용 한 MSDN 기사는 공유 데이터베이스 접근 방식에 대한 보안 고려 사항을 다루는 세 가지 보안 패턴을 언급합니다.

• 신뢰할 수있는 데이터베이스 연결
• 테넌트 뷰 필터
• 테넌트 데이터 암호화

응용 프로그램의 데이터 안전 조치에 확신이 있으면 강력한 데이터 안전 보장을 제공 하는 서비스 수준 계약 을 고객에게 제공 할 수 있습니다 . SLA에서 보증과는 별도로 데이터가 손상되지 않도록하기 위해 수행 할 조치를 설명 할 수도 있습니다.

업데이트 2 : 분명히 Microsoft 직원 이이 주제와 관련하여 새로운 기사를 이동 / 새로 만들었습니다. 원본 링크는 사라졌으며 이것은 새로운 것입니다. 멀티 테넌트 SaaS 데이터베이스 테넌시 패턴

내 경험 (SQL Server 임에도 불구하고)은 각 데이터베이스마다 고유 한 데이터베이스가있는 다중 데이터베이스를 사용하는 방법입니다. 따라서 mySQL 또는 Ruby On Rails 경험이 없지만 입력 내용에 가치가 추가되기를 바랍니다.

이유는 다음과 같습니다.

1. 데이터 보안 / 재해 복구. 각 회사의 데이터는 다른 회사와 완전히 별도로 저장되어 데이터가 손상 될 위험을 줄입니다 (코드 버그를 도입하여 실수로 다른 클라이언트 데이터를 실수로 보지 않아야하는 경우를 생각하는 등). 특정 데이터베이스 등이 손상됩니다. 클라이언트에 대한 인식 된 보안 혜택이 훨씬 더 큽니다 (보너스 부작용 추가).
2. 확장 성. 기본적으로 데이터를 분할하여 확장 성을 향상시킬 수 있습니다. 예를 들어 데이터베이스를 다른 디스크에 배치 할 수있는 경우 여러 데이터베이스 서버를 온라인 상태로 전환하고로드를 분산시키기 위해 데이터베이스를 더 쉽게 이동할 수 있습니다.
3. 성능 조정. 하나의 매우 큰 클라이언트와 하나의 매우 작은 클라이언트가 있다고 가정하십시오. 사용 패턴, 데이터 볼륨 등은 크게 다를 수 있습니다. 필요한 경우 각 클라이언트에 대해보다 쉽게 ​​튜닝 / 최적화 할 수 있습니다.

이것이 유용한 정보를 제공하기를 바랍니다. 더 많은 이유가 있지만 내 마음은 비었습니다. 다시 시작되면 업데이트 할 것입니다 :)

편집 :
이 답변을 게시 한 후에는 10,000 명 이상의 세입자와 이야기하고 있음이 분명합니다. 내 경험은 수백 개의 대규모 데이터베이스에 있습니다. 10,000 개의 개별 데이터베이스가 시나리오에서 너무 관리하기 어렵다고 생각하므로 시나리오에 대한 다중 DB 접근 방식을 선호하지 않습니다. 특히 명확 해지면서 각 테넌트마다 작은 데이터 볼륨을 사용하고 있습니다!

어쨌든 비슷한 보트에있는 다른 사람들에게 (임차인이 적은) 다른 사람들이 사용할 수 있으므로 내 대답을 여기에 유지하십시오.

다음은 Salesforce.com에서 다중 테넌시를 구현하는 방법에 대한 백서 링크입니다.

http://www.developerforce.com/media/ForcedotcomBookLibrary/Force.com_Multitenancy_WP_101508.pdf

500 개의 문자열 열이있는 1 개의 거대한 테이블 (Value0, Value1, ... Value500)이 있습니다. 날짜 및 숫자는 데이터베이스 레벨에서 고유 유형으로 변환 될 수있는 형식으로 문자열로 저장됩니다. 테넌트마다 고유 할 수있는 데이터 모델의 모양을 정의하는 메타 데이터 테이블이 있습니다. 인덱싱, 관계, 고유 값 등에 대한 추가 테이블이 있습니다.

왜 번거로워?

각 테넌트는 데이터베이스 레벨 (테이블 변경 등)에서 변경하지 않고도 런타임에 자체 데이터 스키마를 사용자 정의 할 수 있습니다. 이것은 분명히 이와 같은 일을하는 어려운 방법이지만 매우 유연합니다.

당신이 언급했듯이 테넌트 당 하나의 데이터베이스는 옵션이며 더 큰 절충점이 있습니다. 한 자릿수 또는 낮은 10의 임차인과 같이 소규모로 잘 작동 할 수 있지만 그 이상으로 관리하기가 더 어려워집니다. 마이그레이션뿐 아니라 데이터베이스를 계속 실행하는데도 사용됩니다.

스키마 별 모델은 각 스키마마다 고유 한 스키마에만 유용하지는 않지만 모든 테넌트에서 마이그레이션을 계속 실행하는 것은 어려워지고 1000 개의 스키마에서 Postgres가 문제를 일으킬 수 있습니다.

더 확장 가능한 접근 방식은 테넌트가 무작위로 분산되어 동일한 데이터베이스에 저장되지만 다른 논리적 샤드 (또는 테이블 )에 절대적으로 저장됩니다 . 언어에 따라이를 도와 줄 수있는 라이브러리가 많이 있습니다. Rails를 사용하는 경우 테넌시 acts_as_tenant를 확보하기 위한 라이브러리가 있으므로 테넌트 쿼리가 해당 데이터를 가져 오는 것만 보장합니다. gem도 있습니다 apartment. 스키마 모델을 사용하지만 모든 스키마에서 마이그레이션하는 데 도움이됩니다. Django를 사용하는 경우 숫자가 있지만 가장 인기있는 것 중 하나는 스키마 전체에있는 것 같습니다 . 이들 모두는 응용 프로그램 수준에서 더 많은 도움을줍니다. 데이터베이스 수준에서 직접 더 많은 것을 찾고 있다면 Citus 는 이러한 유형의 샤딩을 만드는 데 중점을 둡니다.멀티 테넌시 는 Postgres와 함께 즉시 사용할 수 있습니다.