다중 테넌트 DB에 여러 데이터베이스 또는 공유 테이블이 있습니까?

다중 테넌트 데이터베이스입니다.

고객 / 테넌트마다 다른 (동일한) 데이터베이스 / 스키마를 가진 DB 서버? 또는
고객 / 테넌트가 동일한 테이블 내에서 레코드를 공유하는 데이터베이스 / 스키마가있는 DB 서버?

예를 들어, 위의 옵션 # 1 아래에 MySQL 서버 mydb01.example.com가 있고 customer1내부에 데이터베이스 가있을 수 있습니다 . 이 customer1데이터베이스에는 특정 고객 (고객 # 1)에 대한 내 응용 프로그램 을 강화하는 10 개의 테이블 이 있을 수 있습니다 . 또한 customer2정확히 10 개의 테이블이 있지만 고객 # 2에 대한 데이터 만 포함 하는 데이터베이스 가있을 수 있습니다 . customer3데이터베이스, 데이터베이스 등 이있을 수 있습니다 customer4.

위의 옵션 # 2에는 myapp_db테이블과 테이블이 10 개인 단일 데이터베이스 / 스키마 만 있습니다 (위와 동일). 그러나 여기서 모든 고객에 대한 데이터는 10 개의 테이블 내에 존재하므로 테이블을 "공유"합니다. 그리고 애플리케이션 계층에서는 고객이 10 개의 테이블에있는 레코드에 액세스 할 수있는 논리 및 보안 제어가 가능하며 고객 # 1이 앱에 로그인하지 않고 고객 # 3의 데이터 등을 보지 않도록 각별한주의를 기울입니다.

이 중 어떤 패러다임이 전통적인 "다중 테넌트"DB를 구성합니까? 그리고 어느 쪽도 아닌 경우 누군가가 다중 테넌트 DB가 무엇인지에 대한 예 (위에서 설명한 시나리오를 사용하여)를 제공 할 수 있습니까?

database-design multitenancy

— 스미 브
소스

"멀티 테넌트"는 강력한 보안 ( 어딘가에 구현 됨)을 의미 하므로 한 테넌트는 다른 데이터를 볼 수없고, 수정할 수 없으며, 액세스를 거부 할 수 없습니다. 그 보안은 어떻게 든 구현되어야합니다. OP의 옵션 # 1과 # 2는 모두 작동하지만 보안 분석 및 보안 구현에 필요한 작업은 다릅니다. 가치있는 것을 위해, 옵션 # 2를 통해 다중 테넌시를 구현 한 스타트 업에서 일했습니다. 여러 테넌트에 속한 행이있는 테이블은 모든 최종 사용자로부터 (권한을 통해) 숨겨졌으며 보안은 전적으로 저장 프로 시저에서 구현되었습니다.

— davidbak

다중 테넌시의

— JeffO

이것이 중복으로 종료되면 두 질문에 실제로 좋은 답변이 있기 때문에 중복 대상과 병합하도록 플래그를 지정해야한다고 생각합니다.

답변:

이러한 패러다임 중 어느 것이 전통적인 "멀티 테넌트"DB를 구성 하는가

두 개념을 모두 다중 테넌 시라고합니다. "단일 소프트웨어 인스턴스가 서버에서 실행되고 여러 테넌트에 서비스를 제공하는" 논리적 개념이기 때문입니다 ( Wikipedia ). 그러나이 개념을 "물리적으로"구현하는 방법은 사용자에게 달려 있습니다.

물론 응용 프로그램에는 서로 다른 테넌트의 데이터를 분리 할 수있는 데이터베이스 개념이 필요하며 다중 테넌시의 아이디어는 리소스를보다 효율적으로 사용하고 관리하기 쉽도록 일부 서버 리소스를 공유 (최소한 하드웨어)하는 것입니다. 따라서 "멀티 테넌트 DB"는 이를 직접 지원 하는 데이터베이스로, DB 모델 또는 테이블의 일부가 공유됩니다.

정확하게 말하면, 멀티 테넌트 DB가 아닌 멀티 테넌트 애플리케이션을 구축하여 클라이언트 당 개별 DB 인스턴스를 제공 할 수 있습니다. 그러나 이로 인해 테넌트간에 DB 리소스를 직접 공유 할 수 없으므로 애플리케이션 계층에서 올바른 테넌트를 올바른 데이터베이스에 연결해야합니다.

— 닥 브라운
소스

감사 @Doc 브라운 (+1)하지만 그때는 어떻게 가능하게 할 수 있는 이었다 데이터베이스 하지 멀티 테넌트 (multi-tenant)을?!?

— Smeeb

@smeeb : 다중 테넌시는 응용 프로그램 "뒤"에있는 데이터베이스가 아니라 다른 테넌트가 사용하는 응용 프로그램의 속성입니다. 물론 db 개념은이를 가능하게하기 위해 다중 테넌시를 지원해야합니다.

— Doc Brown

@smeeb : 사용자 이름이 고유하다는 제약 조건이있는 User 테이블이 있다고 가정 해보십시오. 이제 테넌트 직원 중 일부는 다른 테넌트에서 일하는 다른 사람이 이미 사용하고 있기 때문에 더 이상 사용자 이름을 사용할 수 없습니다.

— RemcoGerlich

@smeeb : 두 명의 테넌트를 지원하는 유일한 방법이 두 개의 별도 데이터베이스가있는 두 개의 서로 다른 서버에 응용 프로그램을 두 번 설치하고 실행하는 것이라면이 멀티 테넌시를 호출하지 않을 것이라고 생각합니다.

— Doc Brown

MYOB가 Azure에서 클라우드 솔루션을 실행한다고 말하면서 Azure에서 프레젠테이션을했는데 각 테넌트가 자체 DB (및 아마도 웹 서버도)를 얻습니다. 여기에는 필요한 수백 개의 DB 인스턴스를 관리 할 수있는 훌륭한 자동화 도구가 있습니다. 반면에, 제가 현재 일하고있는 조직은 단일 데이터베이스에서 수백 명의 고객을 운영하고 있습니다. 고객 데이터의 격리를 강제하기 위해 소프트웨어에서 약간의 작업이 수행됩니다. 또한 최대 규모의 고객이 자신의 DB를 얻는 반면 다른 사람들은 원본을 공유하는 하이브리드를 고려했습니다.

— David Keaveny

Microsoft에 따르면이 용어는 세 가지 잠재적 의미를 갖습니다 (모든 테넌트에 대한 하나의 데이터베이스 또는 테넌트 당 하나의 데이터베이스).

예제를 사용하려면 각 고객이 자신의 테넌트가됩니다.

테넌트 당 데이터베이스 (고객)
- 각 테넌트는 다른 테넌트와 격리됩니다 (다른 테넌트 데이터에 우연히 액세스하지 않음)
- 또한 격리를 통해 데이터 복원을보다 쉽게 관리 할 수있을뿐만 아니라 테넌트 요구에 맞게 스토리지 요구를 조정할 수 있습니다.
공유 데이터베이스, 별도의 스키마
- 각 테넌트에는 고유 한 스키마가 있으며 데이터는 자체 테이블에 있습니다.
- 모든 사람이 같은 데이터베이스에 있기 때문에 데이터베이스를 이전 백업으로 복원 할 수는 없습니다 (모든 테넌트의 데이터를 롤백 할 수 있음). 옵션은 새 데이터베이스로 복원 한 다음 1 테넌트 데이터 만 병합 / 복사하는 것입니다.
공유 데이터베이스, 공유 스키마
- 모든 테넌트의 데이터는 동일한 테이블에 있습니다. 예를 들어 주문을 추적하면 모든 임차인의 주문은 "dbo.Orders"에 있습니다.
- 테넌트 데이터는 각 테이블의 열로 구분되며 (TenantId 일 수 있음) 행 소유자를 표시합니다.

이 기사에서 잘 설명 된 각각의 장단점이 있습니다 : https://msdn.microsoft.com/en-us/library/aa479086.aspx

보너스 : 당신은 그것을 숙소로 생각할 수 있습니다 (거의 단순화).

모든 임차인에게는 자신의 집이 있습니다. 그들은 원하는 모든 것을 할 수 있으며, 화상을 입더라도 다른 사람에게는 영향을 미치지 않습니다.
모든 임차인은 같은 건물에 있지만 아파트가 있습니다.
모든 사람이 같은 아파트에 살고 있으며 모든 물건에는 누가 그것을 소유하고 있는지 보여주기 위해 스티커 메모가 붙어 있습니다.

— lmms90
소스

답변 주셔서 감사합니다. 답을 좀 더 자세히 설명해 주시겠습니까? 그것은 더 나은 대답을 만들 것입니다.

— 토마스 정크

보너스 예는 굉장합니다 @ imms90

— Aravin

Microsoft는 귀하가 MSDN에서 연결 한 페이지를 삭제했습니다. 뒤로 기계는 여전히 복사본을 가지고있다.

— Mike Sherrill 'Cat

MS의 유사한 기사 (이동했을 수도 있음) : docs.microsoft.com/en-us/azure/sql-database/…

— Pierre Henry