MS SQL Server на Linux срещу тест за производителност на Windows, за да забележите разликата

След пускането на SQL Server 2017 за Linux, Microsoft до голяма степен промени цялата игра. Той даде възможност за цял нов свят от възможности за тяхната известна релационна база данни, предлагайки това, което дотогава беше налично само в пространството на Windows.

Знам, че един пурист DBA би ми казал веднага, че готовата версия на SQL Server 2019 Linux има няколко разлики, по отношение на функциите, по отношение на своя аналог в Windows, като например:

• Няма агент на SQL Server
• Няма FileStream
• Без системни разширени съхранени процедури (напр. xp_cmdshell)

Въпреки това станах достатъчно любопитен, за да си помисля „а какво, ако те могат да бъдат сравнени, поне до известна степен, с неща, които и двамата могат да направят?“ И така, дръпнах спусъка на няколко виртуални машини, подготвих някои прости тестове и събрах данни, които да ви представя. Да видим как ще се развият нещата!

Първоначални съображения

Ето спецификациите на всяка виртуална машина:

• Windows
  • ОС Windows 10
  • 4 vCPU
  • 4 GB RAM
  • 30 GB SSD

• Linux
  • Ubuntu Server 20.04 LTS
  • 4 vCPU
  • 4 GB RAM
  • 30 GB SSD

За версията на SQL Server избрах най-новата и за двете операционни системи:SQL Server 2019 Developer Edition CU10

При всяко внедряване единственото активирано нещо беше незабавната инициализация на файл (активирана по подразбиране в Linux, активирана ръчно в Windows). Освен това, стойностите по подразбиране остават за останалите настройки.

• В Windows можете да изберете да активирате незабавна инициализация на файл със съветника за инсталиране.

Тази публикация няма да обхване спецификата на работата с Instant File Initialization в Linux. Въпреки това ще ви оставя връзка към специалната статия, която можете да прочетете по-късно (имайте предвид, че става малко тежка от техническа страна).

Какво включва тестът?

1. Във всеки екземпляр на SQL Server 2019 внедрих тестова база данни и създадох една таблица само с едно поле (NVARCHAR(MAX)).
2. Използвайки произволно генериран низ от 1 000 000 знака, изпълних следните стъпки:
   • *Вмъкнете X брой редове в тестовата таблица.
   • Измерете колко време е необходимо за завършване на оператора INSERT.
   • Измерете размера на MDF и LDF файловете.
   • Изтрийте всички редове в тестовата таблица.
   • **Измерете колко време е необходимо за завършване на оператора DELETE.
   • Измерете размера на LDF файла.
   • Изхвърлете тестовата база данни.
   • Създайте отново тестовата база данни.
   • Повторете същия цикъл.

*X беше извършен за 1 000, 5 000, 10 000, 25 000 и 50 000 реда.

**Знам, че изразът TRUNCATE върши работата много по-ефективно, но целта ми тук е да докажа колко добре се управлява всеки регистър на транзакциите за операцията за изтриване във всяка ОС.

Можете да продължите към уебсайта, който използвах за генериране на произволния низ, ако искате да копаете по-дълбоко.

Ето секциите от TSQL кода, който използвах за тестове във всяка операционна система:

Linux TSQL кодове

Създаване на база данни и таблици

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
)

Размер на MDF и LDF файловете за тестовата база данни

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'

Екранната снимка по-долу показва размерите на файловете с данни, когато нищо не се съхранява в базата данни:

Запитвания за определяне дали незабавното инициализиране на файл е активирано

SELECT 
       servicename,
       instant_file_initialization_enabled
FROM   sys.dm_server_services
WHERE  servicename = 'SQL Server (MSSQLSERVER)'

TSQL кодове на Windows

Създаване на база данни и таблици

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
)

Размер на MDF и LDF файловете за тестовата база данни

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'

Следната екранна снимка показва размерите на файловете с данни, когато нищо не се съхранява в базата данни:

Запитване, за да определите дали незабавното инициализиране на файл е активирано

SELECT 
       servicename,
       instant_file_initialization_enabled
FROM   sys.dm_server_services
WHERE  servicename = 'SQL Server (MSSQLSERVER)'

Скрипт за изпълнение на оператора INSERT:

@limit -> тук посочих броя на редовете за вмъкване в тестовата таблица

За Linux, тъй като изпълних скрипта с SQLCMD, поставих функцията DATEDIFF в самия край. Позволява ми да знам колко секунди отнема цялото изпълнение (за варианта на Windows бих могъл просто да хвърля поглед върху таймера в SQL Server Management Studio).

Целият низ от 1 000 000 знака отива вместо „XXXX“. Поставям го така, само за да го представя добре в тази публикация.

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';

Скрипт за изпълнение на оператора DELETE

SET NOCOUNT ON
GO
DECLARE @StartTime DATETIME;
SET @StartTime = GETDATE();

DELETE FROM test.dbo.ubuntu;

SELECT DATEDIFF(SECOND,@StartTime,GETDATE()) AS 'Elapsed Seconds';

Получените резултати

Всички размери са изразени в MB. Всички измервания на времето се изразяват в секунди.

Ключови прозрения

• Размерът на MDF беше почти постоянен през целия тест, като варираше леко в самия край (но нищо прекалено лудо).
• Моментите за INSERT бяха по-добри в Linux в по-голямата си част, с изключение на самия край, когато Windows „спечеля кръга“.
• Размерът на регистрационния файл на транзакциите се обработваше по-добре в Linux след всеки кръг от INSERT.
• Моментите за DELETE бяха по-добри в Linux в по-голямата си част, с изключение на самия край, където Windows „спечели кръга“ (намирам за любопитно, че Windows също спечели последния кръг INSERT).
• Размерът на регистрационните файлове на транзакциите след всеки кръг от ИЗТРИВАНЕ беше почти равен по отношение на възходи и падения между двете.
• Бих искал да тествам със 100 000 реда, но ми липсваше малко дисково пространство, затова го ограничих на 50 000.

Заключение

Въз основа на резултатите, получени от този тест, бих казал, че няма сериозна причина да се твърди, че вариантът на Linux се представя експоненциално по-добре от неговия аналог на Windows. Разбира се, това в никакъв случай не е формален тест, на който можете да вземете такова решение. Самото упражнение обаче ми беше достатъчно интересно.

Предполагам, че SQL Server 2019 за Windows понякога изостава малко (не много) поради изобразяването на GUI във фонов режим, което не се случва от страната на Ubuntu Server на оградата.

Ако разчитате до голяма степен на функции и възможности, които са ексклузивни за Windows (поне към момента на писане на това писмо), тогава непременно го направете. В противен случай едва ли ще направите лош избор, като изберете едно от друго.