샤딩의 문제점은 애플리케이션이 쿼리 할 샤드를 알아야한다는 것입니다. 일반적으로 이것은 클라이언트와 같은 것을 샤딩하여 수행됩니다. 나는 적응거야 내 옛날 블로그 게시물 중 하나를 내 대답으로 사용할 수 있습니다.
많은 클라이언트를위한 응용 프로그램을 구축 할 때 데이터베이스를 디자인하는 일반적인 두 가지 방법이 있습니다.
- 옵션 A : 모든 클라이언트를 동일한 데이터베이스에 배치
- 옵션 2 : 클라이언트 당 하나의 데이터베이스 작성
모든 클라이언트를 같은 데이터베이스에두기
간단합니다. 스키마 상단에 Client 테이블을 추가하고 ClientUsers 테이블을 추가하여 사람들이 자신의 데이터 만 볼 수 있도록합니다.
이 방법의 장점 :
더 쉬운 스키마 관리. 개발자가 새 버전의 응용 프로그램을 배포 할 때 하나의 데이터베이스에서만 스키마를 변경하면됩니다. 서로 다른 고객이 동기화되지 않았거나 잘못된 버전을 사용하는 것에 대해 걱정할 필요가 없습니다.
보다 쉬운 성능 조정. 한 곳에서 색인 사용 및 통계를 확인하고, 쉽게 개선을 구현하며, 모든 고객에게 즉시 영향을 확인할 수 있습니다. 수백 또는 수천 개의 데이터베이스를 사용하면 아주 작은 변경이라도 조정하기가 어려울 수 있습니다. 프로 시저 캐시 내용을 확인하고 전체 응용 프로그램에서 가장 집중적 인 쿼리 또는 저장 프로 시저를 확인할 수 있지만 클라이언트마다 별도의 데이터베이스를 사용하는 경우 다른 실행 계획에서 쿼리 사용을 집계하는 데 시간이 더 걸릴 수 있습니다.
외부 API를 쉽게 구축 할 수 있습니다. 외부인이 제품을 빌드 할 수 있도록 전체 데이터베이스에 대한 액세스 권한을 부여해야하는 경우 모든 데이터가 단일 데이터베이스에있는 경우 더 쉽게 수행 할 수 있습니다. API가 여러 서버의 여러 데이터베이스에서 데이터를 그룹화해야하는 경우 개발 및 테스트 시간이 추가됩니다. 반면에,“다중 서버”는 단일 데이터베이스에서 규칙까지의 모든 시나리오에 대한 제한을 암시하기 시작합니다. 하나의 데이터베이스는 일반적으로 모든로드가 하나의 데이터베이스 서버에만 영향을 미칩니다. PowerBI를 사용하면 하나의 데이터베이스에 모든 사람이 있으면 연결 관리가 훨씬 쉬워집니다.
고 가용성 및 재해 복구가 쉬워집니다. 데이터베이스 미러링, 로그 전달, 복제 및 클러스터링을 관리하기가 정말 간단합니다. 데이터베이스 하나만 걱정하면됩니다. 우리는 신속하게 인프라를 구축 할 수 있습니다.
자체 데이터베이스 또는 샤드에 각 클라이언트 배치
여전히 클라이언트 목록이 필요하지만 이제는 디렉토리가됩니다. 각 클라이언트에 대해 샤드도 추적합니다. 시작시 앱이이 테이블을 쿼리하고 RAM에 캐시합니다. 클라이언트에 대한 데이터가 필요한 경우 해당 샤드 (데이터베이스 및 서버)에 직접 연결됩니다.
이 방법의 장점 :
더 쉬운 단일 클라이언트 복원. 고객은 신뢰할 수없는 미트 백입니다. (제외 – 그들은 믿을 수있는 미트 백입니다.) 그들은 모든 데이터를 특정 시점으로 되돌리려 고하는 모든 종류의 "oops"순간을 가지고 있습니다. 동일한 테이블의 다른 클라이언트 데이터 단일 클라이언트 데이터베이스 시나리오에서의 복원은 매우 간단합니다. 단지 클라이언트 데이터베이스를 복원하면됩니다. 다른 사람은 영향을받지 않습니다.
더 쉬운 데이터 내보내기. 고객은 데이터를 손에 넣는 것을 좋아합니다. 그들은 까다로운 공급 업체 잠금 시나리오를 피하면서 원하는 시간에 데이터를 얻을 수 있다는 사실을 알고 보안을 원하며 자체보고를 원합니다. 각 클라이언트의 데이터를 자체 데이터베이스로 분리하면 자체 데이터베이스 백업 사본을 제공 할 수 있습니다. 데이터 내보내기 API를 구축 할 필요가 없습니다.
보다 쉬운 다중 서버 확장 성. 애플리케이션이 단일 서버에서 얻을 수있는 것보다 더 많은 전력을 필요로하는 경우 데이터베이스를 여러 서버로 나눌 수 있습니다. 또한 지리적으로 부하를 분산시켜 아시아나 유럽의 서버를 고객과 더 가깝게 만들 수 있습니다.
보다 쉬운 클라이언트 별 성능 조정. 일부 고객이 다른 기능이나 보고서를 사용하는 경우 모든 사용자의 데이터 크기를 늘리지 않고도 해당 고객을 위해 특수화 된 색인 또는 색인 된보기를 작성할 수 있습니다. 여기에는 약간의 위험이 있습니다. 클라이언트 간의 스키마 차이를 허용함으로써 코드 배포를 조금 더 위험하게 만들고 성능 관리를 더욱 어렵게 만들었습니다.
보다 쉬운 보안 관리. 데이터베이스 당 한 명의 사용자로 보안을 제대로 잠그면 Client X가 Client Y의 데이터에 액세스하는 것에 대해 걱정할 필요가 없습니다. 그러나 모든 사용자에게 단일 로그인 만 사용하는 경우 실제로 이러한 문제를 해결하지 못했습니다.
더 쉬운 유지 관리 기간. 전 세계에 고객이 흩어져있는 글로벌 환경에서는 그룹이나 영역에서 고객을 유지 관리하기 위해 오프라인 상태로 유지하는 것이 더 쉽습니다.
어느 것이 당신에게 옳습니까?
올바른 선택은 없습니다. 회사의 강점과 약점을 알아야합니다. 내 고객 중 두 명을 예로 들어 봅시다.
회사 A는 하드웨어 성능 조정에 탁월합니다. 그들은 실제로 하드웨어에서 가장 마지막 성능을 발휘하는 데 능숙하며 12-18 개월 주기로 SQL Server 하드웨어를 교체하는 것을 신경 쓰지 않습니다. (4-6 개월마다 웹 서버를 새로 고칩니다!) Achilles의 발 뒤꿈치는 극한의 준수 및 보안 요구 사항입니다. 감사 요구 사항이 엄청 나며 수십 대의 서버에서 수천 개의 데이터베이스에 대한 요구 사항을 관리하는 것보다 단일 서버의 단일 데이터베이스에서 방탄 제어를 구현하는 것이 더 쉽습니다. 그들은 하나의 데이터베이스, 하나의 서버, 많은 클라이언트를 선택했습니다.
회사 2는 개발 관행에 탁월합니다. 수천 개의 데이터베이스에서 스키마 변경 및 코드 배포를 관리하는 것은 문제가되지 않습니다. 전 세계에 고객이 있으며 24 시간 내내 해당 고객에 대한 신용 카드 거래를 처리하고 있습니다. 지리적으로로드를 분산시킬 수있는 능력이 필요하며 12-18 개월마다 전세계 서버를 교체하고 싶지 않습니다. 그들은 각 클라이언트마다 하나의 데이터베이스를 선택했으며, 해외 클라이언트를 위해 아시아와 유럽에 SQL Server를 설치하기 시작하면서 비용을 지불하고 있습니다.