다중 클라이언트 애플리케이션에 대해 단일 또는 다중 데이터베이스 설정을 사용해야 합니까?

https://stackoverflow.com/questions/255616

05-07-2019
|

문제

저는 회사의 작업 흐름과 프로젝트 관리를 쉽게 하기 위한 PHP 애플리케이션을 개발 중입니다. 예를 들어 보겠습니다. 베이스 캠프 그리고 고플랜.

데이터베이스 측면에서 가장 좋은 접근 방식이 무엇인지 잘 모르겠습니다.단일 데이터베이스를 사용하고 각 테이블에 클라이언트별 열을 추가해야 합니까, 아니면 각각의 새 클라이언트에 대해 데이터베이스를 만들어야 합니까?중요한 요소는 자동화입니다.나는 새 클라이언트를 생성하는 것이 아주 간단하길 원합니다.

하나의 데이터베이스를 사용하는 것을 생각할 수 있는 가능한 단점:

확장성 부족
보안 문제(버그는 있지만 애초에 거기 있으면 안 돼)

이에 대해 어떻게 생각하시나요?위 회사들이 어떤 솔루션을 선택할 가능성이 가장 높은지 아시나요?

해결책

나는 보통 모든 테이블에 clientId를 추가하고 하나의 데이터베이스를 사용합니다. 그러나 데이터베이스는 일반적으로 확장하기 어렵 기 때문에 일부 또는 모든 클라이언트에 대해 다른 데이터베이스 인스턴스에서 실행할 수있게 해줍니다.

이렇게하면 하나의 데이터베이스에 소규모 클라이언트와 별도의 서버에 큰 클라이언트를 가질 수 있습니다.

그러나 유지 관리의 핵심 요소는 모든 데이터베이스에서 스키마를 동일하게 유지한다는 것입니다. 클라이언트 특정 스키마를 도입하지 않고 버전 관리를 관리 할만 큼 두통이 있습니다.

다른 팁

Joel과 Jeff가 동일한 질문에 대해 이야기하는 Stackoverflow 팟 캐스트를 들어보십시오. Joel은 호스팅 된 버전의 소프트웨어를 제공하는 경험에 대해 이야기하고 있습니다. 그는 DB 전체에 클라이언트 ID를 추가하면 설계 및 코드를 복잡하게 만들고 (우연히 WHERE 절에 추가하는 것을 잊지 않았습니까?) 클라이언트 별 백업과 같은 호스팅 기능을 복잡하게 만듭니다.

에피소드 #20 또는 #21에있었습니다 (자세한 내용은 성적 증명서를 확인하십시오).

내 생각에, 그것은 당신의 고객 기반에 달려 있습니다. Arch-Rivals가 시스템을 모두 사용하는 상황에 빠질 수 있다면 별도의 데이터베이스를 사용하는 것이 좋습니다. 또한 DBMS에서 여러 데이터베이스가 구현되는 방식에 따라 다릅니다. 각 데이터베이스에 별도의 인프라 사본이있는 경우 단일 데이터베이스 (또는 DBMS 변경)를 제안합니다. 인프라의 단일 사본으로 여러 데이터베이스를 제공 할 수 있다면 별도의 데이터베이스를 사용하겠습니다.

데이터베이스 백업을 생각해보십시오. 고객 A는 "내 데이터 사본을 보내주세요"라고 말합니다. 단일 데이터베이스를 공유하는 것보다 별도의 데이터베이스 설정에서 훨씬 쉽습니다. 고객 제거를 생각하십시오. 다시 말하지만, 별도의 데이터베이스를 사용하면 훨씬 쉽습니다.

( '인프라'부분은 예를 들어 '데이터베이스'와 '서버 인스턴스'를 구성하는 것에 대한 다른 DBM 사이에 큰 차이가 있기 때문에 Meally-ind. 추가하다: 질문은 'MySQL'으로 표시되어 있으므로 그 생각은 완전히 관련이 없을 것입니다.)

추가하다: 한 가지 더 문제 - 단일 데이터베이스에 여러 고객이 있으면 모든 SQL 쿼리는 올바른 고객의 데이터를 선택해야합니다. 즉, SQL이 쓰기가 더 어려워지고 읽기가 더 어려워지고 DBMS는 데이터 처리를 위해 더 열심히 노력해야하며 인덱스가 커질 것이며 ... 실제로 별도의 데이터베이스와 함께 갈 것입니다. 많은 목적으로 고객.

분명히, stackoverflow (예 : 예를 들어)는 사용자 당 별도의 데이터베이스가 없습니다. 우리 모두는 동일한 데이터베이스를 사용합니다. 그러나 여러 회사에 대한 회계 시스템을 운영하고 있다면 데이터베이스를 공유하는 것이 회사에 허용되고 합법적 인 사람에게는 허용되지 않을 것이라고 생각합니다.

개발신속한 개발을 위해 고객별 데이터베이스를 사용하십시오.고객의 데이터를 백업, 복원 또는 삭제하는 것이 얼마나 쉬운지 생각해 보십시오.또는 사용량을 측정/모니터링/청구합니다.이를 수행하기 위해 코드를 직접 작성할 필요는 없으며 데이터베이스 기본 요소를 사용하면 됩니다.
성능성능을 위해서는 모두 데이터베이스를 사용하십시오.연결 풀링, 공유 메모리, 캐싱 등에 대해 생각해 보세요.
사업귀하의 사업 계획이 다수의 소규모 고객(핫메일 등)을 확보하는 것이라면 아마도 단일 DB에서 작업해야 할 것입니다.등록, 삭제, 데이터 마이그레이션 등의 모든 관리 업무를 담당합니다.완전히 자동화되어 친숙한 인터페이스에 노출됩니다.수십 또는 최대 수백 명의 대규모 고객을 보유할 계획이라면 고객당 하나의 DB에서 작업하고 고객 지원 직원이 운영할 수 있는 시스템 관리 스크립트를 마련할 수 있습니다.

다음과 같은 스크린 캐스트 Salesforce.com에서 어떻게 수행되는지 설명합니다. 그들은 각 세입자의 데이터를 식별하는 특수 열 오르지드와 함께 하나의 데이터베이스를 사용합니다. 그것에 훨씬 더 많은 것이 있으므로 이것을 조사해야합니다. 나는 그들의 접근 방식을 가지고 갈 것입니다.

또 다른 위대한 것이 있습니다 기사 MSDN에서 그것에 대해. 공유 또는 격리 된 접근법을 사용해야 할 때 깊이 설명합니다. 모든 임차인에 대해 공유 DB를 갖는 것은 중요한 보안 영향이 있으며, 모두 동일한 DB 객체를 공유하면 [행 수준 보안]을 사용하고 싶을 수도 있습니다. SQL Server 및 Oracle, 아마도 IBM DB2에서도). 당신은 같은 트릭을 사용할 수 있습니다 MySQL의 행 수준 보안 유사한 결과를 얻기 위해 (보기 + 트리거).

다수성의 경우 성능은 일반적으로 세입자간에 공유 할 수있는 더 많은 리소스를 증가시킵니다.

http://en.wikipedia.org/wiki/multitenancy

따라서 가능하다면 단일 데이터베이스를 사용하십시오. 응용 프로그램에서 모든 액세스 제어를 구현할 수 있으므로 보안 문제가 버그로 인해 발생한다는 데 동의합니다. 일부 데이터베이스에서는 뷰를 신중하게 사용하여 데이터베이스 액세스 컨트롤을 사용할 수 있습니다 (각 인증 된 사용자가 다른보기를 얻을 수 있습니다).

확장 성을 제공하는 방법이 있습니다. 예를 들어, 확장 속성 (테넌트, 기본 레코드 및 확장자 속성 ID)이있는 단일 테이블을 만들 수 있습니다. 또는 각 임차인이 자신의 확장 스키마를 갖도록 테넌트 당 확장 테이블을 만들 수 있습니다.

멀티 테넌트 데이터베이스를 설계 할 때는 일반적으로 세 가지 옵션이 있습니다.

임차인 당 하나의 데이터베이스가 있습니다
임차인 당 하나의 스키마가 있습니다
모든 세입자가 동일한 테이블을 공유하도록합니다.

선택한 옵션은 확장 성, 확장 성 및 격리에 영향을 미칩니다. 이러한 의미는 다른 것에 대해 널리 논의되었습니다 stackoverflow 질문 및 데이터베이스 기사.

실제로, 세 가지 설계 옵션 각각은 충분한 노력으로 규모에 대한 질문, 세입자에 따라 다른 데이터 및 격리에 대한 질문을 해결할 수 있습니다. 결정은 당신이 구축하는 주요 차원에 따라 다릅니다. 요약:

규모를 위해 건축하는 경우 : 모든 세입자가 동일한 테이블을 공유하도록하십시오.
격리를 위해 구축하는 경우 : 임차인 당 하나의 데이터베이스를 만듭니다.

예를 들어, Google 그리고 Salesforce는 첫 번째 패턴을 따르고 임차인이 동일한 테이블을 공유하게합니다. 반면에 stackoverflow는 두 번째 패턴을 따르고 테넌트 당 하나의 데이터베이스를 유지합니다. 두 번째 접근법은 의료와 같은 규제 산업에서도 더 흔합니다.

결정은 데이터베이스 디자인을 최적화하는 기본 차원으로 이어집니다. SaaS 데이터베이스 설계에 대한이 기사는 스케일을 위해입니다 트레이드 오프에 대해 이야기하고 PostgreSQL의 맥락에서 요약을 제공합니다.

고려해야 할 또 다른 요점은 한 회사의 데이터를 다른 회사와 분리해야 할 법적 의무가 있다는 것입니다.

클라이언트 당 데이터베이스를 갖는 것은 일반적으로 규모가 좋지 않습니다. MySQL (및 아마도 다른 데이터베이스)은 테이블마다 리소스를 열 수 있으므로 한 인스턴스의 10k+ 테이블에 적합하지 않으며, 이는 대규모 멀티 텐시 상황에서 발생합니다.

물론,이 수준에 도달하기 전에 다른 문제를 일으키는 다른 문제가있는 경우 관련이 없을 수 있습니다.

또한, "Sharding"은 멀티 테넌트 응용 프로그램이 응용 프로그램이 점점 커지면서 결국 옳은 일이 될 것입니다.

그러나 샤딩은 테넌트 당 하나의 데이터베이스 (또는 인스턴스)를 의미하는 것이 아니라 각각 여러 세입자가있을 수있는 샤드 또는 파편 세트 당 하나를 의미합니다. 아마도 제작에서 올바른 튜닝 매개 변수를 직접 발견해야합니다 (따라서 처음부터 꽤 조정할 수 있어야합니다).

€ 나는 그것을 보장 할 수 없습니다.

단일 데이터베이스로 시작하여 응용 프로그램이 커짐에 따라 파티션 할 수 있습니다. 당신이 이것을한다면, 내가 추천 할 몇 가지 사항이 있습니다.

1) 데이터베이스를 쉽게 분할 할 수있는 방식으로 데이터베이스를 설계하십시오. 예를 들어 고객이 데이터를 공유하려는 경우 각 데이터베이스에서 데이터가 쉽게 복제되어 있는지 확인하십시오.

2) 데이터베이스가 하나만있는 경우 다른 물리적 서버로 백업되는지 확인하십시오. 장애 조치가 발생하면이 다른 서버로 트래픽을 되돌릴 수 있으며 여전히 데이터가 손상되지 않습니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow