Что такое px storage engine
Оптимизируем VPS за 5$ (512MB RAM / 1 CPU) так, что сайт на wordpress выдерживает нагрузку в 42,735,587 хитов в день
Когда вы приобретаете сервер VPS с 256MB или 512MB оперативной памяти на борту и лишь часть мощности процессора, то использовать для таких сервисов как MySQL/PHP/Apache настройки по умолчанию является очень плохой идеей. В настоящее время у меня запущено 3 сайта на самом дешевом тарифном плане с 512MB RAM/1 CPU. Не уверен полностью, но посещаемость составляет порядка 5-10 тысяч посетителей в день. Далее я хочу поделиться инструкцией как оптимизировать LAMP используя всего лишь 512 MB и при этом не уходя в swap. Обычно при такой настройки используется 256 – 378Mb памяти и все работает довольно быстро.
Определяем доступную память и активность swap.
Перед началом оптимизации давайте взглянем на количество используемой памяти. Для этого необходимо выполнить следующую команду:
Для того. чтобы посмотреть список запущенных процессов и отсортировать их по использованию памяти, необходимо выполнить вот такую команду:
Настраиваем LAMP сервер для потребления малого количества оперативной памяти. Останавливаем, отключаем ненужные сервисы
Первый и очевидный вопрос, который необходимо задать — это «какие сервисы мне не нужны в использовании?». Недавно, я обнаружил очень удобную утилиту для управления сервисами. Она называется «sysv-rc-conf» и управляет сервисами при помощи псевдографики и флажками. Выгдялит вот так:
Здесь представлен список сервисов, которые я изменил.
Не запускайте X-сервер, выключите все ненужные сервисы и настройте Apache, MySQL, PHP только с базовой необходимой функциональностью.
Apache
Самая большая проблема Apache — это объем оперативной памяти, который он использует. Я буду рассматривать следующие способы ускорения работы и снижения потребления оперативной памяти:
Настроить Apache на использование только наименьшего количество запущенных дочерних процессов
Prefork — это где случается настоящая магия. Это то, где мы говорим Apache генерировать много процессов. По умолчанию выделяется большое количество, что и приводит к потреблению оперативной памяти сервера. Убедитесь, что apache2.conf не настроен для запуска слишком большого количества серверов или имеет множество запасных. Ниже пример:
Также обязательно отрегулируйте параметр «KeepAliveTimeout«, установив значение 10 или 15. На мой взгляд, 15 секунд слишком много, чем маленькой странице требуется для просмотра и короче, чем требуется для длительного просмотра страницы.
Загружайте только самые необходимые модули
Настроенный по умолчанию веб-сервер Apache подгружает слишком много ненужных модулей. Проверить какие модули установлены и включены можно следующей командой:
Ниже представлен список модулей, которые необходимы для работы WordPress.
Вам необходимо закомментировать остальные модули для экономии памяти. Или же вы можете включить/отключить модули через командную строку. Для включения воспользуйтесь командой:
После проделанных манипуляций вам необходимо обязательно перезагрузить веб-сервер Apache:
Уменьшаем журналирование
Если вы хотите добиться максимальной производительности, вам определенно нужно ограничить журналирование. На моем сервере я установил уровень «error» (ошибок). Также, если вам не нужна детальная статистика, вы можете отключить логирование User-Agent или the http-referer.
Меня устраивают такие настройки, ну а вы сами решайте.
Оптимизация MySQL сервера
Тонкая настройка MySQL для использования малого количества оперативной памяти довольно проста.
Далее мы будем рассматривать следующие типы настроек MySQL:
Для оптимизации MySQL нам необходимо отредактировать файл /etc/mysql/my.cnf.
Вещи, которые нам необходимо выключить
Проблемы блокировок табличного уровня заметны только на очень нагруженных серверах. Для обычных же веб-сайтов, MyISAM показывает лучшую производительность на дешевых серверах.
Если вы решили использовать MyISAM таблицы, то вам необходимо добавить следующие строки в конфигурационный файл my.cnf:
Если у вас будут только MyISAM таблицы, вы можете отключить InnoDB движок, тем самым сэкономив оперативную память, добавив лишь одну строку в my.cnf:
Если вы в прошлом использовали InnoDB, то ниже я предоставляю вам скрипт, который автоматически переконвертирует все таблицы InnoDB в MyISAM.
Оптимизируем параметры MySQL сервера
Ниже представлены несколько параметров, которые могут быть отрегулированы с целью ускорения MySQL сервера.
Key buffer size
Это один из самых важных параметров, влияющий на потребление оперативной памяти и производительности, который необходимо оптимизировать. MySQL пытается положить все, что проиндексировано в key buffer, поэтому этот параметр приносит огромную производительность. SQL-запрос будет подан непосредственно из оперативной памяти RAM. Я не могу сказать, какой размер вы должны установить для key buffer, потому что только вы знаете, сколько RAM имеется у вас свободной.
The Query Cache
Если вы делаете одинаковые запросы два раза подряд, то результат помещается в кэш запросов, таким образом mysql не придется делать запрос снова. Если вы собираетесь повышать производительность, то этот параметр может принести огромную пользу, но возрастет потребление памяти. Поэтому вам необходимо установить этот параметр не слишком огромным, но и не слишком маленьким, то есть столько, сколько необходимо вашему веб-сайту.
Ниже приведены три переменные, которые влияют на то, как работает ваш кэш запросов:
Maximum Number of Connections
Это опциональный параметр. Если вы уже ограничили количество процессов apache, то все уже хорошо. Если нет, и вам необходимо обрабатывать тысячи пользователей одновременно, необходимо увеличить значение этого параметра.
The table Cache
Каждый раз вы обращаетесь к таблице, MySQL подгружает ссылку на таблицу как одну запись в кэш таблицы. Это делается для каждого параллельного доступа к таблице, это действительно важно для производительности, незначительно для использования памяти. Вы можете постоянно увеличивать кэш таблицы, но тогда лы упретесь в лимит на количество открытых файлов в вашей операционной системе, так что имейте это в виду. Если установлен слишком маленький кэш таблицы, то mysql будет блевать на вас, вы же не хотите этого.
Ниже приведен корректный my.cnf, который я оптимизировал на моем VPS с самым низким тарифным планом.
Сторонние мастера настройки MySQL
Я нашел Percona, которая предоставляет бесплатную настройку MySQL и помогает выбрать самые лучше возможности MySQL сервера для достижения лучшей производительности, а также сэкономить время, избежать сложных моментов и рисков, которые могут возникнуть при самостоятельной настройке my.cnf.
Мониторинг MySQL сервера
MySQL хранит статистику, которая помогает определить самые лучшие значения для использования. Кроме этого, имеются две удобные утилиты, которые можно использовать для чтения этой статистики и выводить в понятном формате: tuning-primer.sh and mysqltuner.pl.
Эти скрипты позволят мониторить ваш MySQL сервер, и после предоставят подсказку о параметрах, которые необходимо настроить на вашем сервере.
Оптимизация PHP и кэширование
PHP не очень интенсивно использует память, поэтому я не думаю, что нужно сильно беспокоится о потреблении памяти этим процессов, если ваше приложение не нуждается в этом, но даже в случае необходимости оптимизации, значительно уменьшения потребляемой памяти не будет. Но я исследовал и потом нашел несколько настроек для PHP конфигурации, которые уменьшают потребления памяти веб-сервером.
Alternative PHP Cache
Установите PHP Cache, например, такой как, Alternative PHP Cache. PHP cache будет хранить скомпилированные PHP скрипты таким образом, что они будут заново использованы без компиляции и, соответственно, не создадут нагрузку:
Ниже мой сконфигурированный php.ini файл.
Static Cache
Другая вещь, которая может быть хорошей идеей для блога на маленьком сервере — это поставить его перед статическим HTTP-cache, например, Varnish. Что может реально увеличить вашу масштабируемость. Конфигурация Varnish — это отдельная большая статья, требующая, отдельного топика.
Заключение
Я выложил в открытый доступ конфигурацию моего веб-сервера, чтобы доказать, что можно добиться высокой производительности даже от самого дешевого VPS контейнера с 512МБ RAM и 1Ghz CPU. Использую я Ubuntu 12.04 LTS, LAMP, Varnish,APC Cache для размещения 3-х веб-сайтов, сделанных на WordPress (не мультисайтовых) с посещаемостью 10к в день. Давайте взглянем на результаты тестов от Blitz.io:
Как видите, 0,23% пользователей получают Connection Timeout, когда мой веб-сайт имеет 42,735,587 хитов в день (WOW), может можно еще что-то оптимизировать, но я получаю удовольствие от работы моего веб-сервера. Если ты устал от этого руководства или не хочешь делать руками, то можешь воспользоваться такими сервисами, как PuPHPet или Vagrant.
Анализ неструктурированных данных и оптимизация их хранения
Тема анализа неструктурированных данных сама по себе не нова. Однако в последнее время в эпоху «больших данных» этот вопрос встаёт перед организациями гораздо острее. Многократный рост объёмов хранимых данных в последние годы, его постоянно увеличивающиеся темпы и нарастающее разнообразие хранимой и обрабатываемой информации существенно усложняют задачу управления корпоративными данными. С одной стороны, проблема имеет инфраструктурный характер. Так, по данным IDC, до 60% корпоративных хранилищ занимает информация, не приносящая организации никакой пользы (многочисленные копии одного и того же, разбросанные по разным участкам инфраструктуры хранения данных; информация, к которой никто не обращался несколько нет и уже вряд ли когда-нибудь обратится; прочий «корпоративный мусор»).
С другой стороны, неэффективное управление информацией ведёт к увеличению рисков для бизнеса: хранение персональных данных и прочей конфиденциальной информации на общедоступных информационных ресурсах, появление подозрительных пользовательских зашифрованных архивов, нарушения политик доступа к важной информации и т.д.
В этих обстоятельствах умение качественно анализировать корпоративную информацию и оперативно реагировать на любые несоответствия её хранения политикам и требованиям бизнеса является ключевым показателем зрелости информационной стратегии организации.
Теме аналитики файловых данных посвящён отдельный документ Gartner, вышедший в сентябре 2014 г. под названием «Market Guide for File Analysis Software». В данном документе приводятся следующие типовые сценарии использования аналитического ПО:
В данной статье будет сделан технический обзор обоих продуктов.
HP Storage Optimizer: анализ данных с целью оптимизации их хранения
HP Storage Optimizer объединяет в себе возможности по анализу метаданных объектов в репозиториях неструктурированной информации и назначению политик их иерархического хранения.
Архитектура HP Storage Optimizer
Источники анализируемой информации в терминологии HP Storage Optimizer называются репозиториями. В качестве репозиториев поддерживаются различные файловые системы, а также MS Exchange, MS SharePoint, Hadoop, Lotus Notes, Documentum и многие другие. Есть также возможность заказать разработку коннектора к репозиторию, который в настоящее время не поддерживается продуктом.
HP Storage Optimizer использует собственные соответствующие коннекторы для обращения к анализируемым репозиториям. Информация с коннекторов поступает в компонент под названием Connector Framework Server (обозначенный как «CFS» на картинке), который, в свою очередь, обогащает её дополнительными метаданными и направляет получившиеся данные на индексирование. Для повышения отказоустойчивости и балансировки нагрузки при взаимодействии приложения с коннекторами используется компонент Distributed Connector.
Метаданные индексируются «движком» HP Storage Optimizer Engine («SO Engine» на первой картинке) и помещаются в БД MS SQL. Для доступа к результатам анализа и назначения политик управления используется веб-приложение HP Storage Optimizer.
Для наглядного отображения информации, потенциально подлежащей оптимизации, в HP Storage Optimizer используются круговые диаграммы (ниже), показывающие дубликаты данных, редковостребованные и «ненужные» данные (ROT analysis: Redundant, Obsolete, Trivial). Критерии «редковостребованности» и «ненужности» можно гибко настроить, в том числе индивидуально для каждого репозитория. Кроме круговых диаграмм, доступны графики, иллюстрирующие разбивку данных по типам, времени и частоте добавления и др. Все элементы визуализации интерактивны, т.е. позволяют переходить в какую-либо категорию диаграммы (или столбец) и получать доступ к соответствующим данным.
Графический анализ данных в HP Storage Optimizer
Перечень метаданных, по которым может быть проведён анализ, необычайно широк и даёт возможность осуществлять высокоточные тематические выборки.
Пример работы с метаданными в HP Storage Optimizer
Хотелось бы заметить, что в состав продуктов HP Storage Optimizer и HP Control Point входит «движок» индексирования и визуализации, позволяющий просматривать более 400 различных форматов данных без установки на сервер соответствующих приложений для предпросмотра. Это значительно упрощает и ускоряет процесс анализа большого количества разноплановой информации.
После того как анализ данных проведён, администратору системы предоставляется возможность назначить политики удаления или перемещения данных. Политики на те или иные выборки данных возможно назначать как вручную, так и автоматически. Мощная ролевая модель управления, реализованная в HP Storage Optimizer и в HP Control Point, даёт возможность выдавать полномочия по работе с репозиториями, анализу данных в них, а также по назначению политик, максимально гибко.
HP Control Point: комплексный анализ для снижения бизнес-рисков, связанных с хранением данных
HP Control Point, по сути, представляет собой расширенную версию HP Storage Optimizer и предоставляет инструментарий не только для решения задач по оптимизации хранения, но и для внедрения политик хранения и управления жизненным циклом корпоративной информации.
Продукт позволяет проводить анализ информации не только по метаданным, но и по её содержимому. Кроме того, в нём реализованы дополнительные механизмы анализа данных и назначения политик по работе с ними.
Архитектура HP Control Point
В отличие от HP Storage Optimizer, в HP Control Point широко используются возможности индексирования и смысловой категоризации информации «движка» HP IDOL (Intelligent Data Operating Layer): визуализация, категоризация, тэгирование и др. В его основе лежит возможность определять «смысл» набора анализируемой информации независимо от её формата, языка и т.д.
В частности, в HP Control Point дополнительно доступны два типа визуализации информации: кластерная карта и спектрограф. Кластерная карта представляет собой двухмерное изображение информационных «кластеров». Один кластер объединяет в себе информацию, имеющую схожий смысл. Таким образом, глядя на кластерную карту, можно быстро получить понимание основных смысловых групп этой информации. Кластерные карты интерактивны, т.е. позволяют с помощью кликов на те или иные кластеры получать доступ к информации, содержащейся в них.
Внешний вид кластерной карты в HP Control Point
Спектрограф представляет собой набор информационных кластеров, снятых в различные моменты времени и даёт возможность графически отследить, как менялся смысл информации в анализируемых репозиториях с течением времени.
Внешний вид спектрограммы в HP Control Point
Помимо расширенных возможностей визуализации информации, в HP Control Point доступна возможность категоризации анализируемой информации. Изначально информация категоризируется автоматически – средствами HP IDOL, выдавая пользователю системы массив данных, разбитый на смысловые части. Получив первичное разбиение, аналитик далее может сделать более выверенную категоризацию. Например, использовать какой-либо набор файлов, заведомо для аналитика релевантных той или иной категории, для «тренировки» категории на этот набор файлов, чтобы впоследствии получать более точные результаты категоризации. Для ещё более тонкой настройки можно использовать индивидуальные весовые коэффициенты файлов и даже фраз и отдельных слов внутри файлов, отражающие степень соответствия тех или иных единиц информации «тренируемой» категории. Такая детализация может использоваться, например, для создания подробных правил отнесения анализируемой информации к разряду конфиденциальной.
Что касается политик работы с анализируемой информацией, то в HP Control Point кроме копирования, переноса и удаления доступны также следующие опции:
– «Заморозка» объектов. Позволяет заблокировать доступ к отдельным объектам, не допуская их несанкционированное изменение или удаление.
– Создание рабочего процесса (workflow). Например, информирование или запрос утверждения уполномоченного сотрудника или владельца анализируемых объектов перед их переносом или удалением.
– Безопасный перенос в систему управления корпоративными записями HP Records Manager (например, в случае выявления несанкционированного присутствия конфиденциальных документов на общедоступном файловом сервере). При этом переносимые данные сопровождаются метаданными, которые будут использованы для дальнейшего управления документами в системе HP Records Manager с необходимыми настройками доступа, уровнями секретности и т.п.
Заключение
Как видно из текущего обзора, спектр применения HP Storage Optimizer и HP Control Point для решения задач анализа и управления корпоративными данными весьма широк. Кроме того, возможности анализа документов на разных языках (включая русский), а также масштабируемая архитектура компонентов обоих продуктов позволяет эффективно решать задачи по анализу всего объёма неструктурированных данных в организациях любого масштаба и сложности.
Автор статьи – Максим Луганский, технический консультант, Data Protection & Archiving, HP Big Data
Как работает rollback в базах данных
Всем привет, меня зовут Артём и я алкоголик долгое время не понимал базы данных. Ну, то есть я понимал концепт и как с ними работать, но всегда воспринимал их как чёрный ящик с понятным интерфейсом, который может сохранять и отдавать данные, если знать, как его об этом попросить. Механизмы, позволяющие магии случаться, были совершенно не понятны. И честно говоря, меня это особо не волновало. Бизнесу нужно, чтобы ты фичи фигачил, а не вот это вот всё.
Однако недавно я понял, что хватит это терпеть и настало время разобраться что происходит под капотом, как это происходит и зачем. Статья подойдёт тем, кто каждый день работает с базами данных и не особо вникает в подробности, людям, кто как и я заинтересовался тем, как всё работает и не знает откуда начать копать или просто тем, кто хочет немного освежить своё понимание баз данных.
Всё началось с того, что я задался вопросом, а как чёрт подери работает rollback, когда в результате работы моего воспалённого сознания получается такой код, который генерирует в базу кривые запросы и она вынуждена что-то делать, чтобы всё окончательно не сломалось? Прежде чем начинать копать в сторону механизма отката изменений, нужно понять что это вообще такое и зачем вообще оно нужно. И тут в игру вступает такая волшебная аббривиатура как ACID.
Так что же значит ACID? ACID это набор характеристик, которым должна соответствовать наша программа, чтобы считаться кошерным местом для хранения данных. Попробую в двух словах рассказать о каждой букве в аббривиатуре (ведь это не про кислоту в берлинских клубах):
A значит Atomicity — транзакция работает как единая команда и либо выполняется целиком, либо не выполняется вообще
С значит Consistency — по завершению транзакции данные не должны быть испорчены (такая противная штука как data corruption) или потеряны
I значит Isolation — по сути означает, что транзакции не должны пересекаться друг с другом. То есть если одна транзакция уже начала работу с данными, то следующая транзакция должна дождаться завершения предыдущей для того, чтобы начать выполнение операций с этими данными
D значит Durability — гарантия того, что по завершению транзакции данные будут сохранены и не подвержены риску потери. Тут нужно понимать, что это не только про программные ошибки, но и про потопы, цунами, отключения электричества и прочие ЧП
Однако тут стоит отметить, что не каждая база данных обладает всеми свойствами ACID и часто это осознанный выбор (а бывает и нет), направленный в сторону того, чтобы пожертвовать одними свойствами системы ради других.
Если сильно упростить, то при проектировании хранилища мы должны балансировать между скоростью и надёжностью.
Если мы хотим пойти по пути высокой скорости, то нам нужно хранить наши данные в как можно более быстром хранилище. Конечно, самым быстрым было бы хранить данные прямо в L1 кэше процессора, но объём хранилища не позволит нам развернуться. Следующее, что приходит на ум это RAM. Хранилище данных в оперативке несомненно даёт нам хорошую скорость, но о надёжности можно забыть, ведь любой скачок напряжения в датацентре будет означать неминуемую потерю данных. Примером такой базы данных может послужить какой-нибудь memcached.
Если же мы хотим получить высокую надёжность и нам не нужен частый и быстрый доступ к данным, то имеет смысл записывать все данные прямо на ssd или на hdd для хардкорных парней со специфическими задачами, например для хранения логов и редко запрашиваемой аналитики. Однако в таком случае придётся пожертвовать скоростью (что кстати может измениться с приходом быстрых nvm накопителей).
Популярные реляционные решения вроде Postgres и MySql используют гибридную схему, когда данные записываются на жёсткий диск, но также имеют слой, отвечающий за работы с кешированными в памяти данными для быстрого чтения. В этой статье мы будем говорить именно про этот тип хранилищ. Но прежде чем начинать лезть в гущи технической реализации, давайте с начала обозначим проблему.
Скажем, у нас есть заказчик Петя и фрилансер по имени Вася. Вася сделал Пете крутой лендос (одностраничный сайт) на тильде (конструктор сайтов) и ожидает, что Петя зашлёт ему за это денег. Петя не против и делает перевод через мобильный банкинг. Чтобы никто не присел нам нужно правильно выполнить несколько действий, а именно:
Найти таблицу с балансом Пети
Списать необходимую сумму с его баланса
Найти аккаунт Васи
Зачислить списанную у Пети сумму на счет Васи
Предположим, что первые два шага прошли хорошо. Однако потом выясняется, что Петя не правильно вбил реквизиты и мы не можем найти аккаунт Васи у нас в системе. Теперь мы имеем ситуацию, когда Петя стал беднее, а Вася богаче не стал. Тем самым мы нарушили правило консистентности, ведь данные испорчены. Это не очень крутая ситуация, ведь деньги не должны просто брать и исчезать.
Чтобы ответить на этот вопрос, нам нужно понять, что вообще представляет собой база данных и как она хранит записи. Тут нет единого ответа, ибо кто во что горазд, но если постараться обобщить, то база данных эта программа (ага, кто бы мог подумать) которая состоит из нескольких слоёв:
Transport layer — отвечает за общение базы с внешним миром (нашим замечательным сервером) и также за общение нод в кластере между собой (в случае если мы, скажем, применяем шардинг)
Query processor — ответственен за то, чтобы принять запрос, распарсить его, оптимизировать и превратить в список операций (execution plan), которые должны быть выполнены базой для успешного завершения транзакции
Execution engine — делает запрос на выполнение операций и агрегирует результаты
Storage engine — отвечает за исполнение операций
Ок, с этим этим разобрались, но теперь нам нужно погружаться ещё глубже в кроличью нору.
Дело в том, что storage engine тоже не так прост и состоит из нескольких частей, каждая из которых отвечает за то, чтобы наша база соответствовала злополучному ACID. Тут тоже нет единого консенсуса, но чаще всего выделяют следующие слои:
Transaction Manager — отвечает за очередь транзакций и проверяет, что транзакция полностью завершилась перед тем, как покинуть очередь. Отвечает за букву A и D.
Lock Manager — блокирует объекты, которые участвуют в транзакции. Отвечает за букву I
Storage Structures — отвечает за доступ и организацию данных в хранилище. Не отвечает ни за какие буковки, но без него никуда
Buffer Manager — кэширует данные в памяти. Мы ведь хотим, чтобы наша база работала быстро, правда?
Recovery Manager — отвечает за то, чтобы откатить данные к исходному состоянию в случае, если что-то пошло не так.
Вот оно! Recovery Manager и есть та волшебная штука, которая может нам помочь сделать rollback и вернуть Пете его честно заработанные деньги, а нам избежать исков в суды и жалоб в тысячи всевозможных инстанций.
Теперь давайте вернёмся к сценарию, когда нам нужно провести несколько операций в рамках одной транзакции для того, чтобы Петя заплатил Васе за красивый лендинг. Для модификации хранилища используется семейство паттернов под названием write-ahead logging (WAL). В оперативной памяти создаётся специальный лог файл, в который вносится информация о том, в каких таблицах нужно изменить записи в рамках операции, а также старые и обновленные значения полей. Затем обновлённый лог файл сохраняется на диск. После чего следует изменение записей в таблицах с данными, хранимых в памяти. После чего измененные значения таблиц сохраняются на диск. Тут важно понимать, что цепочка событий отрабатывает не на уровне всей транзакции, а на уровне отдельных операций, которые сохраняются на диск с определённой периодичностью (fsync() kernel call).
Но чтоже происходит, если операция не успешна и по какой-то причине нам нужно откатить изменения и вернуть нашу базу в исходное состояние?
Для восстановления исходного состояния используется семейство алгоритмов под названием ARIES (Algorithms for Recovery and Isolation Exploiting Semantics).
Логику алгоритма можно описать следующими шагами:
Analysis — стадия анализа и выявления таблиц, которые были модифицированы в ходе транзакции, а также анализ операций проведённых в пределах транзакции и их состояния (чекаем где сломалось).
REDO — на этом этапе мы уже точно знаем где транзакция сломалась и в какие таблицы были внесены изменения. Однако пока не можем гарантировать, что наше хранилище находится в консистентном состоянии, так как не понимаем, какие данные уже были сохранены на диск, а какие нет. Так как ребята, которые писали ARIES, были большими любителями простоты, они решили не заморачиваться, а просто ещё раз пройтись по всем операциям необходимым для транзакции, с самого начала и до момента ошибки. И применить их ещё раз с сохранением на жёсткий диск. Это необходимо для того, чтобы гарантировать консистентность нашего хранилища и исключить возможность порчи данных.
UNDO — тут всё просто. На последнем этапе мы делаем очередной проход по лог файлу и перезаписываем значения в изменённых таблицах. Но в отличие от предыдущего этапа на этот раз мы сохраняем значения таблицы, которые были в ней до того, как мы начали выполнение транзакции. Как результат, хранилище возвращается к изначальному состоянию и все счастливы.
После этого transaction manager сообщает нашему клиенту (в нашем случае это наш сервер) о том, что транзакция не прошла и всё, что нам остаётся сделать, это показать Пете сообщение о том, что перевод не случился и ему следует перепроверить реквизиты и попытаться ещё раз.
На этом всё. Надеюсь, данная статья помогла вам немного лучше понять, что происходит под капотом в популярных базах данных, что такое принципы ACID и как они поддерживаются и какие шаги предпринимаются хранилищем для следования этим принципам. Книги на почитать, если вдруг захотите копнуть глубже: