Khám phá SQL Server 2014 CHỌN VÀO song song

SQL Server 2014 CTP1 đã ra mắt được vài tuần nay và bạn có thể đã thấy khá nhiều ấn tượng về các bảng được tối ưu hóa bộ nhớ và các chỉ mục cột lưu trữ có thể cập nhật. Mặc dù những điều này chắc chắn đáng được chú ý, nhưng trong bài đăng này, tôi muốn khám phá cải tiến song song SELECT… INTO mới. Sự cải tiến này là một trong những thay đổi dành cho trang phục may sẵn mà nhìn từ bề ngoài sẽ không yêu cầu thay đổi mã đáng kể để bắt đầu hưởng lợi từ nó. Các khám phá của tôi được thực hiện bằng phiên bản Microsoft SQL Server 2014 (CTP1) - 11.0.9120.5 (X64), Phiên bản Đánh giá Doanh nghiệp.

CHỌN song song… VÀO

SQL Server 2014 giới thiệu tính năng SELECT ... INTO được kích hoạt song song cho cơ sở dữ liệu và để kiểm tra tính năng này, tôi đã sử dụng cơ sở dữ liệu AdventureWorksDW2012 và một phiên bản của bảng FactInternetSales có 61.847.552 hàng trong đó (Tôi chịu trách nhiệm thêm các hàng đó; chúng không đi kèm với cơ sở dữ liệu theo mặc định).

Vì tính năng này, kể từ CTP1, yêu cầu mức độ tương thích cơ sở dữ liệu 110, vì mục đích thử nghiệm, tôi đặt cơ sở dữ liệu thành mức tương thích 100 và thực hiện truy vấn sau cho lần thử nghiệm đầu tiên của tôi:

SELECT  [ProductKey],
        [OrderDateKey],
        [DueDateKey],
        [ShipDateKey],
        [CustomerKey],
        [PromotionKey],
        [CurrencyKey],
        [SalesTerritoryKey],
        [SalesOrderNumber],
        [SalesOrderLineNumber],
        [RevisionNumber],
        [OrderQuantity],
        [UnitPrice],
        [ExtendedAmount],
        [UnitPriceDiscountPct],
        [DiscountAmount],
        [ProductStandardCost],
        [TotalProductCost],
        [SalesAmount],
        [TaxAmt],
        [Freight],
        [CarrierTrackingNumber],
        [CustomerPONumber],
        [OrderDate],
        [DueDate],
        [ShipDate]
INTO dbo.FactInternetSales_V2
FROM dbo.FactInternetSales;

Thời lượng thực thi truy vấn là 3 phút 19 giây trên máy ảo thử nghiệm của tôi và kế hoạch thực thi truy vấn thực tế được tạo như sau:

SQL Server đã sử dụng một kế hoạch nối tiếp, như tôi mong đợi. Cũng lưu ý rằng bảng của tôi có chỉ mục cột lưu trữ không hợp nhất trên đó đã được quét (Tôi đã tạo chỉ mục lưu trữ cột không phân biệt này để sử dụng với các thử nghiệm khác, nhưng tôi cũng sẽ hiển thị cho bạn kế hoạch thực thi truy vấn chỉ mục cột phân nhóm sau này). Kế hoạch không sử dụng song song và Columnstore Index Scan sử dụng chế độ thực thi hàng thay vì chế độ thực thi hàng loạt.

Vì vậy, tiếp theo, tôi đã sửa đổi mức tương thích cơ sở dữ liệu (và lưu ý rằng chưa có mức tương thích SQL Server 2014 trong CTP1):

USE [master];
GO
ALTER DATABASE [AdventureWorksDW2012] SET COMPATIBILITY_LEVEL = 110;
GO

Tôi đã bỏ bảng FactInternetSales_V2 và sau đó thực thi lại SELECT ... INTO hoạt động. Lần này thời lượng thực thi truy vấn là 1 phút 7 giây và kế hoạch thực thi truy vấn thực tế như sau:

Bây giờ chúng tôi có một kế hoạch song song và thay đổi duy nhất tôi phải thực hiện là mức độ tương thích cơ sở dữ liệu cho AdventureWorksDW2012. Máy ảo thử nghiệm của tôi có bốn vCPU được phân bổ cho nó và kế hoạch thực thi truy vấn đã phân phối các hàng trên bốn luồng:

Quét chỉ mục Columnstore không phân biệt, trong khi sử dụng song song, không sử dụng chế độ thực thi hàng loạt. Thay vào đó, nó sử dụng chế độ thực thi hàng.

Đây là bảng hiển thị kết quả thử nghiệm cho đến nay:

Vì vậy, trong lần kiểm tra tiếp theo, tôi đã bỏ chỉ mục cột lưu trữ không được phân bổ và thực thi lại SELECT ... INTO truy vấn sử dụng cả mức độ tương thích cơ sở dữ liệu 100 và 110.

Kiểm tra mức độ tương thích 100 mất 5 phút 44 giây để chạy và kế hoạch sau đã được tạo:

Quét chỉ mục theo cụm nối tiếp kéo dài hơn 2 phút 25 giây so với quét chỉ mục Columnstore không phân nhóm nối tiếp.

Sử dụng mức độ tương thích 110, truy vấn mất 1 phút 55 giây để chạy và kế hoạch sau đã được tạo:

Tương tự như thử nghiệm Quét chỉ mục Columnstore không phân tán song song, Quét chỉ mục theo cụm song song đã phân phối các hàng trên bốn chủ đề:

Bảng sau đây tóm tắt hai thử nghiệm nói trên:

Vì vậy, sau đó tôi tự hỏi về hiệu suất cho chỉ mục cột lưu trữ được phân cụm (mới trong SQL Server 2014), vì vậy tôi đã loại bỏ các chỉ mục hiện có và tạo chỉ mục cột lưu trữ theo cụm trên bảng FactInternetSales. Tôi cũng phải bỏ tám ràng buộc khóa ngoại khác nhau được xác định trên bảng trước khi có thể tạo chỉ mục columnstore được phân cụm.

Cuộc thảo luận trở nên hơi hàn lâm, vì tôi đang so sánh SELECT ... INTO hiệu suất ở mức độ tương thích cơ sở dữ liệu mà ngay từ đầu đã không cung cấp các chỉ mục columnstore theo cụm - cũng như các thử nghiệm trước đó cho các chỉ mục columnstore không được phân bổ ở mức độ tương thích cơ sở dữ liệu 100 - và thật thú vị khi xem và so sánh các đặc điểm hiệu suất tổng thể.

CREATE CLUSTERED COLUMNSTORE INDEX [CCSI_FactInternetSales] 
ON [dbo].[FactInternetSales] 
WITH (DROP_EXISTING = OFF);
GO

Ngoài ra, hoạt động để tạo chỉ mục cột lưu trữ được phân cụm trên bảng 61.847.552 triệu hàng mất 11 phút 25 giây với bốn vCPU có sẵn (trong đó hoạt động tận dụng tất cả), 4GB RAM và lưu trữ khách ảo trên SSD OCZ Vertex. Trong thời gian đó, các CPU không được cố định trong toàn bộ thời gian, mà hiển thị các đỉnh và đỉnh (lấy mẫu 60 giây hoạt động của CPU được hiển thị bên dưới):

Sau khi chỉ mục columnstore nhóm được tạo, tôi đã thực thi lại hai SELECT ... INTO các bài kiểm tra. Kiểm tra mức độ tương thích 100 mất 3 phút 22 giây để chạy và kế hoạch là một kế hoạch nối tiếp như mong đợi (Tôi đang hiển thị phiên bản SQL Server Management Studio của kế hoạch kể từ khi quét chỉ mục Columnstore theo cụm, kể từ SQL Server 2014 CTP1 , chưa được Plan Explorer công nhận hoàn toàn):

Tiếp theo, tôi đã thay đổi mức độ tương thích của cơ sở dữ liệu thành 110 và chạy lại kiểm tra, lần này truy vấn mất 1 phút 11 giây và có kế hoạch thực thi thực tế như sau:

Kế hoạch phân phối các hàng trên bốn luồng và cũng giống như chỉ mục cột lưu trữ không phân tán, chế độ thực thi của Quét chỉ mục Columnstore theo nhóm là hàng chứ không phải hàng loạt.

Bảng sau đây tóm tắt tất cả các bài kiểm tra trong bài đăng này (theo thứ tự thời lượng, từ thấp đến cao):

Một vài nhận xét:

• Tôi không chắc liệu sự khác biệt giữa SELECT ... INTO hoạt động dựa trên chỉ số kho lưu trữ cột không hợp nhất so với chỉ mục cửa hàng cột theo nhóm có ý nghĩa thống kê. Tôi cần phải thực hiện thêm các bài kiểm tra, nhưng tôi nghĩ tôi sẽ đợi để thực hiện những bài kiểm tra đó cho đến khi RTM.
• Tôi có thể nói một cách an toàn rằng SELECT ... INTO song song đã hoạt động tốt hơn đáng kể so với các điểm tương đương nối tiếp trên một chỉ mục được phân nhóm, kiểm tra chỉ số cột theo chuỗi không phân nhánh và kiểm tra chỉ số cột theo nhóm.

Điều đáng nói là các kết quả này dành cho phiên bản CTP của sản phẩm và các thử nghiệm của tôi nên được xem như một thứ có thể thay đổi hành vi bởi RTM - vì vậy tôi ít quan tâm đến thời lượng độc lập hơn so với thời lượng đó so với giữa nối tiếp và song song điều kiện.

Một số tính năng hiệu suất yêu cầu cấu trúc lại đáng kể - nhưng đối với SELECT ... INTO cải tiến, tất cả những gì tôi phải làm là tăng mức độ tương thích cơ sở dữ liệu để bắt đầu thấy những lợi ích, đây chắc chắn là điều tôi đánh giá cao.