От автора: благодаря тому, что существуют транзакции MySQL, мы с вами можем пользоваться такими инфраструктурными благами, как бронирование номеров отелей, интернет-банкинг и дистанционный аудит. Но, сама природа обмена данными в структурных таблицах MySQL не так проста, как может показаться. За быстродействие и стабильность, веб-разработчик платит часами труда и концентрации. Сегодня мы посвятим время тому, чтобы изучить основы транзакционного механизма и его подводных камней.
Под внимательным рассмотрением
Перед тем, как перейти к тому, зачем они нужны и как проводятся транзакции в MySQL, нам необходимо разобраться с самим сабжем. А также, разобраться, под давлением каких факторов изобрели само явление транзакций в базах данных, ведь систему запрос-ответ можно было реализовывать и до того.
Итак, представим, что у нас есть конкретный интернет-магазин, который активно продает свои товары по всему миру, оптом и в розницу. База данных покупателей составляет сотни тысяч человек, а одномоментно на страницах листают товар и нажимают «buy» не менее тысячи юзеров. Только для одной страницы с продуктами магазина необходимо проводить десятки запросов и столько же ответов. Даже если веб-приложение работает по самым простым алгоритмам, как скажем Aliexpress, оно собирает информацию с товарами уже подготовленными к покупке и мониторит активность на страницах, предлагая товары с подобными тегами.
На примере одного пользователя это выглядит сложным механизмом. Когда речь идет о целой аудитории — все еще сложнее. Сразу несколько потенциальных покупателей могут выполнять подобные действия: это явление принято называть параллелизмом выполняемых операций. Если не контролировать этот процесс, информация для пользователей существенно исказится. Получается, что от двух и более пользователей идут подобные потоки данных.
Взирая на реляционную природу баз данных, результат такой операции может быть совершенно непредсказуем. Система не сможет отобразить ответ по правильному адресу, все перемешивается. И, чтобы убрать подобные противоречия, были изобретены транзакции.
Это своеобразная опосредованность инструкций на языке «сиквел», которая выполняется системой от начала до конца, либо не выполняется вовсе. Потоки, которые исходят к базе данных одновременно, изолированы друг от друга, а значит, их доступ к изменению данных тоже ограничен. А когда операция заканчивается, машина, на которой размещена база данных, выполняет их последовательным образом, а не одновременно, как это было бы в варианте без транзакции.
Разберем простой пример операций. Боб и Алиса переводят деньги друг другу, пусть это будет две тысячи долларов. В дотранзакционный период, для такого сценария необходимо было провести две независимых операции: снять деньги со счета одного абонента и перевести другому. На языке запросов это выглядит так:
UPDATE user_account SET allsum=allsum + 2000 WHERE id='Bob'; UPDATE user_account SET allsum=allsum - 2000 WHERE id='Alice';
Но, мы уже знаем, что базы данных иногда останавливаются, иногда тормозят, а иногда подвергаются атакам и полностью падают. Даже незначительная ошибка может привести к тому, что одна операция выполнится, а вторая — нет. Могут быть не списаны деньги со счета, или та же сумма будет потрачена дважды, либо две тысячи будут списаны, а на счет Боба не придет ни гроша.
Вот зачем нужны транзакции. Они призваны не допустить такой провальный сценарий. А потому, вся операция выполняется, как одно целое. Если произойдет ошибка на каком-то из этапов, то деньги не спишут со счетов, и они не придут на другой. Это на заметку тем, кто переживает, что сумма долго не приходит на карту. Все придет, ведь в основе финансовых операций лежат транзакции MySQL или другой системы управления базами данных.
Детально о параллелизме
Как вы уже знаете, параллельные запросы являются одним из базовых камней преткновения в системах управления базами данных. Если даже не вдаваться в подробности функционирования банковской системы, всю сложность вычислений можно продемонстрировать на основе обычного товарного склада.
Представьте, что существует двое коллег, которые отгружают товар и вносят изменения в базу данных, каждый из своего устройства. Каждый из сейлс-агентов, продает и закупает определенное количество продукции, и если бы не было механизма регулирования этого процесса, в базах данных никогда не находилась бы верная информация.
Чтобы облегчить параллельные запросы была установлена система блокировок. Есть центр, который совершает контроль над потоками и блокирует строку, если это необходимо. К примеру, пока один продавец обращается к элементу базы данных, она заблокирована. Как только освободится — другие могут обращаться и изменять ее.
Откат — отмена
Одной из самых важных характеристик, которые делают транзакции используемыми, является возможность ее отмены. Несмотря на то, что некоторые современные разработчики считают возможность отмены уязвимостью и предпочитают блокчейн централизованному реестру. Вторая — это фиксация транзакции. Их принято называть роллбэеками и комитами соответственно. Вообще, все транзакции должны иметь эти четыре свойства:
атомарность. Об этом уже говорили в ходе рассмотрения. Это значит, что все элементы операции должны выполняться одним действием. Если не выполнено хотя бы одно из них, все остальные тоже не применятся. Этот принцип базы данных защищает от двойного использования средств и других двойных изменений;
согласованность. Достигается путем сериализации;
изолированность. Этот параметр обеспечивает стабильную работу при параллельных запросах;
устойчивость. Когда транзакция будет завершена, все изменения становятся необратимыми. Если только такой механизм не записан в алгоритм.
Если не соблюдается хоть один их параметров, такая транзакция не должна проводиться в принципе. Как мы и говорили, одновременность потоков — лишь видимость. На самом деле, транзакции для того и нужны, чтобы обеспечить видимую синхронность. В реальности же, действия происходят последовательно, друг за другом.
В самом начале базы работали абсолютно без транзакций. InnoDB и сегодня она является одним из основных инструментов разработчика. Но, и до ее изобретения, существовали сервисы, подобные современным. Все работало благодаря тому, что содержимое блокировалось на уровне таблицы. И даже сегодня переход на новый движок не всегда оправдан. Для большинства проектов достаточно того функционала, который представляет MyISAM. Об основных движках с поддержкой транзакций — ниже.
Berkley для транзакций
Еще один удачный продукт, который успела приобрести компания Oracle. Это СУБД, которая, в отличии от многих, не является реляционной, а поддерживается за счет ассоциативного массива. Умеет работать с большими массивами, является почти абсолютно кроссплатформенной, что применимо даже для осей реального времени.
Имеет особенную архитектуру. К примеру, полностью лишена сетевого доступа, функции которого реализованы через API внутри процессора. Для программного обеспечения, «сиквел» является всего лишь одним из интерфейсов. СУБД, как и MySQL, поддерживает такие фишки, как транзакции, репликацию и бэкапы. Сравнить даже с героем нашей статьи — MySQL. Также, поставляется с большинством дистрибутивов Linux.
InnoDB — массовый старт транзакций
На ряду с MyISAM, это одна из систем, которая поддерживается системой управления базами данных MySQL. Современные разработчики советуют использовать этот движок для 9 из 10 случаев, но, и здесь есть свои препятствия.
Поддержка Inno началась недавно, если сравнивать с ISAM или Berkley. Только в 2001 MySQL начала работать с этим типом таблиц. Но, уже со следующей версии началась полномасштабное внедрение Inno в набор инструментов СУБД. Как и MySQL, Berkley и многие другие, разрабатывается и поддерживается компанией Oracle.
Этот тип таблиц считается более безопасным, чем любой другой транзакционный движок, имеет гибкую систему настроек. Оснащен полнотекстовым поиском: до недавнего времени отсутствовал, что заставляло вебмастеров делать выбор в пользу MyISAM. Тем не менее, быстродействие таблиц ISAM до сих пор находят себе поклонников.
Итог: транзакции — важнейший элемент в банковской системе, интернет-магазинах и многих других e-commerce решениях. Благодаря высокому уровню безопасности, который они предлагают, мы имеем большинство современных технологий. Это относительно простая последовательность инструкций, но до сих пор не придумали ничего лучше. Транзакции на основе блокчейна могут стать новым витком в развитии этой индустрии. Однако, пока распределенный реестр еще медленный и несовершенный, а значит, MySQL-транзакции еще долго будут в тренде.
На этом мы заканчиваем! Подробные мануалы ищите в документации и в свободном доступе. Обсуждаемость предмета очень высока в кругах веб-разработчиков.