ПАРАЛЛЕЛЬНАЯ ОБРАБОТКА ТРАНЗАКЦИЙ В СИСТЕМАХ ИНТЕРНЕТ-ТОРГОВЛИ С ИСПОЛЬЗОВАНИЕМ СОВРЕМЕННЫХ АРХИТЕКТУР БАЗ ДАННЫХ

Введение

Рост интернет-торговли ведет к увеличению числа параллельных транзакций, что создает риск конфликтов, блокировок и падения производительности в СУБД. Поиск баланса между надежностью и скоростью обработки транзакций является критически важной задачей для масштабируемости современных систем. Цель настоящей работы --- провести экспериментальное сравнение четырёх современных систем управления базами данных --- PostgreSQL, MySQL, MariaDB и Firebird --- с точки зрения их способности эффективно обрабатывать параллельные транзакции в условиях, моделирующих реальные сценарии интернет-торговли. Задачами исследования являются анализ влияния архитектуры СУБД и уровня изоляции транзакций на производительность, а также определение оптимальных конфигураций, обеспечивающих баланс между скоростью обработки и надёжностью данных.

1 Теоретические основы параллельной обработки транзакций

Основу параллельной обработки составляет транзакция --- последовательность операций с базой данных, которые выполняются как единое целое, через атомарность, согласованность, изоляцию и долговечность [1]. Данные свойства реализованы во всех ведущих реляционных СУБД, что обеспечивает высокую степень надёжности корпоративных информационных систем.

Уровни изоляции (Read Uncommitted, Read Committed, Repeatable Read, Serializable) определяют, как транзакции могут взаимодействовать между собой, и насколько сильно могут пересекаться и мешать друг другу при параллельной работе. Современные СУБД развивают параллелизм через многопоточность, распределённые транзакции и батчевую обработку. Механизмы вроде многоверсионности и предикативных блокировок минимизируют конфликты и распределяют нагрузку.

В интернет-торговле, где параллельно выполняются заказы, обновления остатков и платежи, корректные уровни изоляции и архитектурные решения СУБД предотвращают конфликты и потери данных, обеспечивая отказоустойчивость и производительность при высокой нагрузке.

2 Методология исследования

Для исследования использовались четыре СУБД --- PostgreSQL, MySQL, MariaDB и Firebird, каждая с различными механизмами параллелизма. PostgreSQL применяет MVCC, MySQL --- блокировки InnoDB [2], MariaDB --- parallel replication, Firebird --- многопоколенную архитектуру [3]. Эксперименты проводились на ноутбуке с ОС Windows 10, процессором AMD Ryzen 5 3500U (2.1 ГГц) и 8 ГБ ОЗУ. Для тестирования использовалась унифицированная база данных с таблицами users, products и orders, моделирующая структуру интернет-магазина. Это обеспечило сопоставимость результатов при анализе производительности различных систем.

Было подготовлено четыре скрипта для трёх типов исследований: 1) оценка масштабируемости СУБД путём измерения производительности при росте числа параллельных транзакций; 2) анализ компромисса между согласованностью данных и скоростью работы при разных уровнях изоляции; 3) исследование влияния размера пакета операций на время отклика и количество успешно выполненных транзакций.

Параметры исследований включали варьирование количества параллельных транзакций, изменение уровня изоляции и размера пакета. Для оценки эффективности использовались ключевые метрики: время обработки транзакций, число успешно завершённых транзакций и задержка выполнения.

3 Результаты экспериментов

3.1 Производительность при увеличении числа параллельных транзакций

Для оценки масштабируемости и способности СУБД эффективно обрабатывать параллельные транзакции было проведено экспериментальное исследование с использованием Python-скрипта, который имитировал выполнение типичных операций интернет-магазина: добавление нового пользователя, оформление заказа и обновление остатка товара. Для каждой СУБД были заданы одинаковые сценарии, различавшиеся только уровнем параллелизма. Количество потоков (1, 5, 10, 20 и 50) соответствовало числу одновременно выполняемых транзакций. Каждая транзакция включала три основные операции записи в базу данных, выполнявшиеся в рамках одной логической сессии с управлением соединениями через пул.

PostgreSQL показала плавный рост времени отклика и 100% успешность транзакций благодаря эффективной реализации многоверсионного контроля (MVCC), что подтверждает её стабильность и хорошую масштабируемость.

Таблица 1. Исследование производительности для PostgreSQL

Потоки	Среднее время (мс)	Успехов	Ошибок	Общее время (с)
1	15.63	1	0	0.016
5	3.13	5	0	0.485
10	4.69	10	0	1.172
20	5.35	20	0	2.476
50	6.82	50	0	6.862

MySQL демонстрировала умеренный рост производительности до 20 потоков, но при 50 транзакциях возникли ошибки фиксации (7 из 50), что связано с блокировками (gap locks, next-key locks) в InnoDB. Несмотря на относительно высокую скорость обработки при малом числе потоков, при увеличении нагрузки система столкнулась с внутренними конфликтами транзакций.

Таблица 2. Исследование производительности для MySQL

Потоки	Среднее время (мс)	Успехов	Ошибок	Общее время (с)
1	26.25	1	0	0.026
5	15.63	5	0	0.016
10	13.07	10	0	0.027
20	13.28	20	0	0.031
50	16.07	43	7	0.053

MariaDB показала наилучшие результаты при средних нагрузках (5--20 потоков) с минимальным временем выполнения и незначительным числом ошибок, что обусловлено эффективным распределением нагрузки и parallel replication.

Таблица 3. Исследование производительности для MariaDB

Потоки	Среднее время (мс)	Успехов	Ошибок	Общее время (с)
1	14.15	1	0	0.014
5	0.00	5	0	0.016
10	0.00	10	0	0.016
20	7.89	19	1	0.024
50	4.69	49	1	0.047

Firebird продемонстрировала худшую производительность с резким ростом времени выполнения, хотя и сохранила 100% успешность транзакций. Это объясняется накладными расходами многопоколенной архитектуры (MGA) на управление версиями данных.

Таблица 4. Исследование производительности для Firebird

Потоки	Среднее время (мс)	Успехов	Ошибок	Общее время (с)
1	17.68	1	0	0.116
5	73.47	5	0	0.188
10	65.05	10	0	0.184
20	129.06	20	0	0.296
50	286.06	50	0	0.740

На основании полученных данных можно заключить, что лучшую масштабируемость при росте числа параллельных транзакций показали PostgreSQL и MariaDB, которые эффективно реализуют многоверсионный контроль и оптимизированное распределение потоков. MySQL сохранила приемлемый уровень производительности, но столкнулась с блокировками при высокой нагрузке. Firebird продемонстрировала устойчивость к ошибкам, но при этом существенно потеряла в скорости обработки из-за особенностей своей архитектуры.

3.2 Влияние уровня изоляции транзакций

Для анализа влияния уровня изоляции на производительность транзакционной обработки были проведены тесты для трёх стандартных уровней --- READ COMMITTED, REPEATABLE READ и SERIALIZABLE. Эксперименты имитировали одновременное выполнение множества операций вставки заказов в базу данных интернет-магазина, где 10 потоков выполняли по 50 транзакций. Скрипт, динамически изменял уровень изоляции для каждого теста, чтобы оценить влияние этого параметра на общую скорость выполнения и стабильность фиксации транзакций.

Таблица 5. Исследование влияния уровней изоляции транзакций

Уровень изоляции	PostgreSQL (время, успешные / ошибки)	MySQL (время, успешные / ошибки)	MariaDB (время, успешные / ошибки)	Firebird (время, успешные / ошибки)
READ COMMITTED	1.11 с --- 500 / 0	0.70 с --- 500 / 0	0.26 с --- 462 / 38	2.51 с --- 500 / 0
REPEATABLE READ	1.23 с --- 500 / 0	0.55 с --- 500 / 0	0.24 с --- 450 / 50	2.03 с --- 500 / 0
SERIALIZABLE	1.20 с --- 500 / 0	0.53 с --- 500 / 0	0.24 с --- 452 / 48	1.97 с --- 500 / 0

Изменение уровня изоляции по-разному влияло на СУБД. PostgreSQL и Firebird обеспечили 100% успешность, MySQL и MariaDB --- максимальную скорость при лёгком снижении стабильности. Оптимум между скоростью и надёжностью достигается на уровне Read Committed для MySQL и Repeatable Read для PostgreSQL.

3.3 Влияние размера пакета транзакций

В каждом тесте выполнялась вставка 1000 заказов в таблицу orders с варьированием параметра batch size --- количества операций, объединённых в одну транзакцию. Используемый скрипт открывал соединение с базой данных, последовательно выполнял пакеты вставок и фиксировал результаты (время выполнения и среднюю загрузку процессора). Таким образом моделировались реальные сценарии интернет-торговли, где группы заказов могут обрабатываться пакетно, например при массовом оформлении покупок или синхронизации данных между сервисами.

Таблица 6. Исследование влияния размера пакета транзакций

Batch size	PostgreSQL (время / CPU %)	MySQL (время / CPU %)	MariaDB (время / CPU %)	Firebird (время / CPU %)
1	0.48 с / 3.3 %	6.44 с / 5.5 %	2.56 с / 2.2 %	2.56 с / 2.2 %
10	0.22 с / 10.7 %	0.94 с / 7.9 %	0.42 с / 5.9 %	0.42 с / 5.9 %
100	0.17 с / 10.9 %	0.38 с / 16.5 %	0.17 с / 8.6 %	0.17 с / 8.6 %

Для PostgreSQL время выполнения снизилось с 0.48 с (batch=1) до 0.17 с (batch=100) при незначительном росте нагрузки на CPU, что подтверждает эффективность буферизации в MVCC. Для сценариев интернет-торговли оптимальным значением можно считать batch = 50--100, обеспечивающим баланс между скоростью и умеренной нагрузкой на процессор.

MySQL продемонстрировала значительный прирост производительности при увеличении batch size: время сократилось с 6.44 с при batch = 1 до 0.38 с при batch = 100. Это объясняется тем, что InnoDB при каждой фиксации выполняет запись в журнал и синхронизацию данных на диск; при увеличении размера пакета эти накладные расходы распределяются на большее число операций. Повышение загрузки CPU с 5.5 % до 16.5 % указывает на более активное использование буфера и улучшение пропускной способности. Таким образом, MySQL выигрывает от крупных пакетов транзакций, особенно при вставках большого объёма данных.

MariaDB показала результат, аналогичный PostgreSQL (0.17 с при batch=100), с 15-кратным ускорением по сравнению с одиночными вставками.

Firebird, согласно представленным данным, продемонстрировала схожую с MariaDB динамику (с 2.56 с до 0.17 с), так как крупные пакеты уменьшают частоту операций фиксации, затратных в MGA-архитектуре.

Эксперимент подтвердил, что увеличение размера пакета транзакций значительно повышает производительность всех исследуемых СУБД. Наибольший прирост эффективности наблюдается в MySQL и MariaDB, где использование крупных пакетов сокращает время выполнения более чем в 10 раз. PostgreSQL демонстрирует стабильное улучшение производительности при минимальной нагрузке на процессор, а Firebird показывает аналогичную MariaDB зависимость от частоты фиксаций транзакций. Для систем интернет-торговли с групповой обработкой заказов оптимальным является использование размера пакета от 50 до 100 операций, что обеспечивает максимальную пропускную способность при минимальных накладных расходах.

Выводы

В работе рассмотрены теоретические и практические аспекты параллельной обработки транзакций в системах интернет-торговли с использованием современных архитектур баз данных. Проведённые эксперименты показали, что наиболее стабильные и масштабируемые результаты продемонстрировали PostgreSQL и MariaDB благодаря эффективной реализации многоверсионного контроля и оптимизации параллельных операций. MySQL обеспечила высокую скорость обработки при умеренной нагрузке, однако при большом числе одновременных транзакций наблюдались блокировки. Firebird сохранила полную надёжность выполнения, но уступила по производительности из-за особенностей своей многопоколенной архитектуры.

Увеличение размера пакета транзакций позволило всем системам существенно сократить время обработки, что подтверждает важность оптимизации групповых операций при проектировании высоконагруженных сервисов. Полученные результаты подтверждают актуальность выбора архитектуры и параметров СУБД как ключевого фактора устойчивости и эффективности современных систем интернет-торговли [5].

Литература

1. Gray, J. The Transaction Concept: Virtues and Limitations [Электронный ресурс] / Jim Gray // Microsoft Research. -- 1995. -- Режим доступа: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-95-51.pdf
2. MySQL 8.4 Reference Manual. InnoDB Transaction Isolation Levels [Электронный ресурс] / Oracle Corporation. -- 2024. -- Режим доступа: https://dev.mysql.com/doc/refman/8.4/en/innodb-transaction-isolation-levels.html
3. Firebird Documentation: Using Firebird [Электронный ресурс] / FirebirdSQL Foundation. -- 2023. -- Режим доступа: https://www.firebirdsql.org/file/documentation/html/en/firebirddocs/ufb/using-firebird.html
4. TPC Benchmark™ C Standard Specification [Электронный ресурс] / Transaction Processing Performance Council (TPC). -- Version 5.11.0. -- 2023. -- Режим доступа: https://www.tpc.org/tpc_documents_current_versions/pdf/tpc-c_v5.11.0.pdf
5. Harizopoulos, S. OLTP Through the Looking Glass, and What We Found There [Электронный ресурс] / Stavros Harizopoulos, Daniel J. Abadi, Samuel Madden, Michael Stonebraker // Proceedings of the ACM SIGMOD. -- 2008. -- Режим доступа: https://dl.acm.org/doi/10.1145/1620585.1620587