다중 클라이언트 응용 프로그램에 대해 단일 또는 다중 데이터베이스 설정을 사용해야합니까?
저는 회사 워크 플로우와 프로젝트 관리를 용이하게하려는 PHP 애플리케이션을 작업 중 입니다. Basecamp 및 GoPlan 과 같은 것을 가정 해 보겠습니다 .
데이터베이스 측면에서 최선의 접근 방식이 무엇인지 잘 모르겠습니다. 단일 데이터베이스를 사용하고 각 테이블에 클라이언트 별 열을 추가해야합니까? 아니면 각 새 클라이언트에 대해 데이터베이스를 만들어야합니까? 중요한 요소는 자동화입니다. 저는 새 클라이언트를 생성하는 것이 매우 간단하기를 원합니다 (그리고 자신을 위해 가입 할 가능성을 여는 것).
가능한 단점 하나의 데이터베이스 사용을 생각할 수 있습니다.
- 확장 성 부족
- 보안 문제 (버그 가 처음부터 존재해서는 안 됨 )
이것에 대한 당신의 생각은 무엇입니까? 위의 회사가 선택했을 가능성이 가장 높은 솔루션이 무엇인지 알고 있습니까?
나는 일반적으로 모든 테이블에 ClientID를 추가하고 하나의 데이터베이스로 이동합니다. 그러나 데이터베이스는 일반적으로 확장하기 어렵 기 때문에 일부 또는 모든 클라이언트에 대해 서로 다른 데이터베이스 인스턴스에서 실행할 수도 있습니다.
이렇게하면 하나의 데이터베이스에 여러 개의 작은 클라이언트가 있고 별도의 서버에 큰 클라이언트가있을 수 있습니다.
유지 관리의 핵심 요소는 모든 데이터베이스에서 스키마를 동일하게 유지한다는 것입니다. 클라이언트 별 스키마를 도입하지 않고도 버전 관리를 관리 할 수있을만큼 골칫거리가 될 것입니다.
Joel과 Jeff가 동일한 질문에 대해 이야기하는 Stackoverflow 팟 캐스트를 들어보십시오. Joel은 호스팅 된 소프트웨어 버전을 제공 한 경험에 대해 이야기하고 있습니다. 그는 DB 전체에 클라이언트 ID를 추가하면 설계와 코드가 복잡해지고 (실수로 WHERE 절에 추가하는 것을 잊지 않았습니까?) 클라이언트 별 백업과 같은 호스팅 기능이 복잡해집니다.
에피소드 # 20 또는 # 21에있었습니다 (자세한 내용은 대본 확인).
제 생각에 그것은 당신의 가능성있는 고객 기반에 달려 있습니다. 경쟁자가 모두 시스템을 사용하는 상황에 처할 수 있다면 별도의 데이터베이스를 사용하는 것이 좋습니다. 또한 DBMS가 여러 데이터베이스를 구현하는 방법에 따라 다릅니다. 각 데이터베이스에 인프라의 별도 사본이있는 경우 단일 데이터베이스 (또는 DBMS 변경)를 제안합니다. 인프라의 단일 복사본에서 여러 데이터베이스를 제공 할 수 있다면 별도의 데이터베이스를 사용합니다.
데이터베이스 백업을 생각해보십시오. 고객 A는 "데이터 사본을 보내주세요"라고 말합니다. 단일 데이터베이스를 공유하는 경우보다 별도의 데이터베이스 설정에서 훨씬 쉽습니다. 고객 제거를 고려하십시오. 다시 말하지만 별도의 데이터베이스를 사용하면 훨씬 쉽습니다.
( '인프라'부분은 '데이터베이스'를 구성하는 것과 '서버 인스턴스'에 대해 서로 다른 DBMS간에 큰 차이가 있기 때문에 입을 다물었습니다. 추가 : 질문에 'mysql'태그가 지정되어 있으므로 이러한 생각은 완전히 관련이 없습니다.)
추가 : 한 가지 더 문제-단일 데이터베이스에 여러 고객이있는 경우 모든 SQL 쿼리는 올바른 고객에 대한 데이터가 선택되었는지 확인해야합니다. 즉, SQL은 쓰기와 읽기가 더 어려워지고 DBMS는 데이터 처리에 더 많은 노력을 기울여야하며 인덱스는 더 커질 것입니다. 많은 목적을 위해 고객.
분명히 StackOverflow (예 :)에는 사용자 당 별도의 데이터베이스가 없습니다. 우리는 모두 동일한 데이터베이스를 사용합니다. 그러나 다른 회사를 위해 회계 시스템을 운영하고 있다면 데이터베이스를 공유하는 것이 허용되지 않을 것이라고 생각합니다.
개발 신속한 개발을 위해 고객 별 데이터베이스를 사용하십시오. 고객의 데이터를 백업, 복원 또는 삭제하는 것이 얼마나 쉬운 지 생각해보십시오. 또는 사용량을 측정 / 모니터링 / 청구합니다. 혼자서 코드를 작성할 필요가 없으며 데이터베이스 기본 형식 만 사용하면됩니다.
성능 성능을 위해 모두를위한 데이터베이스를 사용하십시오. 연결 풀링, 공유 메모리, 캐싱 등에 대해 생각해보십시오.
비즈니스 비즈니스 계획이 많은 소규모 고객 (핫메일 생각)을 보유하는 것이라면 아마도 단일 DB에서 작업해야합니다. 그리고 등록, 삭제, 데이터 마이그레이션 등과 같은 모든 관리 작업을 완전히 자동화하고 친숙한 인터페이스에 노출합니다. 수십 또는 최대 수백 명의 대형 고객을 보유 할 계획이라면 고객 당 하나의 DB에서 작업하고 고객 지원 직원이 운영 할 수있는 시스템 관리 스크립트를 마련 할 수 있습니다.
다음 스크린 캐스트 는 salesforce.com에서 어떻게 수행되는지 설명합니다. 그들은 각 테넌트의 데이터를 식별하는 특수 열 OrgId와 함께 하나의 데이터베이스를 사용합니다. 그것에 대해 훨씬 더 많은 것이 있으므로 이것을 조사해야합니다. 나는 그들의 접근 방식으로 갈 것입니다.
MSDN에 대한 또 다른 훌륭한 기사 가 있습니다. 공유 또는 격리 된 접근 방식을 사용해야하는시기를 자세히 설명합니다. 모든 테넌트에 대해 공유 DB를 갖는 것은 몇 가지 중요한 보안 의미를 가지고 있으며 모두가 동일한 DB 개체를 공유하는 경우 사용하는 DBMS에 따라 [행 수준 보안]을 사용할 수 있습니다 (MS에서 가능합니다. SQL Server 및 Oracle, 아마도 IBM DB2에서도 가능합니다.) mySQL에서 행 수준 보안 과 같은 트릭을 사용 하여 유사한 결과 (보기 + 트리거)를 얻을 수 있습니다.
다중 테넌시의 경우 일반적으로 테넌트간에 공유하기 위해 관리하는 리소스가 많을수록 성능이 향상됩니다.
http://en.wikipedia.org/wiki/Multitenancy
따라서 가능하다면 단일 데이터베이스를 사용하십시오. 응용 프로그램에서 모든 액세스 제어를 구현할 수 있으므로 보안 문제는 버그로 인해 발생한다는 데 동의합니다. 일부 데이터베이스에서는 뷰를주의 깊게 사용하여 데이터베이스 액세스 제어를 계속 사용할 수 있습니다 (인증 된 각 사용자가 다른 뷰를 갖도록).
확장 성을 제공하는 방법도 있습니다. 예를 들어 확장 속성 (테넌트, 기본 레코드 및 확장 속성 ID로 입력)이있는 단일 테이블을 만들 수 있습니다. 또는 각 테넌트가 고유 한 확장 스키마를 갖도록 테넌트 별 확장 테이블을 만들 수 있습니다.
다중 테넌트 데이터베이스를 디자인 할 때 일반적으로 세 가지 옵션이 있습니다.
- 테넌트 당 하나의 데이터베이스 보유
- 테넌트 당 하나의 스키마 보유
- 모든 세입자가 동일한 테이블을 공유하도록합니다.
선택한 옵션은 확장 성, 확장 성 및 격리에 영향을 미칩니다. 이러한 의미는 다양한 StackOverflow 질문 및 데이터베이스 문서 에서 광범위하게 논의되었습니다 .
실제로 세 가지 설계 옵션 각각은 충분한 노력으로 규모, 테넌트에 따라 달라지는 데이터 및 격리에 대한 질문을 해결할 수 있습니다. 결정은 구축하는 기본 차원에 따라 다릅니다. 요약:
- 규모를 구축하는 경우 : 모든 테넌트가 동일한 테이블을 공유하도록합니다.
- 격리를 위해 구축하는 경우 : 테넌트 당 하나의 데이터베이스 만들기
For example, Google and Salesforce follow the first pattern and have their tenants share the same tables. Stackoverflow on the other hand follows the second pattern and keeps one database per tenant. The second approach is also more commonplace in regulated industries, such as healthcare.
The decision comes down to the primary dimension you're optimizing your database design for. This article on designing your SaaS database for scale talks about the trade-offs and provides a summary in the context of PostgreSQL.
Another point to consider is that you may have a legal obligation to keep one companies' data separate from anothers'.
Having a database per client generally does not scale well. MySQL (and probably other databases) holds resources open per table, this does not lend itself well to 10k+ tables on one instance, which would happen in a large-scale multitenancy situation.
Of course, if you have some other issue which causes other problems before you get to this level, this may not be relevant.
Additionally, "sharding" a multi-tenant application is likely€ to be the right thing to do eventually as your application gets bigger and bigger.
Sharding does not however mean one database (or instance) per tenant, but one per shard or set of shards, which may have several tenants each. You will need to discover the right tuning parameters for yourself, probably in production (hence it probably needs to be pretty tunable from the outset)
€ I can't guarantee it.
You can start with a single database and partition it as the application grows. If you do this, there a few things I would recommend:
1) Design the database in a way that it can be easily partitioned. For example, if customers are going to share data, make sure that data is easily replicated across each database.
2) When you have only one database, make sure it is being backed up to another physical server. In the event of a failover you can revert traffic to this other server and still have your data intact.
'program story' 카테고리의 다른 글
| dplyr 필터 : 최소 변수가있는 행을 가져 오지만 최소값이 여러 개인 경우 첫 번째 행만 가져옵니다. (0) | 2020.11.30 |
|---|---|
| moment.js를 사용하여 이번 달의 일 수 가져 오기 (0) | 2020.11.30 |
| 자동 증가로 열의 시작 값 설정 (0) | 2020.11.30 |
| Python의 스레드 로컬 저장소 (0) | 2020.11.30 |
| 자바 스크립트에서 날짜가 같은지 확인 (0) | 2020.11.30 |