고객 당 데이터베이스를 만들 때 어떤 문제가 발생합니까?

나는 Fog Creek이 고객 당 데이터베이스를 Fogbugz에 사용 한다는 점 을 스택 오버 플로우 팟 캐스트에서 기억합니다 . Fogbugz On Demand 서버에는 수만 개의 데이터베이스가 있다고 가정합니다.

우리는 웹 응용 프로그램을 개발하기 시작했으며 비슷한 문제가 있습니다 (많은 고객이 자체 격리 된 데이터를 가지고 있음).

고객 당 데이터베이스를 사용할 때 어떤 문제가 발생합니까? 어떻게 해결할 수 있습니까?

내 초기 생각

고객 당 데이터베이스의 장점

• 더 간단한 데이터베이스 스키마
• 보다 간편한 백업-다른 고객에게 영향을주지 않고 각 고객을 차례로 백업 할 수 있습니다.
• 주어진 고객 데이터를 쉽게 내보낼 수 있습니다.
• 더 나은 캐시 성능 –보다 활동적인 테이블 중 하나에 대한 쓰기는 쓰기를 수행 한 단일 고객에게만 영향을줍니다.
• 하드웨어 전반에 걸쳐 쉽게 확장 할 수 있습니다. 예를 들어 1 대에서 2 대의 서버로 이동해야하는 경우 고객의 절반 만 새 서버로 옮깁니다.

단점

• MySQL이 5,000 개의 데이터베이스를 처리 할 수 ​​있습니까? 성능이 저하됩니까?
• 모든 데이터베이스에서 스키마 변경 사항을 복제하기 어려울 수 있습니다. 스키마 버전 관리, 한 버전에서 다른 버전으로 데이터베이스를 가져 오는 방법을 이해하는 스크립트와 같은 자동화 된 계획이 실제로 필요합니다.
• 모든 고객에게 공통적 인 것을하는 것은 어색하거나 불가능할 수 있습니다
• 위와 유사하지만 모든 고객에 대해 수행하려는 분석은 불가능할 수 있습니다. 예를 들어 모든 고객의 사용량을 어떻게 추적해야합니까?

이 솔루션을 각 테넌트 (고객)에게 고유 한 데이터베이스가있는 다중 테넌트 디자인이라고합니다. 이를 감안할 때 단일 데이터베이스 인 대체 방법에 대한 다른 고려 사항이 있습니다.

1. 단일 데이터베이스를 사용하면 모든 사람이 무엇이든간에 동일한 버전을 사용해야합니다. 일부 고객은 업그레이드 할 수 없으며 다른 고객은 업그레이드 할 수 없습니다. 고객이 광범위한 릴리스 준비가되지 않은 응용 프로그램의 핫픽스를 원하는 경우 문제가 될 수 있습니다.
2. 단일 데이터베이스를 사용하면 업그레이드를 수행 할 때 모든 클라이언트가 다운됩니다. 문제가 발생하면 모든 고객이 망하게됩니다.
3. 단일 데이터베이스를 사용하면 리소스를 조절하기가 훨씬 어렵습니다. 즉, 한 클라이언트가 데이터베이스를 망치는 경우 다른 모든 사용자와 더 많은 리소스를 제공하기가 더 어렵습니다.
4. 사용자가 자신의 응용 프로그램 버전을 호스팅하는 것이 훨씬 더 어렵습니다. 대기업에서 사용할 솔루션을 구축하는 경우 이는 종종 스타터가 아닙니다. IT 부서는 시스템 액세스에 대한 완벽한 제어를 원합니다.
5. 데이터베이스를 수평 확장하지 않고 수평 확장하는 것이 더 저렴할 것입니다. 즉, 하나의 데이터베이스를 호스팅하기 위해 하나의 데이터베이스를 호스팅하기 위해 더 빠른 하드웨어에 투자해야하는 경우 고객을 더 작고 저렴한 데이터베이스 서버로 확장 할 수있는 것보다 더 비쌀 것입니다. 서버 소프트웨어에 크게 의존하기 때문에 확실하게 말할 수는 없습니다. MySQL을 고수한다면 라이센스 비용이 무시할 수 있기 때문에 이것은 아마도 사실 일 것입니다. 그러나 예를 들어 SQL Server로 이동하면 VPS 환경을 사용하지 않고 확장 및 변경 확장의 비용 이점을 사용하지 않으면 확장이 훨씬 더 비쌉니다. 그러나 데이터베이스가 매우 커지면 관리에 더 많은 전문 지식이 필요합니다. 매우 큰 데이터베이스는 여러 파일 그룹을 가지고 놀고 더 나은 성능을 얻기 위해 특정 인덱스를 다른 스핀들로 푸시해야합니다. 요컨대, 그들은 매우 빨리 복잡해질 수 있습니다.

별도의 데이터베이스가 있다는 것은 데이터베이스 버전과 응용 프로그램 / 사이트 버전이 일치하는 업데이트 메커니즘을 구축해야한다는 것을 의미합니다. 그러나 별도의 데이터베이스는 탁월한 데이터 격리 기능을 제공하며 IMO는 호스팅 비용이 저렴합니다. 모든 시나리오에 대한 솔루션은 아닙니다. 시스템을 호스팅 외부에서 호스팅하지 않고 고객을 빠르게 확장해야하고 동일한 버전의 응용 프로그램 및 데이터베이스 스키마에있는 모든 사용자를 확보해야하는 경우 단일 데이터베이스를 사용하는 것이 더 나은 방법입니다.

내 경험상 고객 당 하나의 데이터베이스를 작성해서는 안됩니다. 예를 들어 보겠습니다.

작년에는 70 개의 데이터베이스 (5000 개 미만)를 사용했으며 각각은 동일한 스키마와 모두를 사용했습니다. 이론적으로 상황은 (장점 섹션에서 언급 한대로) 계획대로 진행되지만 실제로는 그리 많지 않습니다. 스키마 업데이트, 사용자 지원, 소프트웨어 업데이트 등 많은 문제가있었습니다. 그것은 끔찍했다.

우리는 파이어 버드를 사용했는데 제품이 배송 된 후 고용되었는데, 분리 된 데이터베이스로 작업 할 수 없다는 것을 알게되었습니다.

나는 당신이 그것을 뽑을 수 없다고 말하는 것이 아니라, 일이 매우 잘못 되고 솔직하게 말할 수 있다는 것입니다 . 당신의 이점 목록은 위험을 감수하기에 충분히 매력적이지 않습니다. 이들 중 대부분은 단일 데이터베이스로 수행 할 수 있습니다.

각 고객의 버전을 추적하기 위해 다른 데이터베이스를 유지하고 싶을 수 있으므로 마지막 수정 라운드를 수행했거나하지 않은 것을 추적 할 수 있습니다.

업그레이드 스크립팅은 그렇게 어렵지 않을 것입니다 ... 데이터베이스 카탈로그를 살펴보고 각 데이터베이스를 최신 버전으로 가져 오기 위해 필요한 변경 사항을 적용하여 어떤 이유로 업그레이드해서는 안되는 것을 건너 뛸 수 있습니다.

Gaius가 지적한 것처럼 mysql 'databases'는 단순한 스키마이기 때문에 모두 동일한 서버 인스턴스에서 실행되는 경우 수정하려는 테이블의 이름을 한정하거나 정보를 가져올 수 있습니다.

alter schema.table ...
select ... from schema.table

...

여러 서버에서 문제를 일으키더라도 여러 서버에 연결하는 스크립트를 작성하여 모든 변경 사항을 적용 할 수 있습니다. 분석 을 위해 마스터 데이터베이스의 페더 레이 티드 테이블 을 사용하여 한 테이블 에서 데이터에 액세스 할 때 한 테이블 에서 데이터에 액세스 할 수 있도록 여러 데이터베이스 링크를 설정할 수 있습니다.

...

또한 스택 교환에 mySQL을 사용하지 않고 SQL Server를 사용하고 있습니다.

그리고 그 규모의 mysql에 어떤 종류의 성능 오버 헤드가 있는지 전혀 알지 못합니다 .mysql에서 30 개의 '데이터베이스'를 지난 적이 있다고 생각하지 않습니다.

동일한 수의 테이블 (162)과 동일한 테이블 구조를 가진 750 개 이상의 고객 데이터베이스가있는 Web / DB Hosting 클라이언트가 있습니다. 고객의 모든 고객 데이터를 합하면 총 524GB (95 % InnoDB)

순환 복제를 통해 9 개의 DB 서버에서 13G의 innodb 버퍼 풀에 대해 경쟁하는 모든 데이터베이스를 상상해보십시오. 해당 하드웨어 구성으로 확장하는 것만으로는 충분하지 않습니다. 즉시 클라이언트에게 확장을 권장했습니다.

우리는 최근에이 클라이언트를 훨씬 더 강력한 성능을 가진 3 대의 DB 서버로 마이그레이션했습니다 (고비용 환경에서는 항상 !!!). MySQL 5.0.90에서 MySQL 5.5.9로 업그레이드했습니다. 극적인 차이가 거의 즉시 나타났습니다.

동일한 메모리 및 디스크 리소스를 사용하는 수백 명의 클라이언트가있는 경우 스케일 아웃을 사용하면 사용량이 선형으로 감소하므로 (O (n)) 여기서 n은 멀티 마스터 환경의 DB 서버 수를 기반으로합니다.

내 고객의 경우, 회사는 그를 MySQL DB의 9 개의 DB 서버 (Quad Code, 32GB RAM, 824G RAID10)에서 더 빠른 DB 서버 (Dual HexaCore [CPU 12 개], 192GB RAM, 1.7TB RAID10)로 축소했습니다. .9 (테이블은 여러 CPU를 활용). 또한 각각 3GB의 50 개 파티션에서 150GB innodb 버퍼 풀을 상상해보십시오 (여러 개의 InnoDB 버퍼 풀은 MySQL 5.5의 새로운 기능입니다). 소규모 확장, 대규모 확장은 고객의 고유 한 인프라에서 작동했습니다.

스토리의 주제 : 테이블을 잘못 디자인 한 경우 스케일 업 또는 스케일 아웃이 항상 해결책은 아닙니다. 의미하는 바는 다음과 같습니다. 인덱스 페이지에 다중 열 인덱스에 대해 lopsided 키 채우기가있는 경우 인덱스의 lopsided 부분에서 키를 쿼리하면 테이블 스캔 후 테이블 스캔이 발생하거나 적어도 MySQL 쿼리에서 배제되어 사용되지 않는 인덱스가 생성됩니다. 옵티 마이저. 적절한 디자인을 대체 할 수있는 것은 없습니다.

MySQL은 별도의 디렉토리에 데이터베이스를 생성하므로 기본 운영 체제와 처리 할 수있는 폴더 / 파일 핸들 수에 따라 달라집니다. 최신 운영 체제에서는 문제가되지 않지만 많은 병목 현상이 발생합니다.

다른 버전의 데이터베이스 또는 앱을 호스팅해야한다는 말은 없습니다. 고객 당 하나의 db를 수행하고 하나의 버전의 데이터베이스와 앱을 사용하여 단순히 데이터를 격리하는 것은 무엇이 문제입니까? 물론 각 고객 DB는 현재 작업 버전의 템플릿에서 복제해야합니다. 보안 및 데이터 격리 관점에서 이것이 이상적이라고 생각합니다.

내가 볼 수있는 유일한 단점은 새 버전을 만들 때 각 데이터베이스를 수동으로 업데이트해야한다는 것입니다. 그래도 쉽게 자동화 할 수 있습니다.