50.000+ 상점에 하나의 데이터베이스를 사용하는 것이 좋은 생각입니까?

Shopify는 모든 상점에 대해 하나의 데이터베이스 만 사용한다는 것을 알고 있습니다. 그러나 이러한 빅 데이터로 데이터베이스를 어떻게 처리 할 수 ​​있습니까? 50.000+ 상점에 단일 데이터베이스를 사용하는 것이 좋은 생각입니까?

참고 : SQL Server 관점에서 대답하고 있으므로 SQL Server와 관련된 몇 가지 개념을 언급하지만 이러한 모든 개념은 다른 주요 RDBMS 플랫폼과 동등한 이점이 있으며 비슷한 이점과 제한 사항이 있습니다.

다른 잠재적 인 장단점을 생각할 때이 답변을 계속 편집 할 것입니다.

글쎄, 그것은 실제로 스키마, 볼륨 등에 달려 있습니다. 상점 저장은 정확히 무엇입니까? 고양이 50,000 마리 또는 제품 50,000 개 또는 윙넛 50,000 개에 대한 데이터를 저장하는 것과 어떻게 다릅니 까?

고객이 데이터를 완전히 분리 할 수있는 경우 (우편 번호 나 응용 프로그램 별 테이블 (단일 중앙 데이터베이스로 이동할 수 있음) :

• 한 고객이 응용 프로그램을 빨리 성장하는 경우, 당신은 앞서와 같은에 파티션 계획이 아니라면, 밖으로 확장 단지 그들의 데이터를 추출 등 다른 인스턴스, 서버로 이동하는 쉬운 방법이 없다 CustomerID당신이있어 (50,000 파일 그룹이 제한은 어쨌든 15,000 개의 파티션 , 또는 이전 버전의 SQL Server 인 경우 파일 그룹이 너무 많으면 비참 할 수 있습니다 ( 1,000 ). 또한 파티셔닝에는 Enterprise Edition이 필요합니다.

• 모든 고객이이 인스턴스에 비해 너무 큰 것으로 판명되면 스케일 아웃이란 새로운 하드웨어를 가져와 전체 데이터베이스를 그곳으로 옮기는 것을 의미합니다.

• 매우 큰 테이블에서 일부 %의 행을 삭제해야하므로 고객을 삭제하는 것도 똑같이 고통 스러울 수 있습니다.

• 고객 데이터가 광범위하게 배포 될 수 있습니다 (한 행에 10 억 행을 보유한 고객, 5,000 명을 보유한 다른 고객). 이로 인해 카디널리티 및 계획 품질과 관련된 매개 변수 스니핑 및 유해한 성능이 발생할 수 있습니다 (매우 다른 데이터 세트에 대해 동일한 쿼리에 대해 동일한 계획을 재사용 할 것이므로).

• 모든 고객에게 동일한 SLA 및 HA / DR 계획이 적용됩니다. n 분 로그 백업으로 전체 데이터베이스를 전체 복구 모드로 설정했거나 단순하고 전체 + 차등 백업에 의존합니다. 고객 오류로 인해 되돌려 야하거나 특정 시점으로 데이터베이스를 복구해야하는 경우 모든 단일 고객에게 영향을 미칩니다.

• 예를 들어 where 절의 버그는 한 고객이 다른 고객의 데이터를 보거나 다른 고객의 모든 데이터를 보게 할 수 있습니다 .

• 법적 영향이있을 수 있습니다 (일부 회사는 다른 회사와 같은 데이터베이스, 특히 경쟁 업체의 데이터베이스에 데이터를 배치하지 않아야하는 엄격한 요구 사항이 있습니다).

• 한 고객의 데이터 보안이 중요한 경우, 테이블 내 분리보다 데이터베이스 분리를 ​​사용하여 훨씬 쉽게 달성 할 수 있습니다.

각 고객을 별도의 데이터베이스 (또는 고객 그룹마다 각각 여러 데이터베이스를 보유)로 갖는 이점은 다음과 같습니다.

• 크기면에서 디스크의 크기는 거의 같습니다.
• 데이터베이스 (또는 다수)를 다른 서버로 옮기기 만하면 확장이 더 쉬워집니다.
• 고객과 모든 데이터를 삭제하면 대략 다음과 같습니다 DROP DATABASE.
• 계획에 더 많은 메모리를 사용하고 있거나 고객 당 캐시에 더 적은 계획이 있지만 최소한 이러한 계획은 각 데이터베이스의 데이터와 관련이 있으며 통계 / 매개 변수 스니핑 문제가 덜 발생합니다.
• 서로 다른 SLA 및 DR 계획을 쉽게 가질 수 있으며 일부 데이터베이스는 전체를 배치하고 다른 데이터베이스는 단순하게 배치 할 수 있습니다. 또한 특정 시점으로 되돌 리거나 복원하면 해당 고객에게만 영향을줍니다.
• 빠른 I / O에 서로 다른 데이터베이스 (예 : 우선 순위가 높은 고객)를 쉽게 배치 할 수 있습니다. 파일 그룹이있는 단일 데이터베이스에서이 작업을 수행 할 수 있지만 관리하기가 훨씬 더 어렵습니다 (적어도 IMHO).

몇 가지 단점 :

• 크기를 제외하고는 단일 SQL Server 인스턴스에 50,000 개의 데이터베이스를 원하지 않을 것이므로 여러 서버로 확장 할 수 있습니다.
• 각 데이터베이스를 시작할 때 고유 한 오버 헤드가 있기 때문에 시작 시간이 길어집니다.
• where 절에 CustomerID를 사용하는 대신 앱이 조금 더 똑똑해야합니다. CustomerID의 데이터베이스에 동적으로 연결해야합니다. 적절한 중간 계층에서는 어렵지 않지만 변경 사항입니다.
• 예, 동일한 테이블과 프로 시저의 사본이 많이 있지만 코드와 스키마는 데이터베이스에서 동일하지만 데이터 만 다릅니다. 따라서 코드 / 스키마 변경 사항 배포는 이제 단일 실행이 아닌 루프 일뿐입니다.
• 유지 관리는 50,000 개의 데이터베이스를 관리 할 때 약간 다릅니다. 다시 전체 크기는 거의 동일하지만 프로세스를 변경해야합니다. 모든 50,000 개의 데이터베이스를 한 번에 조각 모음 / 다시 색인화 / 백업 할 수는 없습니다. 이전 작업에서 500-1,000 개의 동일한 데이터베이스가있는 인스턴스를 관리했으며 3 개의 동일한 데이터베이스와 750 개의 동일한 데이터베이스를 관리하는 것의 차이점은 단순히 시간이 걸린다는 것입니다.