우리는 대규모 엔터프라이즈 급 데이터베이스를 보유하고 있습니다. 비즈니스 모델의 일부로 모든 웹 사용자는 매월 같은 시간에 웹 서버에 접속하여 SQL 상자를 망치게됩니다. 트래픽은 매우 무거 우며 회사가 커질수록 계속 커집니다. sql proc 최적화가 수행되었으며 하드웨어는 이미 매우 높은 수준으로 확장되었습니다.
우리는 회사의 성장과 미래의 부하를 처리 할 수 있도록 지금 데이터베이스를 분할하려고합니다.
어떤 특정 데이터를 샤딩해야하는지 결정했습니다. 그것은 우리의 데이터베이스의 부분 집합으로 많이 활용됩니다.
그러나 내 질문은 공통적이며 보편적 인 비 샤드 데이터에 관한 것입니다. 이와 같은 데이터의 예로는 인벤토리 테이블 또는 직원 테이블, 사용자 테이블 등이 있습니다.
이 공통 / 유니버설 데이터를 처리하는 두 가지 옵션이 있습니다.
1) 설계 1-공통 / 유니버설 데이터를 외부 데이터베이스에 배치합니다. 모든 쓰기가 여기에서 발생합니다. 그런 다음이 데이터는 각 샤드로 복제되어 각 샤드가이 데이터를 읽고 t-sql procs에서이 데이터에 대한 내부 조인을 허용합니다.
2) 디자인 2-각 샤드에 모든 공통 / 유니버설 데이터의 자체 사본을 제공하십시오. 각 샤드가 이러한 테이블에 로컬로 쓰도록하고 SQL 병합 복제를 사용하여 다른 모든 샤드에서이 데이터를 업데이트 / 동기화합니다.
디자인 # 1에 대한 우려
1) 트랜잭션 문제 : 샤드에 데이터를 쓰거나 업데이트 한 다음 예를 들어 1 개의 저장된 프로 시저에서 공통 / 유니버설 테이블을 쓰거나 업데이트해야하는 상황이 발생하면 더 이상이를 쉽게 수행 할 수 없습니다. 데이터는 이제 별도의 SQL 인스턴스 및 데이터베이스에 존재합니다. 이러한 쓰기가 별도의 데이터베이스에 있기 때문에 이러한 쓰기를 트랜잭션으로 래핑 할 수 있는지 확인하려면 MS DTS를 포함해야 할 수도 있습니다. 여기서 성능은 문제가되며 샤드 및 공통 데이터에 쓰는 프로세스에는 재 작성이 필요할 수 있습니다.
2) 참조 무결성 손실. 데이터베이스 간 참조 무결성을 수행 할 수 없습니다.
3) 공통 데이터를 새로운 범용 데이터베이스에 쓰지만 샤드에서 공통 데이터를 읽는 것을 알 수 있도록 시스템의 넓은 영역을 레코딩합니다.
4). 데이터베이스 트립 증가 위의 # 1과 같이 샤드 데이터와 공통 데이터를 업데이트해야하는 상황이 발생하면 데이터가 별도의 데이터베이스에 있으므로 여러 번의 왕복을 수행하여이 작업을 수행합니다. 여기에 약간의 네트워크 대기 시간이 있지만 위의 3만큼이 문제에 대해 걱정하지 않습니다.
디자인 # 2에 대한 우려
디자인 # 2에서 각 샤드는 모든 공통 / 유니버설 데이터의 자체 인스턴스를 가져옵니다. 이는 공통 데이터에 참여하거나 업데이트하는 모든 코드가 오늘날처럼 계속 작동 / 실행됨을 의미합니다. 개발 팀에서 필요한 레코딩 / 재기록은 거의 없습니다. 그러나이 디자인은 병합 복제에 전적으로 의존하여 모든 샤드에서 데이터를 동기화합니다. dbas는 매우 숙련되어 있으며 병합 복제가이를 처리하지 못할 수 있으며 병합 복제가 실패해야하는 경우,이 실패로부터의 복구가 크지 않으며 우리에게 매우 부정적인 영향을 줄 수 있다는 점에 매우 우려하고 있습니다.
누군가 디자인 옵션 # 2를 사용했는지 알고 싶습니다. 또한 내가 보지 못한 3 또는 4 디자인 옵션을 간과하는지 알고 싶습니다.
미리 감사드립니다.