100 개 이상의 클라이언트 DB의 데이터를 중앙보고 데이터베이스에 통합하는 방법에 대한 조언을 찾고 있습니다.

소규모 (~ 50 명) SaaS 회사의 SQL 개발자 (DBA 또는 아키텍트 아님)입니다. 나는 방법을 알아내는 임무를 맡았습니다.

1. 100 개 이상의 OLTP 데이터베이스에서 운영보고를 오프로드
2. 해당 보고서가 여러 클라이언트 데이터베이스의 데이터에 대해 실행되도록 허용
3. 향후 더 많은 분석 기반 솔루션을 제공 할 수 있도록 회사를 배치

트랜잭션 복제 (특히 다 대일 / 중앙 가입자 모델), SQL 서비스 브로커, 로그 전달, 변경 추적 (CT) 및 변경 데이터 캡처 (CDC)와 같은 다양한 기술에 대한 많은 기사를 읽었습니다. 이것은 엔터프라이즈 전용)이며 어떤 경로를 추구해야하는지 잘 모르겠습니다.

통합 전문 지식을 보유한 일부 사용자가 Google과 유사한 설정을 사용하여 성공적인 경로를 알려주거나 도움이 될만한 리소스로 안내 할 수 있기를 바랍니다.

비용 제약으로 인해 솔루션은 SQL Server Standard Edition 내에서 작동해야합니다. 또한이 솔루션은 소규모 조직 내에서 지원 / 유지 관리 할 수 ​​있어야합니다.

기본 구성 :

현재 100 개 이상의 개별 클라이언트 데이터베이스가 있으며, 대부분은 데이터 센터의 SQL 서버에 배치되지만 일부는 데이터 센터 내의 클라이언트 서버에 배치되어 원격으로 연결할 수 있습니다. 이들은 모두 SQL Server 2008 R2 데이터베이스이지만 곧 SQL 2016으로 업그레이드 할 계획입니다.

데이터베이스 프로젝트와 dacpac를 사용하여 통합 될 모든 클라이언트 데이터베이스에서 스키마가 동일하도록합니다. 그러나 모든 클라이언트가 동시에 새 버전으로 업그레이드하지는 않기 때문에 업그레이드간에 스키마 차이가있을 수 있습니다. 클라이언트 A가 소프트웨어 버전 1.0에 있고 클라이언트 B가 버전 1.1에 있으면 솔루션이 중단되지 않도록 충분히 유연해야합니다.

운영 보고서는 현재 각 클라이언트의 OLTP 데이터베이스에서 직접 실행됩니다. 애플리케이션을 오프로드하지 않으면 애플리케이션 성능에 미칠 영향에 대해 우려하고 있습니다.

고급 요구 사항 :

당사의 고객은 지금까지 처리 한 내용, 재고가있는 장소 등에 대한 최신 보고서를 원하는 병원 멸균 처리 부서 (SPD)입니다. SPD는 주말 및 공휴일 등 24 시간 내내 재고를 처리합니다. 이 노력의 주요 목적 중 하나는 운영보고를보다 잘 지원하는 것이므로 고객의 요구를 계속 충족시키기 위해 데이터가 가능한 한 실시간에 가깝기를 바랍니다.

현재 우리는 실제로 동일한 병원 시스템의 일부인 별도의 데이터베이스에 일부 SPD가 있습니다. 이러한 고객은 시스템의 모든 SPD에 대해보고 할 수있는 기능을 원합니다.

전략적으로 말하면, 우리는 내부 분석 이니셔티브를 지원하기 위해 모든 클라이언트에서 데이터를 쉽게 집계 할 수있는 기능을 원합니다. 수집 된 운영 데이터를 데이터 마트 /웨어 하우스의 소스로 사용할 수있을 것으로 기대합니다.

지금까지 생각 :

트랜잭션 복제는 가장 "실시간"솔루션을 제공하는 것처럼 보입니다. 이 응답이 특히 도움이된다는 것을 알았지 만 스키마 차이의 가능성으로 인해 우리에게는 효과가 없을 것 같습니다. SQL Server 다 대일 복제

쿼리가 활성화되어있는 동안 로그를 복원 할 수없는 경우 로그 전달은 이상적이지 않습니다. 로그를 복원하거나 데이터가 오래 될 수 있도록 모두를 쫓아 내야합니다. 제공된 각 로그는 제공된 개별 데이터베이스에만 해당되므로이 방법을 사용하여 여러 데이터베이스의 데이터를 중앙 집중화 할 수 있는지 확실하지 않습니다.

SQL 서비스 브로커를 사용하면 큐가 처리 할 메시지 수를 따라갈 수없는 경우 대기 시간을 예측할 수 없습니다.

CT는 각 테이블 행의 버전 만 식별합니다. 지연 시간은 각 데이터베이스에 대해 SSIS 패키지와 같은 데이터를 얼마나 빨리 처리하여 데이터를 검색하고 중앙 저장소에 삽입 할 수 있는지에 달려 있습니다.

각 데이터베이스를 개별적으로 복제 한 다음 일종의 데이터 가상화 기술을 사용하여 다양한 복제 된 소스의 데이터를 결합해야합니까?

당신이 기꺼이 제공하려는 조언이나 지시는 대단히 감사하겠습니다.

각 데이터베이스를 개별적으로 복제 한 다음 일종의 데이터 가상화 기술을 사용하여 다양한 복제 된 소스의 데이터를 결합해야합니까?

예. 단일 인스턴스에서 여러 구독자 데이터베이스를 호스트 한 다음 뷰를 사용하여 쿼리하거나 통합 된 데이터베이스에로드 할 수 있습니다.

위의 설명에 따르면 아래 링크는 당신과 내가 동일한 시나리오에서 작업하는 데 도움이 될 것입니다. 단일 구독자를 가진 여러 게시자.

1. server_id와 같은 하나 이상의 열을 기본값 1,2,3 등으로 추가하고 복합 기본 키로 만듭니다.

2. 서적을 작성하고 기사를 추가 할 때 기사 특성이 이름을 사용중인 경우 조치를 데이터 삭제로 설정해야합니다. 기사에 행 필터가있는 경우 필터와 일치하는 데이터 만 삭제하십시오. 새 게시 마법사 기사 속성 대화 상자를 사용하거나 sp_addarticle 복제 저장 프로 시저를 사용하고 @pre_creation_cmd 인수에 대해 delete 값을 지정하여 설정할 수 있습니다. 이런 방식으로 중앙 구독자가 여러 게시 스냅 샷에서 초기화되거나 다시 초기화되면 필터 절과 일치하는 데이터 만 삭제되므로 이전에 적용된 스냅 샷 데이터가 유지됩니다.

http://www.sqlrepl.com/sql-server/central-subscriber-model-explained/

하나의 가능한 아키텍처 :

데이터웨어 하우스 기반 솔루션으로보고를 고려하십시오.

일반적으로 데이터웨어 하우스는 소스 시스템의 필수 서브 세트를 나타내는 스키마가있는 DB입니다. AdventureWorks와 AdventureworksDW는 이러한 모델링을 보여줍니다.

다음으로 ETL : 소스에서 데이터웨어 하우스로 데이터 이동.

여기서 가능한 구현은 변경 내용 추적을 사용하는 것입니다.

첫째, 소비하는 버전에 따라 버전이 다르지만 반환되는 측면에서 균일 한 뷰를 구현할 수 있습니다. 예를 들어 Person.Gender가 버전 2에는 있지만 버전 1에는없는 경우 버전 1의 사람보기는 버전 1의 경우 null을 반환 할 수 있습니다.

웨어 하우스 소비자의 경우, 뷰만 읽기만하면 데이터의 모양이 동일합니다 (완전성이 다름).

변경 내용 추적은 새로 고칠 때마다 어떤 데이터를 변경해야하는지 결정하는 상대적으로 간단한 방법입니다.

위의 구현은 모두 손수 툴링에 의존하므로 SQL 코딩에 대해 확신하고 성능 시나리오를 테스트하여 증분 실행 속도를 확인해야합니다. 많은 경우에 이들은 1 초 미만일 수 있지만 일부 트랜잭션 테이블은 처리 변경에서 높은로드를 생성 할 수 있습니다. (변경 추적은 '상대적으로'경량입니다 ... 테스트만으로 증명됩니다).

스키마 차이가 어떻게 나타나는지에 대한 높은 수준의 제어가 가능하며 변경 내용 추적을 통해 엔진 수준에서 추적이 수행되므로 올바르게 구현할 때 무결성 문제가 발생하지 않습니다.

이것이 당신에게 꼭 맞는지 말하기는 어렵습니다.