SQL Server 2008 - Chỉ mục phân vùng và phân cụm


16

Vì vậy, hãy để tôi mở đầu bằng cách nói rằng tôi không có toàn quyền kiểm soát thiết kế db của mình, vì vậy rất nhiều khía cạnh của hệ thống hiện tại không thể thay đổi cho các mục đích của kịch bản này.

Nhận xét về cách chúng ta nên suy nghĩ lại về các khía cạnh của thiết kế có thể đúng nhưng không có ích :)

Tôi có một bảng rất lớn, rộng khoảng 150 trường và khoảng 600m hàng, điều khiển một số lượng lớn các quy trình. Đây là trong tình huống kho dữ liệu vì vậy chúng tôi không có BẤT K update cập nhật / chèn nào ngoài quy trình tải theo lịch trình, vì vậy nó được lập chỉ mục rất nhiều.

Một quyết định đã được đưa ra để thử phân vùng bảng này và tôi có một số lo ngại về việc lập chỉ mục một bảng được phân đoạn. Tôi không có bất kỳ kinh nghiệm nào về phân vùng, vì vậy mọi đầu vào hoặc liên kết đều được đánh giá cao. Tôi không thể xác định cụ thể những gì tôi đang có sau BOL hoặc msdn.

Hiện tại chúng tôi tập hợp trên một lĩnh vực mà chúng tôi sẽ gọi IncidentKeylà một varchar(50)và không phải là duy nhất - chúng tôi có thể có từ 1-100 bản ghi giống nhau IK(không có nhận xét nào vui lòng). Chúng tôi thường nhận được dữ liệu mới trên các IncidentKeyhồ sơ cũ để nó cũng không tuần tự.

Tôi hiểu rằng tôi cần bao gồm trường phân vùng của mình IncidentDate, trong khóa chỉ mục được nhóm của tôi để phân vùng hoạt động chính xác. Tôi đang nghĩ nó sẽ như vậy IncidentKey, IncidentDate.

Câu hỏi đặt ra là, cơ chế của một chỉ mục được phân cụm sẽ hoạt động như thế nào trên khóa 2 phần trong bảng được phân đoạn, nếu một bản ghi trong phân vùng "mới" phải ở trước một bản ghi trong phân vùng "cũ" trong chỉ mục được phân cụm?

Ví dụ: tôi có 5 hồ sơ:

IncidentKey    Date

ABC123        1/1/2010
ABC123        7/1/2010
ABC123        1/1/2011
XYZ999        1/1/2010
XYZ999        7/1/2010

Nếu tôi nhận được một bản ghi mới cho ABC123, 2/1/2011nó, nó sẽ cần phải nằm trong chỉ mục được nhóm TRƯỚC XYZ999, 1/1/2010 . Cái này hoạt động ra sao?

Tôi giả sử phân mảnh và con trỏ, nhưng tôi không thể tìm thấy bất kỳ thông tin nào về lưu trữ và cấu hình vật lý của các chỉ mục cụm không phân vùng trên các bảng được phân đoạn bằng các khóa hai phần.


Tại sao quyết định phân vùng bảng được thực hiện? Những lợi ích mong đợi từ phân vùng là gì?
Remus Rusanu

@Remus - Tôi thực sự đang làm thử nghiệm, vì vậy chúng tôi sẽ có một phiên bản được phân vùng và một phiên bản không được phân vùng. Lợi ích dự kiến ​​là giảm thời gian tải và thời gian xây dựng chỉ mục. Chúng tôi thực hiện các hoạt động ETL hàng tháng mất khoảng một tuần và hy vọng điều này sẽ giảm đáng kể thời gian đó. Chúng tôi cũng đã triển khai khoảng 3 TB mà chúng tôi hy vọng sẽ giảm với điều này.
JNK

Câu trả lời:


18

Một bảng được phân vùng thực sự giống như một tập hợp các bảng riêng lẻ được khâu lại với nhau. Vì vậy, ví dụ của bạn về phân cụm theo IncidentKeyvà phân vùng theo IncidentDate, giả sử rằng chức năng phân vùng chia các bảng thành hai phân vùng để 1/1/2010 nằm trong phân vùng 1 và 7/1/2010 là phân vùng hai. Dữ liệu sẽ được trình bày trên đĩa dưới dạng:

Partition 1:
IncidentKey    Date
ABC123        1/1/2010
ABC123        1/1/2011
XYZ999        1/1/2010

Partition 2:
IncidentKey    Date
ABC123        7/1/2010
XYZ999        7/1/2010

Ở cấp độ thấp thực sự có hai, hàng riêng biệt. Là bộ xử lý truy vấn tạo ảo giác của một bảng bằng cách tạo các kế hoạch tìm kiếm, quét và cập nhật tất cả các hàng với nhau, như một.

Bất kỳ hàng nào trong bất kỳ chỉ mục không được phân cụm nào cũng sẽ có khóa chỉ mục được phân cụm tương ứng với nó ABC123,7/1/2010. Vì khóa chỉ mục được phân cụm luôn chứa cột khóa phân vùng, nên công cụ sẽ luôn biết trong phân vùng nào (hàng) của chỉ mục được phân cụm để tìm kiếm giá trị này (trong trường hợp này, trong phân vùng 2).

Bây giờ, bất cứ khi nào bạn đang xử lý phân vùng, bạn phải xem xét liệu các chỉ mục NC của bạn có được căn chỉnh không (chỉ mục NC được phân vùng chính xác giống như chỉ mục được phân cụm) hoặc không liên kết (chỉ mục NC không được phân vùng hoặc phân vùng khác với chỉ mục được phân cụm) . Các chỉ mục không liên kết linh hoạt hơn, nhưng chúng có một số nhược điểm:

  • các chỉ mục không liên kết yêu cầu số lượng lớn bộ nhớ cho các gói truy vấn nhất định
  • các chỉ mục không liên kết ngăn chặn các hoạt động chuyển đổi phân vùng hiệu quả

Sử dụng các chỉ mục được căn chỉnh sẽ giải quyết các vấn đề này, nhưng mang lại một loạt vấn đề của riêng nó, bởi vì thiết kế lưu trữ, vật lý này, gợn sóng tùy chọn vào mô hình dữ liệu:

  • các chỉ mục được căn chỉnh có nghĩa là các ràng buộc duy nhất không còn có thể được tạo / thi hành nữa (ngoại trừ cột phân vùng)
  • tất cả các khóa ngoại tham chiếu bảng được phân đoạn phải bao gồm khóa phân vùng trong quan hệ (vì khóa phân vùng là do căn chỉnh, trong mỗi chỉ mục) và do đó tất cả các bảng tham chiếu bảng được phân vùng đều chứa giá trị cột khóa phân vùng. Hãy nghĩ Đơn đặt hàng-> OrderDetails, nếu Đơn hàng có OrderID nhưng được phân vùng bởi OrderDate, thì OrderDetails phải chứa không chỉ OrderID, mà cả OrderDate, để khai báo đúng ràng buộc khóa ngoài.

Những hiệu ứng này tôi thấy hiếm khi được gọi ra khi bắt đầu một dự án triển khai phân vùng, nhưng chúng tồn tại và gây ra hậu quả nghiêm trọng.

Nếu bạn nghĩ các chỉ mục được căn chỉnh là một trường hợp hiếm hoi hoặc cực đoan, thì hãy xem xét điều này: trong nhiều trường hợp, nền tảng của ETL và các giải pháp phân vùng là sự chuyển đổi nhanh chóng trong các bảng phân tầng. Chuyển đổi trong hoạt động yêu cầu chỉ số phù hợp.

Ồ, một điều nữa: tất cả các đối số của tôi về khóa ngoại và hiệu ứng gợn của việc thêm giá trị cột phân vùng vào các bảng khác đều áp dụng như nhau cho các phép nối .


Hoàn hảo, đây chính xác là những gì tôi đang tìm kiếm. Chúng ta sẽ cần sử dụng các chỉ mục được căn chỉnh b / c, việc hoán đổi là một phần của sự rút ra cho những gì chúng ta muốn làm với điều này. Chúng tôi cũng thực hiện một TẤN các hàm tổng hợp nhóm trên IncidentKeylĩnh vực đó, mà tôi nghĩ rằng điều này sẽ cản trở nghiêm trọng. Tôi đánh giá cao tất cả các chi tiết!
JNK

Thông thường những lợi ích của hoạt động chuyển đổi phân vùng lớn hơn tất cả các vấn đề.
Remus Rusanu

Đó là hy vọng của chúng tôi, chúng tôi sẽ sớm thấy!
JNK

9

Khi một chỉ mục cụm có nhiều phân vùng, mỗi phân vùng có cấu trúc cây B chứa dữ liệu cho phân vùng cụ thể đó. Ví dụ: nếu một chỉ mục được nhóm có bốn phân vùng, có bốn cấu trúc cây B; một trong mỗi phân vùng. Tham chiếu Cấu trúc chỉ mục cụm

Nguyên tắc đặc biệt cho các chỉ mục được phân vùng

Bạn có thể xây dựng lại các phân vùng cụ thể của một chỉ mục được phân vùng.

ví dụ

ALTER INDEX IX_TransactionHistory_TransactionDate
ON Production.TransactionHistory
REBUILD Partition = 5;
GO

+1 Đối với liên kết, tôi đã đọc các hướng dẫn đặc biệt nhưng đã bỏ lỡ đoạn đó. Câu hỏi tiếp theo - chúng tôi thực hiện rất nhiều tổng hợp trên IncidentKeylĩnh vực này, bạn có nghĩ rằng điều này sẽ ảnh hưởng xấu đến hiệu suất (tôi nhận ra rằng tôi vẫn sẽ cần phải thử nghiệm)?
JNK

Tôi không biết tất cả các trường hợp cụ thể của bạn nhưng điều đó gây ấn tượng với tôi rằng bạn có thể phân vùng tốt hơn bởi IncidentDate?
Mitch Wheat

Chúng tôi đang phân vùng vào ngày, nhưng khóa cụm được bật IncidentKey- chúng tôi thực hiện rất nhiều lần tham gia vào điều này và đó là một điều thể chế mà chúng tôi sử dụng để phân cụm. Tôi đang thử nghiệm một khóa thay thế nhưng hiện tại đây là thứ tôi phải sử dụng.
JNK
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.