Phân vùng / lập chỉ mục một bảng cực kỳ lớn


7

Tôi đang làm việc về lập chỉ mục và phân vùng một bảng kho dữ liệu duy nhất nặng khoảng 500 GB. Bảng là một đống, có hơn một trăm TEXTcột và TEXT_IN_ROWtùy chọn được bật. Tôi đã không thiết kế bảng này và tôi không có khả năng thay đổi nó trước mắt.

Tôi đã được giao nhiệm vụ phân vùng nó. Chúng tôi đang giải quyết vấn đề này bằng cách sử dụng một bản sao của cơ sở dữ liệu trên máy chủ thử nghiệm. Nó có thể đẩy khoảng 2 GB mỗi giây vào các mảng RAID SSD, vì vậy I / O không phải là một nút cổ chai đáng kể và nó có 16 lõi (2 nút NUMA) và RAM 64 GB.

Cách tiếp cận của tôi là vô hiệu hóa tất cả các chỉ mục không bao gồm, tạo chức năng phân vùng và sơ đồ phân vùng (khoảng 12 phân vùng, tất cả trên PRIMARYfilegroup - họ đang sử dụng điều này để cho phép bảo trì cuộn và cung cấp thêm các phần chèn cục bộ cho ETL hàng đêm và không phân phối I / O), sau đó xây dựng một chỉ mục được nhóm cho bảng bằng cách sử dụng sơ đồ phân vùng này.

Tôi đang tạo chỉ mục cụm và phân vùng bảng như sau:

CREATE CLUSTERED INDEX CX_DailyTable ON DailyTable (LoadDate, SeqNumber) 
  WITH (SORT_IN_TEMPDB = ON) ON monthly_on_primary (LoadDate)

Rõ ràng, nó đã mất một thời gian dài (3 giờ cho đến khi đăng bài này), và tôi chắc chắn không mong đợi nó sẽ nhanh chóng. Điều làm tôi lo lắng một chút là tempdb hiện đang đẩy gần 1 TB và tăng đều đặn, mặc dù bảng hiện tại có kích thước khoảng một nửa. Các tài liệu MS mà tôi đã đọc đề xuất việc sử dụng không gian tempdb nên có kích thước của bảng / chỉ mục cụm cuối cùng.

http://msdn.microsoft.com/en-us/l Library / ms188281.aspx

Nếu SORT_IN_TEMPDB được đặt thành BẬT, thì phải có đủ không gian trống trong tempdb để lưu trữ các lần chạy sắp xếp và đủ không gian trống trong nhóm tệp đích để lưu trữ cấu trúc chỉ mục cuối cùng. Các loại sắp xếp chứa các hàng lá của chỉ mục.

Là ước tính của họ không chính xác? Là tempdb đang được sử dụng cho nhiều hơn là chỉ chạy sắp xếp? Hoặc là tạo ra chỉ số cụm này bằng cách nào đó tăng gấp đôi kích thước của bảng? (Có vẻ khá khó xảy ra; đó là một bảng khá rộng và tôi ước tính chúng tôi sẽ nhận thêm 4-8 byte mỗi hàng, cộng với các trang không có lá bằng cách thêm một chỉ mục được nhóm.)


Kích thước trung bình của một hàng là gì? Với nhiều đống, các phần chèn sẽ được đưa vào bất kỳ trang nào chúng phù hợp (được thực hiện thông qua quét bản đồ byte PFS) Với các chỉ mục được nhóm có chính xác một vị trí mà hàng có thể kết thúc, do đó tùy thuộc vào phân phối dữ liệu của bạn, nó có thể chiếm một số khác biệt .
StrayCatDBA

1
@StrayCatDBA "Bảng là một đống, có hơn một trăm cột văn bản và tùy chọn TEXT_IN_law được bật. Tôi không thiết kế bảng này và tôi không có khả năng thay đổi bảng này trong tương lai trước mắt." tempdbkhóc, chưa kể đến việc chia trang trên trang chèn tiếp theo
swasheck

Câu trả lời:


16

Cách tiếp cận của tôi là vô hiệu hóa tất cả các chỉ mục không bao gồm [...] sau đó xây dựng một chỉ mục được nhóm cho bảng bằng cách sử dụng sơ đồ phân vùng này.

Tạo một chỉ mục được nhóm trên một đống sẽ tự động xây dựng lại tất cả các chỉ mục không được bao gồm (ngay cả những chỉ mục bị vô hiệu hóa). Các chỉ mục không bao gồm được xây dựng lại nhưng không được phân vùng . Giả sử trạng thái kết thúc mong muốn là một bảng được phân vùng với các chỉ mục được căn chỉnh, việc xây dựng lại các chỉ mục không bao gồm thành không liên kết là hoàn toàn lãng phí công sức.

Điều làm tôi lo lắng một chút là tempdb hiện đang đẩy gần 1 TB và tăng đều đặn, mặc dù bảng hiện tại có kích thước khoảng một nửa. Các tài liệu MS mà tôi đã đọc đề xuất việc sử dụng không gian tempdb nên có kích thước của bảng / chỉ mục cụm cuối cùng.

Câu hỏi về không gian sắp xếp rất phức tạp. Để hiểu tất cả các chi tiết (bao gồm cả hiệu ứng song song), bạn cần đọc kỹ toàn bộ loạt bài đăng của Nhóm Xử lý Truy vấn Máy chủ SQL. Chuyển đổi một đống thành bảng được phân vùng có bật song song có lẽ khá gần với trường hợp xấu nhất.

Ở mức cơ bản nhất (bỏ qua hầu hết các thông tin quan trọng trong các bài đăng của Nhóm QP), bạn đang yêu cầu SQL Server chạy một truy vấn như:

SELECT *
FROM DailyTable
ORDER BY
    $partition.monthly_on_primary(LoadDate),
    LoadDate,
    SeqNumber;

Truy vấn này sẽ không được thực thi nhanh chóng, bất kể bạn chọn viết loại chạy nào không phù hợp với bộ nhớ. Thêm vào đó là công việc thực sự xây dựng một bản sao hoàn chỉnh mới của toàn bộ tập dữ liệu trong các hàng riêng biệt và công việc liên quan đến việc xây dựng lại các chỉ mục không bao gồm một cách vô nghĩa ...

Khuyên bảo

Có nhiều cân nhắc trong việc thay đổi này để hoạt động hiệu quả. Những điều quan trọng là tránh sắp xếp mọi lúc có thể, và sử dụng tải số lượng lớn được ghi nhật ký tối thiểu bất cứ khi nào có thể.

Các chi tiết phụ thuộc vào chi tiết không có trong câu hỏi và một giải pháp đầy đủ nằm ngoài câu trả lời ở đây. Tuy nhiên, phác thảo của một cách tiếp cận có hiệu quả với cá nhân tôi trong quá khứ là:

  • Trích xuất dữ liệu hiện có bằng cách sử dụng bcpmột tệp cho mỗi phân vùng cuối cùng
  • Bỏ bảng hiện có và tạo bảng mới
  • Tải bảng mới bằng cách sử dụng tải số lượng lớn được ghi nhật ký tối thiểu song song

Việc trích xuất dữ liệu trên mỗi phân vùng cần được đặt hàng trên (LoadDate, SeqNumber). Lý tưởng nhất, bạn sẽ tránh được một hoạt động sắp xếp. Nếu bạn có một chỉ mục không bao gồm hiện có trên (LoadDate, SeqNumber), bạn có thể trích xuất dữ liệu theo đúng thứ tự mà không cần sắp xếp nếu bạn xây dựng truy vấn chính xác.

Khi dữ liệu trên mỗi phân vùng đã được trích xuất thành các tệp riêng biệt (điều này có thể được thực hiện song song nếu phần cứng của bạn phụ thuộc vào nó), bảng nguồn có thể được loại bỏ, giải phóng không gian. Sau đó, một bảng phân vùng hoặc bảng phân vùng mới được tạo và được tải số lượng lớn với dữ liệu được sắp xếp trước, cũng có thể song song.

Hoàn thành đúng, toàn bộ quá trình yêu cầu không quá 1x kích thước dữ liệu và đạt được tốc độ truyền dữ liệu nhanh nhất có thể theo cả hai hướng, với lượng sử dụng nhật ký ít nhất.


AH-HA. Có vấn đề của tôi. Tôi đã không nhận ra rằng việc xây dựng lại một chỉ mục được nhóm sẽ tự động kích hoạt lại tất cả các chỉ mục không được phân cụm. Tin vui là nó vẫn hoàn thành sau 14 giờ và bao gồm cả đống 500 GB, cộng thêm 500 GB chỉ mục không phân cụm. Tôi sẽ sửa đổi thủ tục để loại bỏ các chỉ mục không được nhóm hoàn toàn. Dù sao tôi cũng phải viết kịch bản cho chúng để chuyển chúng lên sơ đồ phân vùng, vì vậy điều này sẽ không ảnh hưởng nhiều đến quá trình (ngoài việc tăng tốc đáng kể). Cảm ơn.
db2
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.