Hướng dẫn về cài đặt 'ngưỡng chi phí cho song song' có thay đổi với sự xuất hiện của các chỉ mục của nhà kho không?

Trước hết, những gì tôi không hỏi. Tôi không hỏi thiết lập của tôi nên là gì.

Nhiều người đang đề xuất tăng giá trị vượt quá mặc định và tôi chắc chắn hiểu lý do tại sao đó là trường hợp cho các truy vấn dựa trên B-Tree. Nhưng tôi đã đọc về khả năng mở rộng tuyến tính (gần như) của các chỉ mục cột phân cụm trong bộ nhớ và tôi tự hỏi liệu việc đặt ngưỡng chi phí quá cao có thể khiến SQL Server bỏ đói các truy vấn dựa trên kho lưu trữ cho các lõi CPU.

Vì vậy, câu hỏi là: Máy chủ SQL có xử lý các chỉ mục của cột khác nhau khi 'ngưỡng chi phí cho sự song song' có liên quan không và điều đó có khiến tôi thay đổi quyết định về cài đặt ban đầu của mình không?

Ngoài cài đặt Ngưỡng chi phí, SQL Server dường như xử lý song song khác nhau đối với các chỉ mục của cửa hàng cột tùy thuộc vào phiên bản SQL Server của bạn (2012 so với 2014) và thậm chí cả các kiểu dữ liệu trong bảng của bạn.

Tôi sẽ bắt đầu với số thập phân điểm chuẩn của Joe Chang so với kiểu dữ liệu float và cũng đọc các nhận xét về bài đăng đó. Nếu bạn muốn có chính xác MAXDOP và Ngưỡng chi phí chính xác cho cài đặt Song song cho hệ thống của mình, bạn sẽ cần thực hiện mức độ kiểm tra chi tiết mà Joe thực hiện trong bài đăng của mình và phải mất rất nhiều công sức. Do đó, trước tiên tôi sẽ tập trung vào nút cổ chai hệ thống của bạn - sử dụng số liệu thống kê chờ để đảm bảo tính song song hoặc áp suất CPU là vấn đề đối với bạn, sau đó bắt đầu bằng cách điều chỉnh hầu hết các truy vấn chuyên sâu về CPU thay vì thay đổi cài đặt hệ thống.

TL; DR: Cài đặt ban đầu được đề xuất là 50 bạn đọc vẫn là một nơi tốt để bắt đầu. MAXDOP của 1 lõi vật lý trên mỗi nút NUMA là một cài đặt tốt cho máy chủ như của chúng tôi, phục vụ cả khối lượng công việc OLTP và OLAP.

Corrolary: SQL Server thực sự, thực sự giỏi về những gì nó làm.

Lo lắng chính của tôi với cài đặt này là liệu tôi có ngăn cản việc thực thi song song trên một chỉ mục dựa trên cửa hàng cột cho các truy vấn khá ngắn hay không. Liệu cài đặt 50 có gây ra truy vấn phụ 1 giây nào để mất nhiều thời gian hơn không? Vì các chỉ mục của cửa hàng cột có quy mô rất tốt với CPU, nên có thể bỏ qua 'ngưỡng chi phí cho chế độ song song' không?

• H: SQL Server thậm chí có tôn trọng 'ngưỡng chi phí cho sự song song' cho các chỉ mục của nhà kho không?

• A: Vâng. Khi được định cấu hình với cài đặt vô lý 30.000, tính song song cho các chỉ mục của cột lưu trữ đã bị vô hiệu hóa một cách hiệu quả cho khối lượng công việc của tôi. Thử một số giá trị khác, vẫn còn tục tĩu (1.500) đã ức chế sự song song đối với khối lượng công việc thường mất khoảng một giây để chạy, nhưng các truy vấn thường chạy trong khoảng 10 giây trở lên thể hiện kế hoạch thực hiện song song.

• H: Là cài đặt mặc định là 50, như được chỉ định trong một số danh sách kiểm tra ngoài đó, có phải là giá trị an toàn không gây ức chế song song cho các truy vấn dựa trên cửa hàng cột của tôi không?

• A: Vâng , và bằng một cú sút xa. Ngay cả việc xử lý giá trị lên tới 500 vẫn cho phép xử lý song song cho các truy vấn dựa trên kho lưu trữ đơn giản, ngắn (giây phụ).

Về máy chủ, khối lượng công việc và kết quả của tôi:

• 2x Xeon E2650v2, (2 nút NUMA, 12 lõi vật lý, 24 luồng HT), RAM 384 GB
• MAXDOP được định cấu hình ở mức 6 (6 lõi vật lý trên mỗi nút NUMA)
• Máy chủ SQL 2014 doanh nghiệp CU4
• Kiểm tra chỉ số kho lưu trữ cột 111.000.000 hàng, trong 6 phân vùng (theo năm)

Hai khối lượng công việc được thử nghiệm:

• SELECT COUNT(DISTINCT <low cardinality column>) FROM table;

• SELECT COUNT(DISTINCT <high cardinality column>) FROM table;

Truy vấn của cột cardinality cao mất 84 giây (trôi qua) ở ngưỡng trên 1500 và khoảng 14 giây (trôi qua) ở ngưỡng dưới số đó. Truy vấn của cột cardinality thấp mất khoảng 250ms (trôi qua) ở ngưỡng 500 trở xuống và 18 giây (trôi qua) ở ngưỡng trên 1500. (Tôi đã không cố gắng đánh giá chính xác điểm mà nó đã chuyển kế hoạch.) , khi tính song song bị ức chế, tổng thời gian CPU cho truy vấn cardinality thấp sẽ tăng lên đáng kể; có lẽ máy chủ dừng sử dụng chế độ hàng loạt cho truy vấn này.

Heh, cuối cùng chạy thử nghiệm dẫn đến nhiều câu hỏi hơn, nhưng đó là tất cả các fodder blog, và vượt ra ngoài phạm vi của câu hỏi này.

Tôi sẽ thêm vào bài viết của Joe Chang rằng bạn nên xem bài này của Paul White, nơi anh ấy thảo luận về Cờ Trace về cơ bản đặt CTFP thành 0 cho truy vấn bạn đang chạy. Tôi biết đó không chính xác là những gì bạn đang tìm kiếm, nhưng cùng với thử nghiệm MAXDOP có thể cho bạn ý tưởng hay về việc nếu truy vấn của bạn đi song song thậm chí sẽ có ích trên các chỉ mục lưu trữ cột. Tôi đã thử nó một chút gần đây (trong dev, tôi thề) thay vì làm phức tạp một cách giả tạo kế hoạch để buộc song song.