Tìm kiếm lời khuyên về cách tích hợp dữ liệu từ hơn 100 máy khách DB vào cơ sở dữ liệu báo cáo tập trung

Tôi là một Nhà phát triển SQL (không phải DBA hoặc Kiến trúc sư) cho một công ty SaaS nhỏ (~ 50 nhân viên). Tôi được giao nhiệm vụ tìm ra cách để:

1. Giảm tải báo cáo hoạt động từ hơn 100 cơ sở dữ liệu OLTP của chúng tôi
2. Cho phép các báo cáo đó chạy với dữ liệu từ nhiều cơ sở dữ liệu khách hàng
3. Định vị công ty chúng tôi để cung cấp nhiều giải pháp dựa trên phân tích hơn trong tương lai

Tôi đã đọc một số bài viết về các công nghệ khác nhau như sao chép giao dịch (cụ thể là mô hình thuê bao nhiều người / trung tâm), nhà môi giới dịch vụ SQL, vận chuyển nhật ký, Theo dõi thay đổi (CT) và Ghi dữ liệu thay đổi (CDC, tôi hiểu là đây chỉ dành cho doanh nghiệp) và tôi không chắc chắn nên theo đuổi con đường nào là tốt nhất.

Tôi hy vọng một số bạn có chuyên môn tích hợp có thể đã gặp phải một thiết lập tương tự như của chúng tôi và có thể chỉ cho tôi một con đường thành công hoặc hướng tôi đến một số tài nguyên hữu ích.

Do các hạn chế về chi phí, giải pháp của chúng tôi phải hoạt động trong SQL Server Standard Edition. Ngoài ra, giải pháp phải hợp lý để hỗ trợ / duy trì trong tổ chức nhỏ của chúng tôi.

Cấu hình cơ bản:

Chúng tôi hiện có hơn 100 cơ sở dữ liệu khách hàng cá nhân, hầu hết được triển khai trên các máy chủ SQL tại trung tâm dữ liệu của chúng tôi, nhưng một số được triển khai trên các máy chủ của khách hàng trong trung tâm dữ liệu của họ mà chúng tôi có thể truy cập từ xa. Đây là tất cả các cơ sở dữ liệu SQL Server 2008 R2, nhưng chúng tôi đang có kế hoạch nâng cấp lên SQL 2016 sớm.

Chúng tôi sử dụng các dự án cơ sở dữ liệu và dacpac để đảm bảo lược đồ giống nhau trên tất cả các cơ sở dữ liệu khách hàng sẽ được tích hợp. Tuy nhiên, vì chúng tôi không buộc tất cả khách hàng nâng cấp lên phiên bản mới cùng một lúc, một số khác biệt về lược đồ có thể có giữa các lần nâng cấp. Giải pháp phải đủ linh hoạt để không bị hỏng nếu máy khách A ở phiên bản phần mềm 1.0 và máy khách B ở phiên bản 1.1.

Báo cáo hoạt động hiện đang được chạy trực tiếp từ cơ sở dữ liệu OLTP của mỗi khách hàng. Chúng tôi lo ngại về tác động của nó đối với hiệu năng của ứng dụng nếu chúng tôi không giảm tải.

Yêu cầu cấp cao:

Khách hàng của chúng tôi là các bộ phận xử lý vô trùng của bệnh viện (SPD), những người muốn báo cáo cập nhật về những gì họ đã xử lý cho đến nay, nơi tồn kho, v.v. Kiểm kê quy trình của SPD suốt cả ngày, kể cả cuối tuần và ngày lễ. Vì một trong những mục đích chính của nỗ lực này là hỗ trợ tốt hơn cho báo cáo hoạt động, chúng tôi muốn dữ liệu càng gần với thời gian thực càng tốt để tiếp tục đáp ứng nhu cầu của khách hàng.

Hiện tại chúng tôi có một số SPD trong các cơ sở dữ liệu riêng biệt thực sự là một phần của cùng một hệ thống bệnh viện. Những khách hàng này muốn có khả năng báo cáo chống lại tất cả các SPD trong hệ thống của họ.

Nói một cách chiến lược, chúng tôi muốn khả năng dễ dàng tổng hợp dữ liệu trên tất cả các khách hàng của mình để hỗ trợ các sáng kiến ​​phân tích nội bộ của chúng tôi. Kỳ vọng của chúng tôi là chúng tôi sẽ có thể sử dụng dữ liệu vận hành được thu thập làm nguồn cho kho dữ liệu / kho dữ liệu.

Những suy nghĩ cho đến nay:

Nhân rộng giao dịch có vẻ như sẽ cung cấp giải pháp "thời gian thực" nhất. Tôi thấy phản hồi này đặc biệt hữu ích, nhưng tôi lo ngại rằng với tiềm năng về sự khác biệt của lược đồ, nó sẽ không hoạt động đối với chúng tôi: Sao chép nhiều máy chủ SQL Server

Nhật ký vận chuyển không có vẻ lý tưởng cho rằng nhật ký không thể khôi phục trong khi các truy vấn đang hoạt động. Tôi hoặc phải đuổi tất cả mọi người ra để nhật ký có thể khôi phục hoặc dữ liệu sẽ trở nên cũ. Tôi không rõ liệu phương pháp này có thể được sử dụng để tập trung dữ liệu từ nhiều cơ sở dữ liệu hay không, vì mỗi nhật ký vận chuyển sẽ chỉ dành cho cơ sở dữ liệu riêng lẻ mà nó xuất phát.

Sử dụng môi giới dịch vụ SQL, độ trễ có thể không dự đoán được nếu hàng đợi không thể theo kịp số lượng tin nhắn cần xử lý.

CT chỉ xác định một phiên bản cho mỗi hàng của bảng. Độ trễ sẽ phụ thuộc vào mức độ nhanh chóng chúng ta có thể xử lý một cái gì đó như gói SSIS đối với từng cơ sở dữ liệu để lấy dữ liệu và chèn nó vào kho lưu trữ trung tâm.

Chúng ta có cần xem xét sao chép từng cơ sở dữ liệu riêng lẻ và sau đó có thể sử dụng một số loại kỹ thuật ảo hóa dữ liệu để kết hợp dữ liệu từ các nguồn được sao chép khác nhau không?

Bất kỳ lời khuyên hoặc hướng mà bạn sẵn sàng cung cấp sẽ được đánh giá rất cao.

Chúng ta có cần xem xét sao chép từng cơ sở dữ liệu riêng lẻ và sau đó có thể sử dụng một số loại kỹ thuật ảo hóa dữ liệu để kết hợp dữ liệu từ các nguồn được sao chép khác nhau không?

Đúng. Bạn có thể lưu trữ nhiều cơ sở dữ liệu thuê bao trên một trường hợp, sau đó truy vấn chúng bằng các khung nhìn hoặc tải chúng vào cơ sở dữ liệu hợp nhất.

Theo mô tả ở trên, liên kết dưới đây sẽ giúp bạn và tôi cũng làm việc trên cùng một kịch bản. Nhà xuất bản đa cấp với người đăng ký duy nhất.

1. Thêm một cột nữa như server_id với giá trị mặc định như 1,2,3, v.v. và biến nó thành khóa chính tổng hợp.

2. Khi tạo các ấn phẩm và thêm bài viết, thuộc tính bài viết Hành động nếu tên đang được sử dụng cần được đặt thành Xóa dữ liệu. Nếu bài viết có bộ lọc hàng, chỉ xóa dữ liệu phù hợp với bộ lọc. Điều này có thể được đặt bằng hộp thoại Thuộc tính bài viết hướng dẫn xuất bản mới hoặc bằng cách sử dụng các thủ tục được lưu trữ sao chép sp_addarticle và chỉ định giá trị xóa cho đối số @pre_creation_cmd. Bằng cách này, khi thuê bao trung tâm được khởi tạo hoặc khởi tạo lại từ nhiều ảnh chụp nhanh xuất bản, dữ liệu ảnh chụp nhanh được áp dụng trước đó sẽ được giữ nguyên do chỉ dữ liệu khớp với mệnh đề bộ lọc sẽ bị xóa.

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

Một kiến ​​trúc có thể:

Xem xét báo cáo như một giải pháp dựa trên kho dữ liệu.

Thông thường, kho dữ liệu là một DB với một lược đồ đại diện cho tập hợp con cần thiết của các hệ thống nguồn. AdventureWorks và AdventureworksDW chứng minh rằng mô hình hóa.

Tiếp theo, ETL: Di chuyển dữ liệu từ các nguồn vào kho dữ liệu.

Một triển khai có thể có ở đây là sử dụng theo dõi thay đổi.

Thứ nhất, người ta có thể thực hiện các quan điểm là phiên bản cụ thể trong những gì họ tiêu thụ, nhưng về mặt những gì họ trả lại, là thống nhất. ví dụ: Nếu Person.Gender tồn tại trong phiên bản 2 nhưng không có trong phiên bản 1, chế độ xem người cho phiên bản một có thể trả về, giả sử, null cho phiên bản 1.

Đối với người tiêu dùng kho, chỉ đọc các khung nhìn, dữ liệu có cùng hình dạng (với độ hoàn chỉnh khác nhau).

Theo dõi thay đổi cung cấp một cách (tương đối) trọng lượng nhẹ để xác định dữ liệu nào cần thay đổi mỗi lần làm mới.

Việc thực hiện các điều trên phụ thuộc vào công cụ cầm tay tất cả, vì vậy bạn sẽ cần tự tin vào mã hóa SQL và kiểm tra các kịch bản hiệu suất để xem tốc độ tăng nhanh như thế nào. Trong nhiều trường hợp, chúng có thể là phụ 1 giây, nhưng một số bảng giao dịch cao có thể tạo ra tải cao trong xử lý thay đổi. (Theo dõi thay đổi là "trọng lượng nhẹ" tương đối ... chỉ có thử nghiệm chứng minh điều đó).

Điều tốt ở đây là bạn có mức độ kiểm soát cao đối với cách hiển thị sự khác biệt của lược đồ và với theo dõi thay đổi, sẽ không có vấn đề về tính toàn vẹn khi được triển khai chính xác, vì việc theo dõi được thực hiện ở cấp độ động cơ.

Cho dù điều này chắc chắn là phù hợp với bạn, nó sẽ rất khó để nói.