Tại điểm nào tôi nên chia hoặc phân vùng một bảng rất lớn nhưng đơn giản

Trang web của chúng tôi có một số bảng lớn nhưng đơn giản (INT, INT, DATE) cho các số liệu thống kê. Mỗi bảng có tới 300.000.000 hàng và lớn hơn mỗi ngày.

Nhà cung cấp dịch vụ lưu trữ đã đề nghị chúng tôi chia hoặc phân vùng các bảng và tôi đã thấy đề xuất này ở nơi khác trong nhiều trường hợp.

Tuy nhiên...

Tôi đang đấu tranh để dung hòa lời khuyên này với dung lượng tối đa đã nêu cho SQL Server - kích thước cơ sở dữ liệu là 524.272 terabyte, với các hàng trong bảng chỉ giới hạn bởi "bộ nhớ khả dụng".

Dựa trên những con số, bảng mô tả ở trên có thể dễ dàng có centillions hàng (10 với sức mạnh của 303).

Ah ha bạn có thể nói, có một sự khác biệt giữa NĂNG LỰC và HIỆU SUẤT.

Nhưng trong hầu hết mọi câu hỏi về hiệu năng của SQL Server , câu trả lời là "Nó phụ thuộc .... vào thiết kế bảng và thiết kế truy vấn".

Đó là lý do tại sao tôi hỏi câu hỏi này. Thiết kế bảng không thể đơn giản hơn nhiều. Các truy vấn đơn giản là các hoạt động đếm (*) đơn giản dựa trên trường ID được lập chỉ mục.

Có một lý do mà lời khuyên chung là nó phụ thuộc vào thiết kế bảng và các truy vấn trên đó. Câu trả lời của tôi cho bài viết khác của bạn trên Stack Exchange nói rất nhiều. Nói "các truy vấn là các thao tác đếm đơn giản (*) dựa trên trường ID được lập chỉ mục" sẽ không cung cấp nhiều thông tin vì nó không nói gì về tính chính yếu của tập hợp các hàng đang được xem xét. Những điều bạn có thể làm để giảm thiểu các vấn đề (như hiện tại đã nhận thấy) là:

1. Phân vùng. Cụ thể, dữ liệu của bạn dường như là dữ liệu loại nhật ký. Tôi đoán là bạn muốn có được số liệu thống kê theo một số đơn vị thời gian (ví dụ: "widget mỗi ngày" hoặc "whozits theo giờ"). Phân vùng theo lượng tử của bạn (tức là ngày hoặc giờ trong các ví dụ trước) và thỉnh thoảng di chuyển phân vùng sang các nhóm tệp chỉ đọc

2. Trên một lưu ý liên quan, nếu dữ liệu được ghi một lần, hãy xem xét tổng hợp trước dữ liệu một khi khoảng thời gian không còn hoạt động. Đó là, tại sao tôi cần phải tiếp tục đếm xem có bao nhiêu sự kiện đã xảy ra trong một ngày từ ba năm trước nếu dữ liệu đó sẽ không bao giờ thay đổi? Khi ngày kết thúc, hãy đếm mọi thứ trong ngày đó, lưu trữ ở nơi khác và không bao giờ đếm lại. Trong thực tế, nếu bạn không bao giờ có nhu cầu về dữ liệu chi tiết (tức là bạn chỉ bao giờ thực hiện tổng hợp chống lại nó), hãy xem xét xóa nó sau khi bạn đếm nó. Nếu bạn thực hiện ý tưởng này, bạn thậm chí có thể thông minh hơn với các chỉ mục được lọc chỉ bao gồm khoảng thời gian "hoạt động" sẽ giúp truy vấn của bạn nhanh hơn vì chúng sẽ không bao gồm phần lớn dữ liệu của bạn

Nhưng, như lời khuyên của tôi trong bài đăng khác cho thấy, cách duy nhất bạn sẽ biết chắc chắn là tải nó lên với một lượng dữ liệu hợp lý và dùng thử. Tất cả những gì chúng ta có thể làm ở đây là nói những gì có thể sẽ hoạt động trong trường hợp chung. Không có chi tiết cụ thể về phần cứng, dữ liệu và truy vấn của bạn, tất cả những gì chúng ta có thể làm là đoán. Và, bạn có thể thấy rằng một khi bạn chạy thử nghiệm mà tôi đề xuất rằng câu trả lời là "không có gì để làm" bởi vì nó hoạt động tốt như vậy.

Tôi sẽ thực hiện một cách tiếp cận khác và lưu ý rằng phân vùng ( trong SQL Server ) chủ yếu là một tính năng quản lý dữ liệu với hiệu suất truy vấn là kết quả phụ có thể xảy ra, tùy thuộc vào cách bạn quản lý nó . ¹

Như đã lưu ý trong bài viết được liên kết, lợi ích chính của phân vùng là bạn có thể nhanh chóng di chuyển dữ liệu bằng cách sử dụng chuyển đổi phân vùng . Ví dụ: bạn có thể lưu trữ dữ liệu "mát" hơn để lưu trữ chậm hơn và giữ dữ liệu "nóng" của bạn trên bộ nhớ nhanh. Tại các khoảng thời gian được lên lịch thường xuyên, bạn có thể nhanh chóng lưu trữ dữ liệu bằng cách cuộn dữ liệu đó để lưu trữ (các) phân vùng mà không phải trải qua quá trình chờ đợi một ETL thực hiện chuyển tiền. Như đã lưu ý trong một trong những ý kiến ​​sớm cho câu hỏi của bạn, tuy nhiên, điều này sẽ cần một số suy nghĩ và lập kế hoạch cẩn thận trước khi thực hiện nó. Ngoài ra, tùy thuộc vào phiên bản SQL Server mà bạn sử dụng (Enterprise), bạn có thể tận dụng nén dữ liệu để nén các phân vùng riêng lẻ.

Liên quan đến hiệu suất, bạn có thể thay đổi leo thang khóa thành AUTO(mặc định là TABLE) như vậy :

ALTER TABLE dbo.T1 SET (LOCK_ESCALATION = AUTO);
GO

Ngoài ra, bạn có thể loại bỏ phân vùng nhưng các mẫu truy vấn của bạn sẽ cần phải phù hợp với một mẫu rất cụ thể và có thể lặp lại trong hệ thống của bạn - khóa phân vùng và khóa phân cụm và bất kỳ khóa duy nhất nào đều được kết nối với nhau và rất quan trọng . Nếu số dư này không được xử lý thừa nhận và thiết kế xung quanh, bạn sẽ gặp ác mộng về hiệu suất.

Với sự ra đời của SQL Server 2014, bạn cũng có thể tận dụng các số liệu thống kê gia tăng rất tiện dụng nếu bạn chủ động theo dõi và cập nhật / tạo số liệu thống kê trên các bảng lớn.

Vì vậy, tại điểm nào một bảng nên được phân vùng? Điều đó phụ thuộc vào khối lượng công việc truy vấn của bạn, hồ sơ dữ liệu của bạn, nhưng quan trọng nhất, nó phụ thuộc vào tính năng quản lý phân vùng nào mà bạn nhất định phải tận dụng. Phân vùng không dành cho hiệu năng truy vấn, chủ yếu để quản lý và quản lý dữ liệu.

Trước khi quyết định bạn muốn phân vùng lớn đến mức nào, vui lòng xem xét ý nghĩa của kế hoạch truy vấn của phân vùng. Từ quan điểm hiệu suất hoàn toàn, các phân vùng phục vụ như một dạng chỉ mục hạt thô. Điều này có thể cung cấp hiệu suất bổ sung, nhưng nó cũng là một nguồn hồi quy hiệu suất, đặc biệt nếu khóa phân vùng không xuất hiện trong tất cả các truy vấn. Từ đây, tôi giả sử bạn đã làm bài tập về nhà này rồi (như có vẻ như bạn có).

Một nguyên tắc nhỏ cho kích thước phân vùng bạn muốn là bao nhiêu: Khoảng một nửa kích thước DRAM bạn có trên hộp. Lý do cho khuyến nghị này là:

1. Bạn có thể xây dựng lại các chỉ mục trên phân vùng mà không bị đổ tempdb. điều này nhanh hơn nhiều so với khi bạn sử dụng truy cập đĩa (ngay cả với SSD).
2. Trong khi bạn thực hiện việc xây dựng lại này, bạn vẫn có thể giữ toàn bộ phân vùng (thường là mới nhất) trong DRAM để duy trì hiệu suất truy vấn của bạn.

Nói cách khác, bạn muốn có đủ DRAM để chứa hai phân vùng và kích thước phân vùng bạn muốn tùy thuộc vào máy bạn chạy. Máy lớn hơn có thể thoải mái xử lý các phân vùng lớn hơn.

Lưu ý rằng hướng dẫn này cũng cung cấp kích thước tối thiểu cho tempdb: Ít nhất là kích thước của phân vùng lớn nhất của bạn (vì vậy bạn CÓ THỂ làm đổ chỉ mục xây dựng ở đó nếu không có đủ DRAM khi bạn xây dựng lại chỉ mục).

Bạn có thể xem xét kích thước phân vùng nhỏ hơn mức này, nhưng nếu bạn làm vậy, điều này thường nhằm mục đích tối ưu hóa hiệu suất và không hỗ trợ khả năng quản lý dữ liệu.

Có rất nhiều thủ thuật khác mà bạn có thể chơi với các phân vùng. Ví dụ: nén, tổng hợp hoặc sử dụng Fill Factor 100 trên các phân vùng chỉ đọc. Nhưng nguyên tắc cơ bản vẫn là: Cố gắng giữ cho mỗi khối dữ liệu bạn quản lý nhỏ hơn DRAM.

Tái bút: Rất vui khi thấy bạn không lấy "nó phụ thuộc" làm câu trả lời, luôn luôn yêu cầu một phương pháp để có được câu trả lời.

Phân vùng bảng, giống như một số tính năng khác, khá thường xuyên (hoặc thậm chí là thường xuyên nhất?) Được sử dụng không phù hợp. Bất kỳ cảnh báo nào tôi sẽ đưa ra đều được nêu rõ trong câu trả lời của @ swasheck .

Ngoài ra, một lựa chọn khác để xem xét là Chế độ xem được phân vùng. Đây là cách giữ các bảng hoàn toàn riêng biệt nhưng liên kết chúng lại với nhau thông qua UNION ALL trong Chế độ xem. Mỗi bảng yêu cầu KIỂM TRA CONSTRAINT thi hành phạm vi dữ liệu mà mỗi bảng giữ. Trình tối ưu hóa biết về cấu trúc này và chỉ nên truy cập vào các bảng bên dưới được yêu cầu bởi truy vấn bằng cách sử dụng Chế độ xem (Tôi không nhớ tất cả các yêu cầu để có công việc này như dự định, vì vậy vui lòng xem liên kết CREATE VIEW ở phía dưới, nhưng Tôi đã thiết lập nó trước đây và không khó để làm cho nó hoạt động như mong đợi).

Chắc chắn có một số hạn chế và một nhược điểm chính là nó kém minh bạch hơn so với Phân vùng bảng. Tuy nhiên, một lợi ích chính là đây là các bảng riêng biệt và do đó các số liệu thống kê hoàn toàn riêng biệt, trong khi với Bảng được phân chia, chúng dành cho toàn bộ bảng (ngay cả khi, bắt đầu từ SQL Server 2014, bạn có thể cập nhật số liệu thống kê trên mỗi phân vùng).

Nếu bạn sẽ không sử dụng chuyển đổi phân vùng vào và ra, bạn nên xem xét tùy chọn này. Đặc biệt là nếu dữ liệu cũ không thay đổi nhiều do các bảng chứa dữ liệu cũ không cần chỉ mục / thống kê của chúng được cập nhật gần như thường xuyên (hoặc có thể là bao giờ nếu dữ liệu đó không bao giờ thay đổi).

Một nhược điểm khác của Phân vùng bảng thường không được đề cập / không được chú ý là bắt đầu trong SQL Server 2012, bạn không còn nhận được THỐNG KÊ CẬP NHẬT "miễn phí" với FULLSCAN khi xây dựng lại các chỉ mục được phân vùng. Bạn vẫn nhận được số liệu thống kê cập nhật này với việc xây dựng lại các chỉ mục không được phân vùng, mà các chỉ mục trên các bảng trong Chế độ xem được phân vùng sẽ là :).

Để biết thêm thông tin về Chế độ xem được phân vùng, vui lòng kiểm tra trang MSDN để TẠO XEM và xem phần "Chế độ xem được phân vùng" trong "Nhận xét".