하나의 SQL Server에 배치 할 수있는 데이터베이스 수에 제한이 있습니까?

각 고객에게 고유 한 데이터베이스를 제공 할 계획 인 SaaS 시스템을 설정하고 있습니다. 로드가 너무 커지면 추가 서버로 쉽게 확장 할 수 있도록 시스템이 이미 설정되어 있습니다. 우리는 수천 명, 심지어 수만 명의 고객이 있기를 바라고 있습니다.

질문

• 하나의 SQL Server에서 가질 수 있거나 가질 수있는 마이크로 데이터베이스 수에 실질적인 제한이 있습니까?
• 서버 성능에 영향을 줄 수 있습니까?
• 각각 100MB의 데이터베이스 10,000 개 또는 1TB의 데이터베이스 하나를 사용하는 것이 더 낫습니까?

추가 정보

"마이크로 데이터베이스"라고 말할 때 실제로 "마이크로"를 의미하는 것은 아닙니다. 우리는 수천 명의 고객을 목표로하고 있기 때문에 각 개별 데이터베이스는 전체 데이터 스토리지의 1000 분의 1 이하에 불과합니다. 실제로 각 데이터베이스는 사용량에 따라 100MB 정도입니다.

10,000 개의 데이터베이스를 사용하는 주된 이유는 확장 성 때문입니다. 사실, 시스템의 V1에는 하나의 데이터베이스가 있으며 DB가로드 상태에서 변형 될 때 불편한 순간이있었습니다.

위의 모든 CPU, 메모리, I / O에 부담을주었습니다. 비록 우리가 그 문제들을 고치더라도, 세계에서 가장 좋은 색인을 생성하더라도, 원하는만큼 성공한다면, 모든 데이터를 하나의 큰 혼킨에 넣을 수는 없다는 것을 깨닫게되었습니다 '데이터베이스. 따라서 V2의 경우 샤딩을 수행하므로 여러 DB 서버간에로드를 분할 할 수 있습니다.

작년에이 샤드 솔루션을 개발했습니다. 서버 당 하나의 라이센스이지만 Azure에서 VM을 사용하기 때문에 어쨌든 처리됩니다. 문제가 지금 제기되는 이유는 이전에 우리가 대규모 기관에만 제공하고 각 기관을 직접 설립했기 때문입니다. 다음 비즈니스 순서는 브라우저를 가진 사람은 누구나 가입하고 자신의 데이터베이스를 만들 수있는 셀프 서비스 모델입니다. 그들의 데이터베이스는 대규모 기관보다 훨씬 작고 훨씬 더 많습니다.

Azure SQL Database Elastic Pools를 시도했습니다 . 성능이 매우 실망스러워 일반 VM으로 다시 전환했습니다.

단일 인스턴스에서 8-10 만 개의 데이터베이스가있는 SQL Server에서 작업했습니다. 예쁘지 않아요.

서버를 다시 시작하는 데 1 시간 이상 걸릴 수 있습니다. 10,000 개의 데이터베이스에 대한 복구 프로세스를 고려하십시오.

SQL Server Management Studio를 사용하여 개체 탐색기에서 데이터베이스를 안정적으로 찾을 수 없습니다.

백업이 가치가 있기 위해서는 실행 가능한 재해 복구 솔루션이 필요하기 때문에 백업은 악몽입니다. 바라건대 당신의 팀은 모든 것을 스크립팅 하는 데 능숙합니다 .

당신은 같은 번호로 데이터베이스를 이름처럼 일을 시작 M01022하고 T9945. 예를 들어 M001022대신에 올바른 데이터베이스에서 작업하고 있는지 확인하는 M01022것은 열광적 일 수 있습니다.

많은 데이터베이스에 메모리를 할당하면 많은 비용이 듭니다. SQL Server는 결국 많은 I / O를 수행하므로 성능이 저하 될 수 있습니다. 10,000 개 회사에 대해 4 개의 테이블에서 탄소 사용량 세부 사항을 기록하는 시스템을 고려하십시오. 하나의 데이터베이스에서이를 수행하면 4 개의 테이블 만 필요합니다. 10,000 개의 데이터베이스에서이 작업을 수행하면 갑자기 메모리에 4 만 개의 테이블이 필요합니다. 메모리에서 해당 테이블 수를 처리하는 오버 헤드는 상당합니다. 사용중인 데이터베이스가 10,000 개인 경우 해당 테이블에 대해 실행하도록 디자인 한 쿼리 에는 계획 캐시에 10,000 개 이상의 계획 이 필요 합니다.

위의 목록은 이러한 종류의 규모로 운영 할 때 계획해야 할 작은 문제 샘플입니다.

SQL Server 서비스와 같이 시작하는 데 시간이 오래 걸리므로 서비스 컨트롤러 오류가 발생할 수 있습니다. 서비스 시작 시간을 직접 늘리고 다음 레지스트리 항목을 작성할 수 있습니다.

하위 키 : HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control
이름 : ServicesPipeTimeout
유형 : REG_DWORD
데이터 : 서비스 시작 중 시간 초과가 발생하기 전의 밀리 초

예를 들어 서비스 시간이 초과되기 전에 600 초 (10 분) 동안 대기하려면 600000을 입력하십시오.

내 대답을 쓴 후 Azure에 대한 질문이라는 것을 깨달았습니다. 아마도 SQL 데이터베이스에서이 작업을 수행하는 것은 그리 문제가되지 않습니다. 아마도 더 문제가 될 수 있습니다. 개인적으로, 아마도 단일 데이터베이스를 사용하여 시스템을 설계했을 것입니다. 아마도 여러 서버에 수직으로 분할되었지만 고객 당 하나의 데이터베이스는 아닙니다.

따라서 두 가지 방법 모두 장단점이 있습니다. 귀하의 응용 프로그램 또는 귀하가 제공하고자하는 서비스에 대해 더 많이 알지 못하면 결정적인 답변을 드릴 수는 없지만 그 문제에 대한 제 생각은 버리겠습니다.

모든 클라이언트에 대해 1 개의 데이터베이스를 사용해야하는 이유에 대한 제 사례입니다.

찬성

• 쉬운 정비. 하나의 DB가 있으면 유지 관리 작업을 여러 위치가 아닌 한 곳에서만 수행하면됩니다. 백업 할 1000 개의 서로 다른 데이터베이스를 처리하는 악몽을 상상해보십시오. 1000 DB의 통계를 업데이트하거나 인덱스를 다시 작성하는 것은 DBCC CHECKDB어떻습니까?

• 코드 배포. 응용 프로그램 코드 또는보고의 저장 프로 시저에 문제가 있다고 가정 해 봅시다. 빠른 변경이 필요합니다 ... 이제이 변경 사항을 1000+ DB에 배포해야합니다. 아뇨, 고마워요

• 쉬운 가시성. SSMS가 1000+ DB (shudder) 를 열려고했을 뿐입니다 . 실제로 문제를 쓸모 없게 만들고 SSMS를 열고 렌더링하는 데 놀라운 시간이 걸립니다. 괜찮은 명명 규칙을 생각해 낼 수 있다는 것을 명심하십시오.

단점

• 보안. 별도의 DB로 다른 고객 데이터를 가지고 있다면 다른 고객 데이터를 보지 못하게하는 것이 더 쉬울 것입니다. 그러나이를 방지하기 위해 할 수있는 매우 간단한 작업이 있습니다.

• 공연. 고객 당 하나의 DB를 제한한다는 것은 SQL 서버가 쿼리하는 정보를 얻기 위해 적은 양의 데이터를 스캔해야한다는 것을 의미 할 수 있습니다. 그러나 데이터 구조가 적절하고 인덱싱 (및 가능한 파티셔닝)이 좋으면 신중하게 수행하면이 문제를 모두 함께 해결할 수 있습니다. 고객 별 데이터가 포함 된 각 테이블 CompanyID에 오버 헤드를 줄이기 위해 일종의 데이터를 제공하는 것이 좋습니다 .

궁극적으로 가장 좋은 방법은 응용 프로그램을 위해 하나의 DB를 보유하고 DB 자체 내에서 고객 데이터를 분리하는 것입니다. 1000 개 이상의 데이터베이스를 관리하는 악몽과 비교할 때 아무런 문제가 없습니다.

SQL Server의 최대 용량 사양에 따르면 32,767으로 제한됩니다.

성능에 영향을 미치는지 여부는 정답이지만, 성능에 영향을 줄 수있는 방법과 성능에 영향을 줄 수있는 방법은 무수한 요인에 따라 다릅니다.

데이터베이스를 10,000 개의 데이터베이스로 분리해야 할 이유가없는 한 하나의 데이터베이스를 사용합니다. 하나의 백업 또는 10,000 개의 백업? 하나의 무결성 검사 또는 10,000? 10,000 개의 작은 DB를 사용해야 할 충분한 이유가있을 수 있지만이를 결정하기에 충분한 세부 정보를 제공하지 않았습니다. 귀하가 요청한 질문은 매우 광범위하며, 최고의 답변이 무엇인지 아는 사람은 충분하지 않습니다.

여기서 말하는 것은 다중 테넌트 대 다중 인스턴스 아키텍처입니다. 나는 당신이 당신의 질문에 사용하지 않을 때이 용어를 가져 왔지만 이것이 당신이 논의하는 것입니다. "멀티 테넌트 아키텍처"를 Google에 연결하면 풍부한 자원과 토론을 찾을 수 있습니다 그것에 대해, 책 전체가 쓰여졌습니다.

SQL Server에 관한 몇 가지 좋은 리소스는 다음과 같습니다.

https://msdn.microsoft.com/en-us/library/ff966499.aspx

https://docs.microsoft.com/en-us/azure/sql-database/sql-database-design-patterns-multi-tenancy-saas-applications

다중 응답 을 선호하는 강력한 이유가없는 한, 기본적으로 다중 테넌트에 강하게 의존한다는 점에서 다른 답변이 있습니다 .

확장하기 위해 수천 개의 개별 클라이언트 데이터베이스로 분할 할 필요가 없으며,이를 수행하는 다른 많은 방법이 있습니다. 클러스터링, 복제, 샤딩, 파티셔닝 등과 같이 휠을 재발 명하지 마십시오. 이를 개별 고객 수준에서 직접 수동으로 분할해야한다고 말하고 실제로 그렇게하면 모든 새 고객을 추가하는 비용이 크게 증가 할 수 있습니다.

고객의 "수백만"에 대해 이야기하고 있습니다. 대규모 클라우드 기반 소프트웨어를 서비스로 생각하면 Gmail은 각각 새로운 가입마다 완전히 새로운 데이터베이스를 생성한다고 생각하지 않습니다.

예를 들어 자체 인프라에서 사내 호스팅해야하는 고객에게 제품을 판매하는 경우이를 촉진하려는 이유가있을 수 있습니다. 그러나 일반적인 SAAS 규칙에 따라 다중 테넌트 아키텍처의 기본값으로 생각하십시오.

단일 데이터베이스 제안에서 볼 수있는 단점 중 하나는 데이터 롤백과 관련이 있습니다. 테넌트 설정 당 데이터베이스가있는 경우 각 클라이언트의 데이터를 독립적으로 (및 특정 시점으로) 복원 할 수 있습니다. 그것들이 모두 하나의 데이터베이스에 있다면, 이것은 훨씬 더 어려워집니다 (INSERT / UPDATE / DELETE 문을 통해 수행되어야 할 것이므로 오류가 발생하기 쉽습니다).

답변 한 모든 분들께 감사드립니다. 여러분이 생각한 점에 감사드립니다. 내가 얻은 일반적인 느낌은 단일 데이터베이스가 바람직하지만 샤드 아키텍처를 선호하고 다른 사람들이 언급 한 우려를 해결하기 위해 상반되는 점을 추가하고 싶습니다.

샤딩 동기 부여

(업데이트 된) 질문에서 언급했듯이, 우리는 문자 그대로 수백만 명의 사용자가있는 전 세계의 대규모 판매를 목표로하고 있습니다. 세계 최고의 하드웨어 및 인덱싱으로 단일 DB 서버는로드를받지 않으므로 여러 서버에 분산 할 수 있어야합니다. 그리고 주어진 고객 데이터가있는 서버를 찾아야한다면, 전용 데이터베이스를 제공하는 것이 그리 중요하지 않아 사람들의 데이터를 깔끔하게 분리하는 측면에서 훨씬 간단 해집니다.

우려에 대한 대응

• 서버를 다시 시작하는 데 시간이 오래 걸립니다. 정상이지만 정상적인 작동에서는 서버를 다시 시작하지 않습니다. 시스템은 궁극적으로 연중 무휴 온라인 상태 여야하므로 가동 중지 시간이 발생하면 예약해야합니다.
• 백업 / 재해 복구 : 모든 것을 자동화하는 CloudBerry를 사용하고 있습니다. 문제가 아니다.
• SSMS에서 데이터베이스 이름 지정 / 위치 지정 : 고객 이름을 기준으로 이름 지정 규칙을 쉽게 수행 할 수 있습니다. 이름이 공유되면 일련 번호를 추가하십시오.
• 유지 관리 : 각 데이터베이스의 크기가 생각보다 작 으면 인덱스를 수동으로 다시 작성할 필요가 없습니다.
• 코드 배포 : Entity Framework를 사용하므로 모든 스키마 변경 사항이 새 릴리스와 함께 각 데이터베이스에 자동으로 배포됩니다. 그러나 간단한 인덱스 조정으로 해결할 수있는 프로덕션 성능 문제를 발견하면 쉽게 밀어 낼 수는 없습니다. 반면에 각 데이터베이스가 너무 작 으면 프로덕션 샤드에서 성능 문제가 발생할 가능성이 거의 없습니다. 그리고 공통 데이터베이스는 단일 DB로 남아 있으며 이러한 우려 사항이 적용되지 않습니다.

당신이 내가 아무것도 빠졌다고 생각하면 의견에 당신의 의견을 드리겠습니다.