다중 테넌시-단일 데이터베이스 및 다중 데이터베이스

20

우리는 시스템이 일부 기능을 공유하지만 상당히 다양한 다양성을 가진 다수의 클라이언트를 보유하고 있습니다. 고객 수가 늘고 있습니다. 항상 건강한 것입니다! -비즈니스 간의 다양성도 증가하고 있습니다.

현재 단일 테넌트의 비표준 페이지와 함께 각 테넌트에 대한 하위 폴더가있는 단일 ASP.Net (Web Forms) 웹 사이트 (웹 프로젝트와 반대)가 있습니다. 데이터베이스 액세스 및 비즈니스 로직을 다루는 별도의 모델 프로젝트가 있습니다.

(a) 클라이언트 당 하나의 데이터베이스를 갖고 그 클라이언트와 관련된 기능 만 갖는 것 사이에서 바람직하고 가장 중요한 이유는 무엇입니까? 또는 (b) 모든 클라이언트가 공유하는 단일 데이터베이스. 단일 클라이언트가 테이블의 서브 세트 만 사용하는 경우.

비즈니스 내 주요 관심사는 다음과 같습니다.

여러 자산의 유지 관리-백업, 버전 관리 등
최대한 재사용을 촉진

이러한 문제를 어떻게 해결하고 어떤 솔루션을 선호하며 그 이유는 무엇입니까? (저는 비슷한 질문에 대한 답변을 작성하고 있습니다)

database-design projects-and-solutions multitenancy

— 리차드
소스

이것이 Azure와 같은 PaaS 클라우드 환경으로 이동할 가능성이 있습니까? 그렇다면 환경에 대한 모범 사례도 고려해야합니다. 마지막으로 MS는 Azure의 다중 테넌트 소프트웨어에 여러 데이터베이스를 권장했습니다.

— Harper Shelby

질문 주셔서 감사합니다. 나는 비슷한 것을 궁금해했지만 당신처럼 질문 형식으로 설득력을 얻지 못했습니다.

— MathAttack

Ayende의 다중 테넌트 블로그 시리즈를 읽으십시오. 그는 다중 데이터베이스와 단일 데이터베이스에 대해 매우 좋은 지적을합니다.

— Sebazzz

12

다른 출처의 연구에서 얻은 주요 내용은 다음과 같습니다 (원래 질문 개정 2 ).

응용 프로그램 당 하나의 데이터베이스를 사용하거나 여러 응용 프로그램간에 단일 데이터베이스를 공유해야합니까?
다중 테넌시 지원
MSDN 다중 테넌트 데이터 아키텍처
SO 공유 테이블 구조로 다중 테넌트 데이터베이스를 작성하는 방법은 무엇입니까?
CloudExpo SaaS- 다중 테넌트 데이터베이스 설계 옵션
MSDN 블로그 SQL Azure 페더레이션으로 손쉽게 다중 테넌트 데이터베이스 모델로 이동
SQL Server Central에 하나 이상의 데이터베이스를 요구합니까?
다른 데이터베이스 / 응용 프로그램에서 하나의 데이터베이스로 SQL Server Central 믹싱 테이블
Ayende @ Rahien 블로그 멀티 테넌시-물리적 데이터 모델
코드 프로젝트 다중 테넌트 데이터베이스 아키텍처
소프트웨어 다중 테넌트 데이터베이스 설계 에 관한 Joel
SO 여러 응용 프로그램이 하나의 데이터베이스를 사용하고 계십니까?
SO 단일 또는 다중 데이터베이스
코드 범위-다중 테넌트 1 부, 전략 및 2 부, 구성 요소 및 컨텍스트

— 개정 사용자
소스

10

SQL Server를 사용하는 경우 하나의 데이터베이스를 사용하지만 스키마를 사용하십시오. 모든 클라이언트에 공통적 인 항목에 dbo를 사용하고 각 클라이언트에 대한 스키마를 작성하고 해당 클라이언트의 사용자에 대한 기본 스키마를 작성하십시오. 이제 dbo 스키마에 일반 객체 (예 : getBudget proc)와 동일한 이름의 스키마에있는 클라이언트에 대해 사용자 정의 된 객체를 가질 수 있습니다.

— HLGEM
소스

+1 또한 MSDTC를 구성하지 않고 관련된 오버 헤드 (2 단계 커밋)를 수행하지 않아도됩니다.

— brian

그리고 CustomField1부터 CustomField30까지의 열과 / 또는 Budget, BudgetEx, BudgetCustom, BudgetCustomerName, BudgetAnotherCustomerName 등과 같은 테이블을 갖는 함정을 피하기를 바랍니다.

— jfrankcarr

190 개의 테이블, 테이블 당 5 개의 코드 생성 프로 시저 및 일부 사용자 정의 프로 시저를 사용하는 많은 저장 프로 시저를 사용하는 기존 데이터 액세스 계층이 있습니다. 중간 목표는 Entity Framework를 도입하는 것이지만 저장된 저장을 복제해야 할 경우가 있습니다. 각 스키마에 대한 절차?

— RichardW1001

@ RichardW1001 : 의존합니다. sp에서 동적 SQL을 수행하여 일반으로 만들 수는 있지만 적어도 약간 유사한 구조를 갖는 것에 달려 있습니다. 동적 SQL의 가능한 대안은 Synonyms 일 것입니다. 유감스럽게도 내가 이해할 수 있듯이 시스템 전체에 있고 트랜잭션에 포함되어 있지 않으므로 다른 값을 가진 동시 사용에는 적합하지 않습니다.

— jmoreno

여러 스키마를 사용하는 경우 EF 코드 우선을 사용하면 시스템이 가동 된 후 모든 스키마를 최신 버전으로 마이그레이션 할 수 있습니까?

— Yashvit

4

클라이언트 데이터베이스와 기능이 다양하기 때문에 언젠가는 서로 다른 시스템이 될 수 있으므로이 경우 각 클라이언트의 사용자 지정을 유지 관리하는 데 드는 비용이 단일의 이점보다 중요하므로 별도의 시스템을 권장합니다 데이터베이스 시스템.

단일 데이터베이스 시스템은 서로 다른 고객 간의 변경이 단지 구성이지만 각 클라이언트에 대한 추가 기능이 아닌 경우에 가장 좋습니다.

— Stephen Senkomago Musoke
소스

최소한의 고통으로 일반적인 기능을 관리하는 방법에 대한 제안은 무엇입니까?

— RichardW1001

1

버전 관리 시스템에서 핵심 응용 프로그램의 헤드를 유지 관리하고 유지 관리해야하는 새로운 기능에 대한 하위 브랜치를 사용하여 각 고객에 대한 기본 지점을 만듭니다. 트렁크 등을 업데이트하는 옵션을 사용하여 지점에서 고객 별 기능을 개발합니다. 고객 별 환경을 필요할 때마다 쉽게 스핀

— 업할

3

몇 가지 우려 사항이 없습니다. 문제는 성장할 것입니다. 언젠가 하나의 DB 서버보다 커질 것이라고 생각할 수 있다면 하나의 복잡한 데이터베이스가 분명히 두통을 유발할 것입니다. 아키텍처에 미리 투자하지 않는 한. 그러나 그것은 또한 비싼 단계입니다)

따라서 거대한 데이터베이스보다 몇 가지 다른 데이터베이스를 확장하는 것이 여러 번 저렴하고 쉽다는 것을 잊지 마십시오.)

— 자극
소스

확장의 용이성을 확인하는 데이터가 있습니까? 그렇다면 매우 매력적인 사례가 될 것입니다. 다른 누락 된 문제에 대해 자세히 설명해 주시겠습니까? 가능한 한 양면에 완전한 인수를 작성하려고합니다.

— RichardW1001

1

답변에서 다루지 않은 한 가지 영역은 다중 테넌트 DB 애플리케이션을 올바르게 보호하는 데 문제가 있다는 것입니다. 다중 테넌트 앱은 보안 문제를 피하기 위해 매우 신중하게 설계되어야합니다. 대부분의 데이터베이스와 앱은 일부 격리를 제공하지만 완전히 격리되지는 않습니다. 일반적으로 DB 스키마에서 데이터를 직접 또는 간접적으로 유추하는 방법이 있습니다. 그리고 최소한 최소한 다른 테넌트에 대한 서비스 거부 공격으로 이어질 수있는 상당히 많은 공유 리소스 (로그 및 기타 파일, DBA 테이블, 커서 ...).

— 백로
소스