Nén dữ liệu SQL Server có tốt về mặt phân loại cho cơ sở dữ liệu chỉ đọc không?

Một số tài liệu về nén dữ liệu SQL Server tôi đọc được rằng chi phí ghi tăng lên khoảng bốn lần so với yêu cầu thông thường. Dường như điều này cũng ám chỉ rằng đây là nhược điểm chính của việc nén dữ liệu, ngụ ý mạnh mẽ rằng đối với cơ sở dữ liệu lưu trữ chỉ đọc, hiệu suất (với một vài ngoại lệ) sẽ được cải thiện bằng cách sử dụng nén dữ liệu của các trang được lấp đầy 100%.

1. Những tuyên bố trên có đúng không?

2. Các "biến thể" chính giữa nén dữ liệu và mặt khác (để đọc)

   • "CPU + x%"?
   • "IO -y%"?
   • xảy ra chia trang?
   • sử dụng tempdb?
   • Sử dụng RAM?
3. Và để viết?

Với mục đích của câu hỏi này, bạn có thể giới hạn ngữ cảnh ở mức nén PAGE của cơ sở dữ liệu lớn (> 1TB) , nhưng luôn có những bình luận bổ sung.

Người giới thiệu:

Blog công cụ lưu trữ máy chủ SQL (Kịch bản DW cho thấy việc nén rất thuận lợi)
Nén dữ liệu: Chiến lược, lập kế hoạch năng lực và thực tiễn tốt nhất

Một cách tiếp cận chi tiết hơn để quyết định nén cái gì liên quan đến việc phân tích các đặc tính khối lượng công việc cho mỗi bảng và chỉ mục. Nó dựa trên hai số liệu sau:

U: Tỷ lệ phần trăm của các hoạt động cập nhật trên một bảng, chỉ mục hoặc phân vùng cụ thể, so với tổng số hoạt động trên đối tượng đó. Giá trị của U càng thấp (nghĩa là bảng, chỉ mục hoặc phân vùng được cập nhật không thường xuyên), ứng cử viên tốt hơn cho việc nén trang.
S: Tỷ lệ phần trăm của các hoạt động quét trên một bảng, chỉ mục hoặc phân vùng, so với tổng số các hoạt động trên đối tượng đó. Giá trị của S càng cao (nghĩa là bảng, chỉ mục hoặc phân vùng chủ yếu được quét), ứng cử viên tốt hơn để nén trang.

Cả hai điều trên đều thiên về hướng nén trang khuyến nghị cho cơ sở dữ liệu kiểu DW (hoạt động đọc dữ liệu lớn / độc quyền, dữ liệu lớn).

Chỉ 2 phần trăm từ các thử nghiệm của riêng tôi trên phần cứng 1-2 năm tuổi:

Các thao tác chỉ đọc (quét kiểu DW, sắp xếp, v.v.) trên các bảng được nén trang (~ 80 mũi tên / trang) Tôi đã tìm thấy hòa vốn khi giảm kích thước nén ~ 3x.

Tức là nếu các bảng phù hợp với bộ nhớ nào, việc nén trang chỉ mang lại lợi ích cho hiệu suất nếu kích thước dữ liệu bị thu hẹp hơn 3x. Bạn quét ít trang hơn trong bộ nhớ, nhưng sẽ mất nhiều thời gian hơn để quét từng trang.

Tôi đoán số dặm của bạn có thể thay đổi nếu kế hoạch của bạn được lồng vào nhau và tìm kiếm nặng nề. Trong số những người khác, điều này cũng sẽ phụ thuộc vào phần cứng (hình phạt truy cập nút NUMA nước ngoài, tốc độ bộ nhớ, v.v.).

Trên đây chỉ là một quy tắc thô sơ mà tôi tuân theo, dựa trên thử nghiệm của riêng tôi bằng các truy vấn của riêng tôi trên phần cứng của riêng tôi (Dell Poweredge 910 trở xuống). Nó không phải là phúc âm!

Chỉnh sửa: Hôm qua, bài thuyết trình SQLBits XI tuyệt vời của Thomas Kejser đã được cung cấp dưới dạng video. Khá liên quan đến cuộc thảo luận này, nó cho thấy khuôn mặt 'xấu xí' của chi phí CPU khi nén trang - các bản cập nhật bị chậm lại 4 lần, các khóa được giữ lâu hơn một chút.

Tuy nhiên , Thomas đang sử dụng bộ lưu trữ FusionIO và anh ấy đã chọn một bảng chỉ "đủ điều kiện" để nén trang. Nếu lưu trữ trên SAN điển hình và dữ liệu được sử dụng nén 3x-4x thì hình ảnh có thể đã kém ấn tượng hơn.

Tôi có thể thêm vài từ trong môi trường Kho dữ liệu của mình.

Thực hiện nén (TRANG trong trường hợp của tôi) trên bảng thử nghiệm với 30 triệu hàng (18 GB) giảm kích thước của bảng từ 18 GB xuống còn 3 GB! (chắc chắn hiệu quả lưu trữ) nhưng tăng thời gian tải (ghi) từ 22 lên 36 phút.

Vì vậy, để đọc hoặc đọc và đặt dữ liệu vào bộ nhớ, nó có thể là một giải pháp tốt nhưng đối với tải dữ liệu hàng ngày, nó có thể làm giảm hiệu suất.