Thiết kế cơ sở dữ liệu SQL Server cho lưu trữ dữ liệu lưu trữ nhưng có sẵn dữ liệu


12

Chúng tôi có cơ sở dữ liệu lớn này (> 1TB) mà chúng tôi dự định "thu nhỏ". Cơ sở dữ liệu xoay quanh một thực thể chính, hãy gọi nó là "Truy cập". Để thảo luận, hãy nói rằng nó là một cơ sở dữ liệu cho một thực hành y tế.

Có tổng cộng 30 "loại" truy cập, chẳng hạn như thủ tục, hàng năm, theo dõi, tiêm chủng, v.v., mỗi loại là một bảng trợ cấp để "Truy cập", ví dụ: "visit_immuno".

Cơ sở dữ liệu đã tích lũy được khoảng 12 năm dữ liệu kể từ năm 2000. Ai đó đã đề xuất rằng chúng tôi giữ khoảng 3 năm dữ liệu trong phiên bản "trực tiếp" và phần còn lại sống trong cơ sở dữ liệu "old_data". Ngày CHỈ được lưu trong bảng "Truy cập" vì nó được chuẩn hóa. Bảng Visit cũng chứa một ROWVERSIONcột và cột BIGINTgiả danh tính (cụm). Đối với tất cả ý định và mục đích, giả sử khóa phân cụm được điền bởi SEQUENCE (SQL Server 2012 Enterprise) - chúng ta sẽ đặt tên cho nó cid.

Các visit.datekhông phải lúc nào cũng theo thứ tự như phím clustering, ví dụ như khi một bác sĩ tiếp tục thăm viếng kéo dài và trở lại với "cặp" của mình dữ liệu, nó được sáp nhập vào bảng chính. Ngoài ra còn có một số cập nhật cho bảng "truy cập" sẽ khiến ROWVERSIONcột không đồng bộ với cả cột ciddatecột - nói một cách đơn giản, không phải ROWVERSIONcũng không cidtạo ra các khóa phân vùng phù hợp vì lý do này.

Quy tắc kinh doanh để xóa dữ liệu khỏi "trực tiếp" là visit.datephải lớn hơn 36 tháng visit_payment phải có hồ sơ con . Ngoài ra, cơ sở dữ liệu "old_data" không chứa bất kỳ bảng cơ sở nào ngoại trừ visit%.

Vì vậy, chúng tôi kết thúc với:

Live DB (sử dụng hàng ngày) - Tất cả các bảng DB dữ liệu cũ - dữ liệu cũ hơn cho các visit%bảng

Đề xuất yêu cầu DB kết hợp là một vỏ chứa Từ đồng nghĩa với TẤT CẢ các bảng cơ sở trong Live DB(ngoại trừ visit%) cộng với Chế độ xem UNION ALL trên các visit%bảng trong hai cơ sở dữ liệu.

Giả sử các chỉ mục tương tự được tạo trong Old-DataDB, các truy vấn sẽ hoạt động tốt trên Chế độ xem UNION-ALL ? Kiểu mẫu truy vấn nào có thể vượt qua kế hoạch thực hiện cho Chế độ xem UNION-ALL ?


3
Động lực nào để a) lưu trữ dữ liệu cũ và b) giữ cho nó có thể truy cập được? Bảo trì trên cao? Vấn đề về hiệu suất? Dữ liệu lưu trữ có cần phải được truy cập liền mạch vào ứng dụng không? Có hay không sửa đổi ứng dụng?
Mark Storey-Smith

(a) Giữ db chính nhỏ. Nó được nhân rộng thành 3 envs khác - dev, pre-test, test. Ngoài ra còn có các bản sao và bản sao lưu, tất cả đều được hỗ trợ bởi bộ lưu trữ đắt tiền. (b) Vì các hệ thống hạ nguồn hiện có quyền truy cập vào tất cả dữ liệu, do đó, điều này duy trì hiện trạng. (c) Một phiên bản của ứng dụng có thể chạy với DB "kết hợp" với tất cả các chế độ xem, nhưng tôi nghi ngờ nó có thể không hoạt động.
孔夫子

Chỉ cần làm rõ, dữ liệu lưu trữ vẫn là đọc-ghi, đúng không? Hay là nó chỉ đọc?
Jon Seigel

Dữ liệu cũ sẽ thay đổi thành các trang chỉ đọc và được điền 100%. Ví dụ của ứng dụng kết nối với các chế độ xem được kết hợp có thể gây ra lỗi nếu ai đó thử điều gì đó ngớ ngẩn trên dữ liệu cũ - chúng tôi không quan tâm.
孔夫子

Tôi nghĩ rằng một filegroup chỉ đọc cho dữ liệu lịch sử và sao lưu / khôi phục một phần sẽ bao gồm điều này, mà không cần thêm vào cơ sở dữ liệu shell và từ đồng nghĩa. Tôi nói nghĩ rằng tôi đã không hòa nhập với cơ chế của nó trong một thời gian và cần phải làm mới bộ nhớ của tôi. Không biết làm thế nào nó sẽ phù hợp với sao chép nhưng tôi đặt câu hỏi tại sao bạn lại sao chép cơ sở dữ liệu trực tiếp vào môi trường hạ lưu.
Mark Storey-Smith

Câu trả lời:


4

Để thuận tiện, giả sử rằng cơ sở dữ liệu trực tiếp được gọi LiveDbvà cơ sở dữ liệu achive được gọiArchiveDb

  • Thêm chế độ xem UNION ALL khi LiveDbtrỏ đến các bảng trong ArchiveDbcơ sở dữ liệu thông qua từ đồng nghĩa (Không cần thực hiện db kết hợp với từ đồng nghĩa)
  • "Phân vùng" bật visit.datevà không chuẩn hóa cột này thành visit_paymentsquá nếu nó chưa có (điều này cải thiện hiệu suất tham gia cùng vị trí)
  • Chỉ lưu trữ hai bảng lớn nếu có thể (giảm cơ hội vấp tối ưu hóa). Giữ chế độ xem UNION ALL và các bảng khác LiveDbđể tất cả các tham gia vào các bảng nhỏ hơn được giữ cục bộ
  • Thêm một ràng buộc CHECK trên các bảng trong cả hai LiveDbArchiveDb điều đó mô tả phạm vi visit.datechứa trong bảng. Điều này giúp trình tối ưu hóa loại bỏ bảng lưu trữ khỏi cả tìm kiếm và quét có chứa cột visit.data. Bạn sẽ phải định kỳ cập nhật ràng buộc này.
  • Trong chế độ xem UNION ALL, hãy thêm tiêu chí WHERE để lọc visit.data. Đây là ngoài gợi ý bạn đã cung cấp trong ràng buộc kiểm tra. Điều này tối đa hóa cơ hội các bộ lọc bị đẩy xuống
  • Nếu bạn có EE, phân vùng bảng trong cơ sở dữ liệu lưu trữ (Nhưng KHÔNG trong cơ sở dữ liệu trực tiếp). Nếu bạn muốn thực sự ưa thích, hãy sử dụng sao lưu / khôi phục cấp độ cơ sở dữ liệu lưu trữ để tiết kiệm thời gian sao lưu.
  • Cân nhắc đưa AchiveDbvào chế độ khôi phục SIMPLE nếu chưa có. Bạn không có khả năng cần sao lưu nhật ký giao dịch củaArchiveDb
  • Sử dụng CHỌN ... VỚI (TABLOCK) CHỌN ... VỚI (ROWLOCK) để buộc đăng nhập tối thiểu vào đích khi di chuyển dữ liệu giữa LiveDbArchiveDb

Tất cả những điều trên không đảm bảo rằng trình tối ưu hóa sẽ loại bỏ các bảng lưu trữ khỏi tìm kiếm và quét, nhưng nó làm cho nó có nhiều khả năng hơn.

Khi việc loại bỏ không xảy ra. Đây là những hiệu ứng bạn có thể thấy (danh sách này có thể không đầy đủ). Đối với tìm kiếm, bạn sẽ nhận được một tìm kiếm bổ sung trên mỗi truy vấn (điều này thúc đẩy IOPS). Đối với quét, kết quả có thể là thảm họa đối với hiệu suất vì cuối cùng bạn có thể quét cả lưu trữ và bảng trực tiếp. Dưới đây là những cách điển hình để bạn có thể tăng tốc tối ưu hóa:

  • Nếu bạn tham gia các visit%bảng với nhau và không bao gồm các visit.datatiêu chí tham gia (đây là lý do tại sao bạn muốn không chuẩn hóa). Vì điều này, bạn có thể muốn sửa đổi một số truy vấn của mình
  • Nếu bạn nhận được một phép nối băm giữa visit.datavà một bảng khác (ví dụ: thứ nguyên ngày), bạn có thể không loại bỏ đúng các bảng
  • Nếu bạn cố gắng tổng hợp dữ liệu qua các bảng lưu trữ
  • Nếu bạn lọc bất cứ thứ gì NHƯNG visit.data, ví dụ như tìm kiếm trực tiếp trên khóa của chế độ xem.

Đối với kịch bản cuối cùng, bạn có thể tự bảo vệ mình trước các tác động xấu nhất bằng cách thêm một ràng buộc kiểm tra khác vào cid- nếu điều này là có thể. Bạn đã đề cập rằng chuỗi cidkhông "sạch" liên quan đến ngày và tiến trình của các hàng trong bảng. Tuy nhiên, bạn có thể duy trì một bảng chứa thông tin: "Không có cidcon số nào ở trên con số này vì điều này visit.data" hay tương tự không? Điều này sau đó có thể lái một ràng buộc bổ sung.

Một điều cần cẩn thận nữa là các truy vấn song song có thể sinh ra RẤT NHIỀU luồng sau khi bạn truy vấn chế độ xem được phân vùng (vì cả hai "bảng phụ" sẽ được hiển thị cùng một tối ưu hóa song song). Vì lý do đó, bạn có thể muốn giới hạn MAXDOP trên máy chủ hoặc các truy vấn song song.

Nhân tiện, nếu bạn biết rõ các truy vấn - bạn thậm chí có thể không cần các chỉ mục giống nhau trong hai cơ sở dữ liệu (điều này giả định rằng bạn chắc chắn 100% rằng bạn sẽ loại bỏ đúng các bảng). Bạn thậm chí có thể xem xét sử dụng các cửa hàng cột cho ArchiveDb.


-1

Cách chúng tôi đã làm là ghi dữ liệu cũ theo lô vào cơ sở dữ liệu mới được tạo và xóa dữ liệu cũ khỏi db trực tiếp. Bằng cách đó, cả hai db đều có thể truy cập được. Bạn cũng có thể sao lưu cơ sở dữ liệu mới được tạo và khôi phục nó ở nơi khác để xóa dấu chân lớn khỏi các máy chủ sản xuất. Hy vọng đó là một giải pháp chấp nhận được cho nhu cầu của bạn.


OP cần phải đi xa hơn thế này để duy trì khả năng tương thích ứng dụng. Bạn đã đọc câu hỏi?
Jon Seigel
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.