Là hỗ trợ cho Parallel Scalar UDF là một yêu cầu tính năng hợp lý?

Một tài liệu khá rõ ràng rằng UDF vô hướng buộc một kế hoạch nối tiếp tổng thể.

Chạy các chức năng song song

Đưa ra một số lượng lớn các hàng đi vào một điểm trong đường ống nơi phải tính UDF, tại sao động cơ không thể phân phối chúng giữa các bộ xử lý? Nếu không có trạng thái trong UDF thì thứ tự không thành vấn đề.

Có những tuyên bố về UDF là một hộp đen phải sử dụng con trỏ. Tôi có thể thấy rằng một con trỏ người dùng không thể được song song trong một SP cho các trường hợp trong đó một số trạng thái được duy trì giữa các lần lặp nhưng có vẻ như nó phải song song với nhau.

Thêm điểm để giải thích lý do tại sao động cơ buộc toàn bộ kế hoạch phải nối tiếp thay vì chỉ là giai đoạn tính toán UDF.

Là hỗ trợ cho UDF song song là một tính năng hợp lý để yêu cầu?

Một tài liệu khá rõ ràng rằng UDFs buộc một kế hoạch nối tiếp tổng thể.

Tôi không chắc chắn đó là tất cả những gì được ghi chép lại.

• Hàm T-SQL vô hướng ngăn chặn sự song song ở bất cứ đâu trong kế hoạch.
• Một hàm CLR vô hướng có thể được thực thi song song, miễn là nó không truy cập vào cơ sở dữ liệu.
• Hàm T-SQL có giá trị bảng nhiều câu lệnh buộc một vùng nối tiếp trong một kế hoạch có thể sử dụng song song ở nơi khác.
• Hàm T-SQL có giá trị bảng nội tuyến được mở rộng như dạng xem, do đó không có tác dụng trực tiếp.

Xem Buộc Buộc Kế hoạch thực hiện song song và / hoặc bản trình bày Thi hành song song của Craig Freedman .

Có những tuyên bố về UDF là một hộp đen phải sử dụng con trỏ.

Những tuyên bố này là không chính xác.

Thêm điểm để giải thích lý do tại sao động cơ buộc toàn bộ kế hoạch phải nối tiếp thay vì chỉ là giai đoạn tính toán UDF.

Hiểu biết của tôi là các hạn chế hiện tại hoàn toàn là kết quả của một số chi tiết thực hiện nhất định. Không có lý do cơ bản tại sao các chức năng không thể được thực thi bằng cách sử dụng song song.

Cụ thể, các hàm vô hướng T-SQL thực thi bên trong một bối cảnh T-SQL riêng biệt, làm phức tạp đáng kể hoạt động, phối hợp và tắt máy (đặc biệt là trong trường hợp có lỗi) đáng kể.

Tương tự, các biến bảng không hỗ trợ đọc song song (nhưng không ghi) nói chung, nhưng biến bảng được hiển thị bởi hàm có giá trị bảng không thể hỗ trợ đọc song song vì lý do cụ thể thực hiện. Bạn sẽ cần một người có quyền truy cập mã nguồn (và tự do chia sẻ chi tiết) để cung cấp một câu trả lời có thẩm quyền, tôi sợ.

Là hỗ trợ cho UDF song song là một tính năng hợp lý để yêu cầu?

Tất nhiên, nếu bạn có thể làm một trường hợp đủ mạnh. Cảm giác của riêng tôi là công việc liên quan sẽ rộng rãi, vì vậy đề xuất của bạn sẽ phải đáp ứng một thanh cực kỳ cao. Ví dụ, một yêu cầu liên quan (và đơn giản hơn nhiều) để cung cấp các hàm vô hướng nội tuyến có sự hỗ trợ tuyệt vời, nhưng đã không được thực hiện trong nhiều năm nay.

Bạn có thể muốn đọc bài báo của Microsoft:

• Froid: Tối ưu hóa các chương trình bắt buộc trong cơ sở dữ liệu quan hệ (pdf)

... trong đó phác thảo cách tiếp cận mà Microsoft đang tìm cách giải quyết các vấn đề về hiệu năng của hàm vô hướng T-SQL trong bản phát hành sau SQL Server 2017.

Mục tiêu của Froid là cho phép các nhà phát triển sử dụng các tóm tắt của UDF và các thủ tục mà không ảnh hưởng đến hiệu suất. Froid đạt được mục tiêu này bằng cách sử dụng một kỹ thuật mới để tự động chuyển đổi các chương trình bắt buộc thành các dạng đại số quan hệ tương đương bất cứ khi nào có thể. Các mô hình Froid chặn các mã bắt buộc dưới dạng các biểu thức quan hệ và kết hợp chúng một cách có hệ thống thành một biểu thức bằng cách sử dụng toán tử Áp dụng, từ đó cho phép trình tối ưu hóa truy vấn chọn các kế hoạch truy vấn song song , định hướng hiệu quả .

(nhấn mạnh của tôi)

Các hàm T-SQL vô hướng nội tuyến hiện được triển khai trong SQL Server 2019 .

Như Paul đã đề cập đúng trong câu trả lời của mình, không có lý do cơ bản nào khiến UDF vô hướng không thể được thực thi bằng cách sử dụng song song. Tuy nhiên, ngoài những thách thức thực hiện, còn có một lý do khác để buộc chúng phải nối tiếp. Bài báo Froid được Paul trích dẫn cung cấp thêm thông tin về điều này.

Trích dẫn từ bài báo (Phần 2.3):

Hiện tại, SQL Server không sử dụng song song truy vấn nội bộ trong các truy vấn gọi UDF. Các phương pháp có thể được thiết kế để giảm thiểu giới hạn này, nhưng chúng đưa ra những thách thức bổ sung, chẳng hạn như chọn mức độ song song phù hợp cho mỗi lần gọi UDF.

Ví dụ, hãy xem xét một UDF gọi các truy vấn SQL khác, chẳng hạn như truy vấn trong Hình 1. Mỗi truy vấn như vậy có thể tự sử dụng song song, và do đó, trình tối ưu hóa không có cách nào để biết cách chia sẻ các luồng trên chúng, trừ khi nó nhìn vào UDF và quyết định mức độ song song cho mỗi truy vấn bên trong (có thể có khả năng thay đổi từ một yêu cầu này sang một yêu cầu khác). Với các UDF lồng nhau và đệ quy, vấn đề này càng trở nên khó quản lý hơn.

Cách tiếp cận của Froid, như được mô tả trong bài báo, sẽ không chỉ dẫn đến các kế hoạch song song, mà còn bổ sung thêm nhiều lợi ích hơn cho các truy vấn với UDF. Về bản chất, nó chấp nhận yêu cầu của bạn để thực hiện song song các UDF.

Cập nhật: Froid hiện có sẵn như là một tính năng của bản xem trước SQL Server 2019. Tính năng này được gọi là "Nội tuyến UDF nội tuyến". Thêm thông tin chi tiết tại đây: https://bloss.msdn.microsoft.com/sqlserverst Storageengine / 2018/11/07 / int sinh-scarar-udf-inlining /

[Tiết lộ: Tôi là đồng tác giả của bài báo Froid]