Thiết kế bảng lớn SQL

Tôi có một câu hỏi chung về thiết kế bảng SQL Server 2008. Chúng tôi hiện có một bảng có dung lượng hơn 600 GB và tăng lên khoảng 3 GB mỗi ngày. Bảng này có các phân tích thích hợp nhưng đang trở thành một cúp máy lớn khi chạy các truy vấn và chỉ vì kích thước của nó. Câu hỏi đặt ra là tôi có nên chia bảng thành nhiều bảng theo năm và tháng không (điều này sẽ phù hợp với cách các bộ phận khác phân chia bộ dữ liệu lớn của họ) hoặc chúng ta nên tận dụng phân vùng được tích hợp trong SQL Server. Dường như việc sử dụng phân vùng sẽ yêu cầu thay đổi mã ít hơn. Từ những gì tôi đọc được khi phân vùng, bạn vẫn chỉ cần truy vấn một bảng và máy chủ xử lý cách lấy dữ liệu. Nếu chúng tôi đã đi tuyến đường nhiều bảng, chúng tôi sẽ phải xử lý việc kéo dữ liệu từ nhiều bảng.

"Bảng này có các phần không phù hợp nhưng đang trở thành một cúp máy lớn khi chạy truy vấn"

Phân vùng một mình không giúp thực hiện truy vấn trừ khi SQL Server có thể loại bỏ phân vùng khi chạy truy vấn. Mệnh đề WHERE của bạn cần xếp hàng với cách bạn phân vùng. Chúng tôi chỉ nhận được một trường để sử dụng làm trường phân vùng, vì vậy nếu trường đó không được bao gồm trong mệnh đề WHERE của bạn, bạn vẫn có khả năng quét toàn bộ bảng mặc dù có phân vùng.

"và chỉ vì kích thước của nó."

Phân vùng có thể làm cho các hoạt động bảo trì nhất định dễ dàng hơn, nhưng vẫn có những điều chúng ta không thể làm trên cơ sở phân vùng theo phân vùng. Nếu bảo trì chỉ mục và cập nhật thống kê gây ra sự cố cho bạn, tốt hơn hết bạn nên chia thiết kế thành bảng lưu trữ và bảng cập nhật trực tiếp. Khi bạn cần định kỳ di chuyển dữ liệu từ bảng trực tiếp sang bảng lưu trữ, bạn thực hiện việc đó, xây dựng lại các chỉ mục với hệ số lấp đầy 100%, cập nhật số liệu thống kê với quét toàn bộ, sau đó đặt nhóm tệp của nó thành chỉ đọc. Phân vùng có thể giúp tải bảng lưu trữ - nhưng phân vùng bảng trực tiếp có thể không. (Tôi đang đưa ra một số khái niệm nâng cao ở đây như thể nó nhanh chóng và đơn giản, nhưng tôi chỉ phác thảo một số nền tảng ở đây.)

"Có vẻ như việc sử dụng phân vùng sẽ yêu cầu thay đổi mã ít hơn."

Sorta kinda - thoạt nhìn có vẻ như vậy, nhưng bạn càng hiểu sâu về nó, bạn có các tùy chọn như các khung nhìn được phân vùng. Bạn có thể đổi tên bảng hiện có, đặt chế độ xem vào vị trí của bảng và sau đó bạn có thể thực hiện các thay đổi của riêng mình cho các bảng bên dưới (và thêm nhiều bảng) mà không cần thay đổi ứng dụng của bạn.

Tôi đã viết thêm về những cạm bẫy của phân vùng ở đây:

http://www.brentozar.com/archive/2008/06/sql-server-partitioning-not-the-answer-to-everything/

Phân vùng trong sự cô lập có thể là đủ nhưng bạn có thể nhận được kết quả tốt hơn bằng cách kết hợp với các khung nhìn được phân vùng và nhiều bảng. Nó rất nhiều phụ thuộc vào mô hình truy vấn và tăng trưởng.

Hạn chế hiện tại với phân vùng là số liệu thống kê cột chỉ được duy trì ở một bảng, thay vì mức phân vùng. Nếu bạn có một mẫu truy vấn sẽ được hưởng lợi từ số liệu thống kê chính xác hơn, kết hợp phân vùng bảng với các khung nhìn được phân vùng có thể mang lại lợi ích hiệu suất đáng kể.

Trường hợp bản chất của dữ liệu của bạn thay đổi từ tháng này sang tháng khác, năm này sang năm khác, các chế độ xem được phân vùng cũng có thể giúp ích. Hãy tưởng tượng một nhà bán lẻ thay đổi liên tục các dòng sản phẩm của mình, như vậy có rất ít tính nhất quán trong phạm vi Sản phẩm. Sản phẩm được sử dụng từ năm này sang năm khác. Với một bảng đơn hàng / đơn hàng và do đó một biểu đồ thống kê duy nhất, các số liệu thống kê sẽ cung cấp rất ít cho trình tối ưu hóa truy vấn. Một bảng mỗi năm (Order_2010, Order_2011, OrderLine_2010, OrderLine_2011) được phân vùng theo tháng và kết hợp với các chế độ xem được phân vùng (Order, OrderLine) sẽ cung cấp số liệu thống kê chi tiết và có khả năng hữu ích hơn cho trình tối ưu hóa.

Bạn có thể giới thiệu phân vùng bảng với nỗ lực tương đối ít, vì vậy hãy bắt đầu từ đó, đo lường tác động và sau đó đánh giá xem các khung nhìn được phân vùng có xứng đáng với nỗ lực bổ sung hay không.

Kimberly Tripp đã xuất bản rất nhiều hướng dẫn và sách trắng về phân vùng thường được coi là yêu cầu đọc về chủ đề này. Kendra Little cũng có một số tài liệu tốt và hữu ích danh sách tham khảo của các bài viết khác

Hiệu suất thường là lý do số 1 mọi người tìm đến phân vùng. Cá nhân, tôi xem các cải thiện trong thời gian phục hồi là một lợi ích tương đương hoặc lớn hơn với VLDB. Hãy dành chút thời gian để hiểu sự sẵn có một phần và khôi phục từng phần trước khi bạn bắt đầu vì nó có thể ảnh hưởng đến phương pháp bạn thực hiện.

Nếu bạn có quy trình gửi bản sao lưu không lý tưởng nhưng không phổ biến trên mạng, bạn có thể xem xét thời gian khôi phục 3 giờ cho 600GB hiện tại của mình. Trong một năm khi bạn vi phạm 1,5TB, bạn đã gặp sự cố.

Như bạn đã nói, bạn có hai lựa chọn ở đây:

1. Sử dụng nhiều bảng
2. Sử dụng phân vùng

Với 1, bạn có thể tạo XEM để kết hợp tất cả các bảng đó lại với nhau và chỉ cần cập nhật nó để bao gồm các bảng mới được tạo. Tôi coi đây thực sự là một cách để mô phỏng phân vùng. Ưu điểm của phương pháp này bao gồm không yêu cầu Phiên bản doanh nghiệp của SQL Server.

Với 2, bạn có thể căn chỉnh các chỉ mục của mình với các phân vùng và căn chỉnh các phân vùng của bạn với các bộ lưu trữ khác nhau. Sau khi bạn thiết lập chức năng phân vùng và sơ đồ phân vùng, việc này được thực hiện cho bạn khi bạn phân tách hoặc hợp nhất các phân vùng. Ưu điểm của phương pháp này bao gồm không bắt buộc phải di chuyển các bản ghi sang bảng mới. Vì chức năng phân vùng và sơ đồ phân vùng xử lý việc này cho bạn. Hơn nữa, như bạn đã nói, có rất ít hoặc không cần thay đổi mã để truy cập dữ liệu.

Nếu bạn có Enterprise Edition, tôi chắc chắn sẽ phân vùng. Mặc dù trông phức tạp như thế nào, nó thực sự không tệ đến thế. Nếu không, phân vùng thậm chí không phải là một lựa chọn cho bạn.

Tạo các bảng được phân vùng

Sửa đổi bảng phân vùng

Thiết kế phân vùng để quản lý tập hợp dữ liệu

Hi vọng điêu nay co ich,

Matt

Từ câu hỏi của bạn, bạn dường như đang lưu trữ dữ liệu lịch sử (nhật ký) và giới hạn của bạn dường như đến từ tốc độ truy vấn, không phải vấn đề phòng lưu trữ. Đối với tôi phân vùng sẽ không giúp đỡ.

Khi bạn nói rằng bạn có các chỉ mục thích hợp, nó có bao gồm một chỉ mục trên trường ngày không? Tôi đã có kết quả tốt khi sử dụng chỉ mục trên trunc (dấu thời gian, ngày) với Postgres. Sau đó, bạn phải đảm bảo tất cả các truy vấn được chọn vào ngày trước khi có bất kỳ thao tác nào khác. Hãy cẩn thận, dấu thời gian với trường múi giờ không thể lập chỉ mục (vì nó "di chuyển" tùy theo múi giờ) vì vậy bạn cần có dấu thời gian "cố định" để được lập chỉ mục.