공유 테이블 구조를 가진 멀티 테넌트(Multi-tenant) 데이터베이스를 작성하려면 어떻게 해야 합니까?
현재 MySQL에서 소프트웨어가 실행되고 있습니다.모든 테넌트의 데이터는 동일한 스키마에 저장됩니다.Ruby on Rails를 사용하고 있기 때문에 어떤 데이터가 어떤 세입자의 것인지 쉽게 판단할 수 있습니다.다만, 물론, 데이터의 유출을 염려하는 기업도 있기 때문에, 다른 솔루션을 검토하고 있습니다.
지금까지 세 가지 옵션을 보았습니다.
- 멀티 데이터베이스(각 테넌트마다 독자적인 서버 사용 가능.고객 1대당 서버 1대와 거의 동일)
- Multi-Schema(MySQL에서는 사용할 수 없습니다. 각 테넌트는 공유 데이터베이스에서 고유한 스키마를 가져옵니다.)
- 공유 스키마(각 열에 추가 식별 기록이 있을 수 있음)
Multi-Schema가 마음에 듭니다(비용을 고려).그러나 모든 스키마에 대해 반복하여 테이블/컬럼/정의 변경을 해야 하기 때문에 새 계정을 만들고 마이그레이션을 수행하는 것은 매우 힘든 작업인 것 같습니다.
Q: Multi-Schema는 각 테넌트에 대해 약간 다른 테이블을 갖도록 설계되어 있는 것 같습니다.이것을 원하지 않습니다.테이블 구조가 모든 테넌트 간에 공유되는 멀티 스키마 멀티 테넌트 솔루션을 사용할 수 있는 RDBMS가 있습니까?
추신: 멀티란 울트라 멀티(1만 명 이상의 세입자)와 같은 것을 말합니다.
다만, 물론, 데이터의 유출을 염려하는 기업도 있기 때문에, 다른 솔루션을 검토하고 있습니다.
이는 고객이 물리적 격리만이 충분한 보안을 제공할 수 있다는 잘못된 인식을 가질 수 있기 때문에 유감스러운 일입니다.
Multi-Tenant Data Architecture라는 흥미로운 MSDN 기사가 있습니다.이 기사를 확인해 주십시오.저자들은 공유 접근법에 대한 오해를 다음과 같이 해결하였다.
일반적인 오해는 물리적 격리만이 적절한 수준의 보안을 제공할 수 있다는 것입니다.실제로 공유 접근 방식을 사용하여 저장된 데이터는 강력한 데이터 안전성을 제공할 수 있지만 보다 정교한 설계 패턴을 사용해야 합니다.
기술 및 비즈니스상의 고려사항에 대해 기사에서는 특정 접근법이 다른 접근법보다 더 적합한 부분에 대해 간략하게 분석합니다.
서비스를 제공할 것으로 예상되는 테넌트의 수, 특성 및 요구 사항은 데이터 아키텍처 결정에 다양한 방식으로 영향을 미칩니다.다음 질문 중 일부는 더 고립된 접근 방식을 선호하고 다른 질문들은 더 공유된 접근 방식을 선호할 수 있습니다.
몇 명의 입주 예정자를 대상으로 하고 있습니까?권한으로 미래의 사용을 추정하는 것은 불가능할 수 있지만, 규모 면에서 생각해 보십시오. 수백 명의 세입자를 위한 애플리케이션을 구축하고 있습니까?수천?수만 개?추가 정보? 테넌트 기반 규모가 클수록 공유 방식을 더 많이 고려할 수 있습니다.
평균 테넌트의 데이터가 차지하는 스토리지 공간은 어느 정도입니까?일부 또는 모든 테넌트가 매우 많은 양의 데이터를 저장할 것으로 예상되는 경우 별도의 데이터베이스 접근 방식이 가장 좋습니다(실제로 데이터 스토리지 요구 사항으로 인해 별도의 데이터베이스 모델을 채택해야 할 수도 있습니다).이 경우 나중에 별도의 데이터베이스 접근 방식으로 전환하는 것보다 처음부터 애플리케이션을 설계하는 것이 훨씬 더 쉬워집니다.
평균 테넌트가 지원하는 동시 최종 사용자는 몇 명입니까?이 수치가 클수록 최종 사용자의 요건을 충족하기 위해 격리된 접근방식이 더욱 적절해집니다.
테넌트당 백업 및 복원 기능과 같은 테넌트당 부가가치 서비스를 제공할 예정입니까?이러한 서비스는 보다 고립된 접근 방식을 통해 보다 쉽게 제공할 수 있습니다.
업데이트: 예상 테넌트 수에 대한 추가 정보입니다.
예상 테넌트 수(10k)는 모든 시나리오는 아니더라도 대부분의 경우 다중 데이터베이스 접근방식을 제외해야 합니다.10,000개의 데이터베이스 인스턴스를 관리하고 매일 수백 개의 새로운 인스턴스를 만들어야 한다는 생각은 별로 좋아하지 않을 것입니다.
이 파라미터만 놓고 보면 공유 데이터베이스 단일 스키마 방식이 가장 적합할 것으로 보입니다.테넌트당 약 50Mb의 용량만 저장하고 테넌트당 추가 기능은 없으므로 이러한 접근 방식이 더욱 적합합니다.
위에서 인용한 MSDN 기사에서는 공유 데이터베이스 접근법에 대한 보안 고려사항에 대해 다음 3가지 보안 패턴을 언급하고 있습니다.
애플리케이션의 데이터 안전 대책에 자신이 있는 경우, 강력한 데이터 안전 보증을 제공하는 Service Level Agreement를 고객에게 제공할 수 있습니다.SLA에는 보증과는 별도로 데이터가 손상되지 않도록 하기 위해 취해야 할 조치를 기술할 수도 있습니다.
업데이트 2: 이 주제에 관한 새로운 기사를 Microsoft 직원이 이동/작성했다고 합니다.원래 링크는 없어지고 이것이 새로운 링크입니다.멀티 테넌트 SaaS 데이터베이스 테넌시 패턴(kudos to Shai Kererer)
(SQL Server를 사용하더라도) 각 클라이언트에 고유한 데이터베이스가 있는 멀티 데이터베이스가 가장 적합합니다.mySQL이나 Ruby On Rails 경험은 없지만 제 입력이 어떤 가치를 더하기를 바랍니다.
이유는 다음과 같습니다.
- 데이터 보안/하드웨어 복구.각 기업의 데이터는 다른 기업과는 완전히 분리되어 저장되므로 데이터가 침해될 위험이 줄어듭니다(다른 클라이언트 데이터를 잘못 보면 안 되는 코드 버그 도입 등).또한 특정 데이터베이스가 파손될 경우 클라이언트의 손실을 최소화할 수 있습니다.클라이언트에 대한 보안상의 이점은 더욱 커집니다(추가되는 보너스 부작용).
- scalability.기본적으로 데이터 파티셔닝을 통해 확장성을 높일 수 있습니다.예를 들어 데이터베이스를 다른 디스크에 배치하거나 여러 데이터베이스 서버를 온라인으로 전환하거나 데이터베이스를 쉽게 이동하여 부하를 분산할 수 있습니다.
- 퍼포먼스 튜닝매우 큰 클라이언트와 매우 작은 클라이언트가 있다고 가정합니다.사용 패턴, 데이터 볼륨 등은 크게 다를 수 있습니다.필요에 따라서, 각 클라이언트의 튜닝/최적화를 용이하게 실시할 수 있습니다.
도움이 되었으면 좋겠습니다!이유는 더 있지만 머릿속이 하얘졌어요.재기동하면, 갱신합니다. : )
★★★★★★
이 답변을 게시한 후, 10,000명 이상의 테넌트에 대해 이야기하고 있는 것이 분명합니다.제 경험은 수백 개의 대규모 데이터베이스에 있습니다.고객님의 시나리오에서는 10,000개의 개별 데이터베이스를 관리할 수 있을 것 같지 않기 때문에 현재 고객님의 시나리오에서는 multi-db 접근 방식을 선호하지 않습니다.특히 이제는 각 테넌트의 데이터 볼륨이 작다는 것을 알 수 있습니다.
같은 배에 타고 있는 다른 사람에게도 도움이 될 수 있으므로 가능한 한 답변을 여기에 보관합니다(세입자가 적음).
멀티 테넌시(Multi-tenancy)를 구현하는 방법에 대한 Salesforce.com 백서의 링크를 다음에 나타냅니다.
http://www.developerforce.com/media/ForcedotcomBookLibrary/Force.com_Multitenancy_WP_101508.pdf
500개의 문자열 열이 있는 거대한 테이블이 1개 있습니다(Value0, Value1, ...).값 500).날짜 및 숫자는 데이터베이스 수준에서 기본 유형으로 변환할 수 있는 형식으로 문자열로 저장됩니다.테넌트별로 고유할 수 있는 데이터 모델의 모양을 정의하는 메타 데이터 테이블이 있습니다.색인, 관계, 고유한 값 등을 위한 추가 테이블이 있습니다.
왜 그렇게 귀찮아?
각 테넌트는 데이터베이스 수준(변경 테이블 등)에서 변경할 필요 없이 런타임에 자체 데이터 스키마를 사용자 지정할 수 있습니다.이것은 확실히 어려운 방법이지만 매우 유연합니다.
말씀하신 바와 같이 테넌트당 하나의 데이터베이스만 사용할 수 있으며 몇 가지 더 큰 단점이 있습니다.한 자리 수 또는 10자리 미만의 테넌트(tenant)와 같은 소규모 환경에서는 잘 작동하지만, 그 이후에는 관리가 더욱 어려워집니다.이행 뿐만이 아니라, 데이터베이스의 가동 상태를 유지하기 위해서도 마찬가지입니다.
스키마별 모델은 각각의 고유한 스키마에만 도움이 되는 것이 아닙니다.다만, 모든 테넌트에 대해서 이행을 실행하는 것은 곤란해지기 때문에, 1000개의 스키마에서 Postgres에 문제가 생기기 시작할 수 있습니다.
보다 확장성이 높은 접근방식은 테넌트를 같은 데이터베이스에 랜덤하게 분산하여 저장하되 서로 다른 논리 샤드(또는 테이블)에 분산시키는 것입니다.사용하시는 언어에 따라 이 기능을 지원하는 라이브러리가 많이 있습니다.Rails를 사용하는 경우 테넌트 쿼리를 통해 해당 데이터만 회수할 수 있도록 하는 라이브러리가 있습니다.또한 스키마 모델을 사용하지만 모든 스키마 간의 이행을 지원합니다.만약 장고를 사용한다면 번호가 있지만, 가장 인기 있는 것 중 하나는 스키마를 넘나드는 것 같습니다.이 모든 것이 애플리케이션 레벨에서 도움이 됩니다.데이터베이스 수준에서 직접 무언가를 찾고 있다면, Citus는 Postgres를 통해 멀티 테넌시(Multi-tenancy)를 위한 이러한 샤딩을 바로 사용할 수 있도록 하는 데 초점을 맞추고 있습니다.
언급URL : https://stackoverflow.com/questions/2213006/how-to-create-a-multi-tenant-database-with-shared-table-structures
'programing' 카테고리의 다른 글
| Js가 현재 달의 첫 번째와 마지막 날을 얻는 순간 (0) | 2022.10.02 |
|---|---|
| 래퍼 "https"를 찾을 수 없습니다. PHP 구성 시 래퍼 "https"를 사용하도록 설정하지 않았습니까? (0) | 2022.10.02 |
| "new" 연산자를 사용하여 개체를 만들 때 괄호를 생략할 수 있습니까? (0) | 2022.10.02 |
| JavaScript에서 var가 문자열인지 확인하려면 어떻게 해야 합니까? (0) | 2022.10.02 |
| PHP 재귀 함수가 있는 디렉터리의 모든 파일 및 폴더 나열 (0) | 2022.10.02 |