Kể từ khi phát hành SQL Server 2017 cho Linux, Microsoft đã thay đổi khá nhiều toàn bộ trò chơi. Nó cho phép một thế giới khả năng hoàn toàn mới cho cơ sở dữ liệu quan hệ nổi tiếng của họ, cung cấp những gì chỉ có sẵn trong không gian Windows cho đến lúc đó.
Tôi biết rằng một DBA thuần túy nhất sẽ cho tôi biết ngay rằng phiên bản Linux SQL Server 2019 mới ra mắt có một số điểm khác biệt, về mặt tính năng, liên quan đến đối tác Windows của nó, chẳng hạn như:
- Không có tác nhân SQL Server
- Không có FileStream
- Không có thủ tục lưu trữ mở rộng hệ thống (ví dụ:xp_cmdshell)
Tuy nhiên, tôi đủ tò mò để nghĩ "điều gì sẽ xảy ra nếu chúng có thể được so sánh, ít nhất là ở một mức độ nào đó, chống lại những thứ mà cả hai đều có thể làm được?" Vì vậy, tôi đã kích hoạt một vài máy ảo, chuẩn bị một số thử nghiệm đơn giản và thu thập dữ liệu để trình bày cho bạn. Hãy xem mọi thứ diễn ra như thế nào!
Cân nhắc ban đầu
Dưới đây là thông số kỹ thuật của từng máy ảo:
- Windows
- Hệ điều hành Windows 10
- 4 vCPU
- RAM 4 GB
- SSD 30 GB
- Linux
- Máy chủ Ubuntu 20.04 LTS
- 4 vCPU
- RAM 4 GB
- SSD 30 GB
Đối với Phiên bản SQL Server, tôi đã chọn phiên bản mới nhất cho cả hai Hệ điều hành:SQL Server 2019 Developer Edition CU10
Trong mỗi lần triển khai, thứ duy nhất được bật là Khởi tạo tệp tức thì (được bật theo mặc định trên Linux, được bật theo cách thủ công trên Windows). Ngoài ra, các giá trị mặc định vẫn được giữ nguyên cho phần còn lại của cài đặt.
- Trong Windows, bạn có thể chọn bật Khởi tạo tệp tức thì bằng trình hướng dẫn cài đặt.
Bài đăng này sẽ không đề cập đến tính cụ thể của công việc Khởi tạo tệp tức thì trong Linux. Tuy nhiên, tôi sẽ để lại cho bạn một liên kết đến bài viết chuyên dụng mà bạn có thể đọc sau (lưu ý rằng nó hơi nặng về mặt kỹ thuật).
Kiểm tra bao gồm những gì?
- Trong mỗi phiên bản SQL Server 2019, tôi đã triển khai cơ sở dữ liệu thử nghiệm và tạo một bảng chỉ có một trường (NVARCHAR (MAX)).
- Sử dụng một chuỗi 1.000.000 ký tự được tạo ngẫu nhiên, tôi đã thực hiện các bước sau:
- * Chèn X số hàng vào bảng kiểm tra.
- Đo lường thời gian cần thiết để hoàn thành câu lệnh INSERT.
- Đo kích thước của các tệp MDF và LDF.
- Xóa tất cả các hàng trong bảng kiểm tra.
- ** Đo lường thời gian cần thiết để hoàn thành câu lệnh DELETE.
- Đo kích thước của tệp LDF.
- Bỏ cơ sở dữ liệu thử nghiệm.
- Tạo lại cơ sở dữ liệu thử nghiệm.
- Lặp lại cùng một chu kỳ.
* X được thực hiện cho 1.000, 5.000, 10.000, 25.000 và 50.000 hàng.
** Tôi biết rằng câu lệnh TRUNCATE thực hiện công việc hiệu quả hơn, nhưng quan điểm của tôi ở đây là chứng minh mỗi nhật ký giao dịch được quản lý tốt như thế nào đối với thao tác xóa trong mỗi hệ điều hành.
Bạn có thể truy cập trang web mà tôi đã sử dụng để tạo chuỗi ngẫu nhiên nếu bạn muốn tìm hiểu sâu hơn.
Dưới đây là các phần của mã TSQL mà tôi đã sử dụng cho các bài kiểm tra trong mỗi Hệ điều hành:
Mã TSQL Linux
Tạo cơ sở dữ liệu và bảng
DROP DATABASE IF EXISTS test
CREATE DATABASE test
ON
(FILENAME= '/var/opt/mssql/data/test.mdf', NAME = test, FILEGROWTH = 128MB)
LOG ON
(FILENAME= '/var/opt/mssql/data/test_log.ldf',NAME = test_log, FILEGROWTH = 64MB);
CREATE TABLE test.dbo.ubuntu(
long_string NVARCHAR(MAX) NOT NULL
)
Kích thước của tệp MDF và LDF cho cơ sở dữ liệu thử nghiệm
SELECT
DB_NAME(database_id) AS 'DB',
type_desc AS 'Type',
state_desc AS 'State',
CONVERT(DECIMAL(10,2),size*8/1024) AS 'Size',
CONVERT(DECIMAL(10,2),growth*8/1024) AS 'Growth'
FROM sys.master_files
WHERE DB_NAME(database_id) = 'test'
Ảnh chụp màn hình bên dưới hiển thị kích thước của tệp dữ liệu khi không có gì được lưu trữ trong cơ sở dữ liệu:
Truy vấn để xác định xem Khởi tạo tệp tức thì có được bật hay không
SELECT
servicename,
instant_file_initialization_enabled
FROM sys.dm_server_services
WHERE servicename = 'SQL Server (MSSQLSERVER)'
Mã TSQL của Windows
Tạo cơ sở dữ liệu và bảng
DROP DATABASE IF EXISTS test
CREATE DATABASE test
ON
(FILENAME= 'S:\Program Files\Microsoft SQL Server\MSSQL15.WINDOWS\MSSQL\DATA\test.mdf', NAME = test, FILEGROWTH = 128MB)
LOG ON
(FILENAME= ''S:\Program Files\Microsoft SQL Server\MSSQL15.WINDOWS\MSSQL\DATA\test_log.ldf',NAME = test_log, FILEGROWTH = 64MB);
CREATE TABLE test.dbo.windows(
long_string NVARCHAR(MAX) NOT NULL
)
Kích thước của tệp MDF và LDF cho cơ sở dữ liệu thử nghiệm
SELECT
DB_NAME(database_id) AS 'DB',
type_desc AS 'Type',
state_desc AS 'State',
CONVERT(DECIMAL(10,2),size*8/1024) AS 'Size',
CONVERT(DECIMAL(10,2),growth*8/1024) AS 'Growth'
FROM sys.master_files
WHERE DB_NAME(database_id) = 'test'
Ảnh chụp màn hình sau đây hiển thị kích thước của tệp dữ liệu khi không có gì được lưu trữ trong cơ sở dữ liệu:
Truy vấn để xác định xem Khởi tạo tệp tức thì có được bật hay không
SELECT
servicename,
instant_file_initialization_enabled
FROM sys.dm_server_services
WHERE servicename = 'SQL Server (MSSQLSERVER)'
Tập lệnh để thực hiện câu lệnh INSERT:
@limit -> ở đây tôi đã chỉ định số hàng để chèn vào bảng thử nghiệm
Đối với Linux, vì tôi thực thi tập lệnh bằng SQLCMD, tôi đặt hàm DATEDIFF ở cuối. Nó cho tôi biết toàn bộ quá trình thực thi mất bao nhiêu giây (đối với biến thể Windows, tôi có thể chỉ cần xem qua bộ đếm thời gian trong SQL Server Management Studio).
Toàn bộ chuỗi 1.000.000 ký tự thay vì "XXXX". Tôi đặt nó như vậy chỉ để trình bày nó độc đáo trong bài đăng này.
SET NOCOUNT ON
GO
DECLARE @StartTime DATETIME;
DECLARE @i INT;
DECLARE @limit INT;
SET @StartTime = GETDATE();
SET @i = 0;
SET @limit = 1000;
WHILE(@i < @limit)
BEGIN
INSERT INTO test.dbo.ubuntu VALUES('XXXX');
SET @i = @i + 1
END
SELECT DATEDIFF(SECOND,@StartTime,GETDATE()) AS 'Elapsed Seconds';
Tập lệnh để thực hiện câu lệnh DELETE
SET NOCOUNT ON
GO
DECLARE @StartTime DATETIME;
SET @StartTime = GETDATE();
DELETE FROM test.dbo.ubuntu;
SELECT DATEDIFF(SECOND,@StartTime,GETDATE()) AS 'Elapsed Seconds';
Kết quả thu được
Tất cả các kích thước được biểu thị bằng MB. Tất cả các phép đo thời gian được biểu thị bằng giây.
INSERT Time | 1.000 bản ghi | 5.000 bản ghi | 10.000 bản ghi | 25.000 bản ghi | 50.000 bản ghi |
Linux | 4 | 23 | 43 | 104 | 212 |
Windows | 4 | 28 | 172 | 531 | 186 |
Kích thước (MDF) | 1.000 bản ghi | 5.000 bản ghi | 10.000 bản ghi | 25.000 bản ghi | 50.000 bản ghi |
Linux | 264 | 1032 | 2056 | 5128 | 10184 |
Windows | 264 | 1032 | 2056 | 5128 | 10248 |
Kích thước (LDF) | 1.000 bản ghi | 5.000 bản ghi | 10.000 bản ghi | 25.000 bản ghi | 50.000 bản ghi |
Linux | 104 | 264 | 360 | 552 | 148 |
Windows | 136 | 328 | 392 | 456 | 584 |
Thời gian XÓA | 1.000 bản ghi | 5.000 bản ghi | 10.000 bản ghi | 25.000 bản ghi | 50.000 bản ghi |
Linux | 1 | 1 | 74 | 215 | 469 |
Windows | 1 | 63 | 126 | 357 | 396 |
XÓA Kích thước (LDF) | 1.000 bản ghi | 5.000 bản ghi | 10.000 bản ghi | 25.000 bản ghi | 50.000 bản ghi |
Linux | 136 | 264 | 392 | 584 | 680 |
Windows | 200 | 328 | 392 | 456 | 712 |
Thông tin chi tiết chính
- Kích thước của tấm MDF tương đối nhất quán trong toàn bộ thử nghiệm, hơi thay đổi ở phần cuối (nhưng không có gì quá điên rồ).
- Thời gian cho INSERT phần lớn tốt hơn trong Linux, ngoại trừ phần cuối khi Windows “thắng vòng”.
- Kích thước của tệp nhật ký giao dịch được xử lý tốt hơn trong Linux sau mỗi vòng INSERT.
- Thời gian cho DELETE hầu hết đều tốt hơn trong Linux, ngoại trừ phần cuối khi Windows “thắng vòng” (tôi thấy thật tò mò khi Windows cũng giành chiến thắng trong vòng INSERT cuối cùng).
- Kích thước của các tệp nhật ký giao dịch sau mỗi vòng XÓA có khá nhiều ràng buộc về mặt thăng trầm giữa hai loại.
- Tôi muốn thử nghiệm với 100.000 hàng, nhưng tôi hơi thiếu dung lượng đĩa, vì vậy tôi đã giới hạn ở 50.000.
Kết luận
Dựa trên kết quả thu được từ thử nghiệm này, tôi cho rằng không có lý do chính đáng để tuyên bố rằng biến thể Linux hoạt động tốt hơn theo cấp số nhân so với phiên bản Windows của nó. Tất nhiên, đây không phải là một bài kiểm tra chính thức mà bạn có thể dựa vào đó để đưa ra quyết định như vậy. Tuy nhiên, bản thân bài tập đã đủ thú vị đối với tôi.
Tôi đoán rằng SQL Server 2019 dành cho Windows đôi khi bị chậm một chút (không nhiều) do GUI hiển thị trong nền, điều này không xảy ra ở phía hàng rào của Máy chủ Ubuntu.
Nếu bạn chủ yếu dựa vào các tính năng và khả năng dành riêng cho Windows (ít nhất là tại thời điểm viết bài này), thì hãy sử dụng nó. Nếu không, bạn sẽ khó có một lựa chọn tồi khi chọn cái này thay cho cái kia.