Chiến lược xử lý SQL Server DB có quá nhiều tệp (BLOB) trong đó?

Kịch bản:
Cơ sở dữ liệu SQL Server 2005 phục vụ một ứng dụng ASP.NET (trên một máy chủ web riêng).

Cơ sở dữ liệu:
DB có khoảng 5 GB dữ liệu "bình thường" và khoảng 15 GB "tệp" (ví dụ: tệp PDF 200 nghìn được lưu dưới dạng hình ảnh (BLOB), loại đó). Nhiều tệp đang được người dùng tải lên và nhanh chóng tiêu tốn nhiều dung lượng đĩa hơn (DB có thể tăng lên 50GB trong vài tháng tới, chủ yếu là các tệp).

Mối quan tâm:
Việc lưu trữ quá nhiều tệp trong DB đã gây ra sự cố (ví dụ: Tổng kích thước lớn của cơ sở dữ liệu khiến việc sao lưu và triển khai toàn bộ DB đôi khi gặp khó khăn.).

Và chúng tôi lo lắng sẽ có nhiều vấn đề hơn . (ví dụ: các vấn đề về hiệu năng - có thể do không thể giữ toàn bộ DB trong RAM, có lẽ?)

Câu hỏi:
Giải pháp kỹ thuật nào bạn muốn đề xuất cho vấn đề này? Lưu trữ các tập tin trong hệ thống tập tin? Chia cơ sở dữ liệu thành hai và có một cơ sở dữ liệu lớn hơn, chậm hơn cho các tệp?

Thông tin chi tiết nếu cần:
Các tệp này không quá quan trọng và không cần thời gian truy cập rất nhanh - hiện tại một vài giây sẽ ổn và có thể có hàng tá lựa chọn mỗi giờ. Dữ liệu "bình thường" khác trong DB bao gồm thông tin cần thiết nhiều lần trong một giây.

Tôi chăm sóc một cơ sở dữ liệu rất giống nhau, hiện là 3TB và tăng 5GB mỗi ngày.

• Filestream (2008+) không giải quyết được thách thức sao lưu / khôi phục.
• Filestream hoạt động tốt hơn lưu trữ LOB cho các tệp> 1MB, do đó, thử nghiệm của Paul Randal cho biết . Đó là khối lượng công việc phụ thuộc vào 256KB-1MB và thường tệ hơn ở mức <256KB.
• Một điểm cộng lớn cho Filestream trong một số môi trường là nó bỏ qua vùng đệm và sử dụng bộ đệm hệ thống Windows thay thế.
• Nếu bạn đặt các tệp trên một hệ thống tệp, bạn sẽ mất tính nhất quán giao dịch với bản ghi cơ sở dữ liệu. Bạn cũng đã thêm chi phí sao lưu hàng triệu tệp riêng lẻ, điều này có thể gây rắc rối.

Cân nhắc sự ủng hộ và ủng hộ cho Filestream và xem nó có phù hợp với trường hợp của bạn không. Trong trường hợp của chúng tôi, chúng tôi đã thực hiện một tuyến đường khác và đã chọn phân vùng cơ sở dữ liệu để chúng tôi có thể sử dụng khôi phục sẵn có một phần / từng phần .

Một tùy chọn không có sẵn cho chúng tôi, mà bạn có thể có, là đánh dấu các nhóm tệp cũ / lưu trữ là chỉ đọc. Các filegroup chỉ đọc sau đó có thể được sao lưu không thường xuyên.

Nếu bạn bị mắc kẹt trên Tiêu chuẩn 2005 (phân vùng là một tính năng phiên bản Doanh nghiệp) và bạn có tùy chọn chỉ đọc cho lịch sử, bạn có thể giải quyết theo cách cũ.

• Chia bàn của bạn. Bạn có thể xem xét tuyến đường hoạt động / lịch sử hoặc ngày dựa trên ví dụ: bảng mỗi tháng.
• Đặt dữ liệu lịch sử trên một nhóm chỉ đọc và chỉ sao lưu khi bạn lưu trữ thêm dữ liệu. Đảm bảo người dùng của bạn hiểu rằng điều này chỉ cắt giảm thời gian sao lưu. Khôi phục có thể mất một lúc khi bạn không có tính năng khả dụng một phần.
• Tạo một khung nhìn phân vùng trên các bảng.

Một tùy chọn cuối cùng (mà chúng tôi đang xem xét cho blobber 3TB của chúng tôi) là di chuyển dữ liệu tệp sang cơ sở dữ liệu tài liệu hoặc lưu trữ đám mây (ví dụ: AmazonS3 , Azure BLOB Storage ). Điều này không giới thiệu vấn đề về tính nhất quán trong giao dịch mà tôi đã đề cập trước đó nhưng nó giúp giảm tải khỏi các Máy chủ SQL rất tốn kém đó.

hãy thử tính năng FILESTREAM trong máy chủ SQL,

FILESTREAM tích hợp Công cụ cơ sở dữ liệu SQL Server với hệ thống tệp NTFS bằng cách lưu trữ dữ liệu đối tượng lớn nhị phân (tối đa) nhị phân (tối đa) dưới dạng tệp trên hệ thống tệp

những bài viết hay về nó

1. Giới thiệu về SQL Server FileStream
2. Để BLOB hoặc không tới BLOB: Lưu trữ đối tượng lớn trong cơ sở dữ liệu hoặc hệ thống tệp
3. Lưu trữ FILESTREAM trong SQL Server 2008