Почему базы данных SQL используют журнал записи с опережением по журналу команд?
Я читал о журнале команд Voltdb. Журнал команд записывает вызовы транзакций вместо каждого изменения строки, как в журнале с опережением записи. Записывая только вызов, журналы команд сводятся к минимуму, что ограничивает влияние дискового ввода-вывода на производительность.
Может кто-нибудь объяснить теорию баз данных, почему Voltdb использует журнал команд и почему стандартные базы данных SQL, такие как Postgres, MySQL, SQLServer, Oracle, используют журнал опережающей записи?
5 ответов
Я думаю, что лучше перефразировать:
Почему новый распределенный VoltDB использует журнал команд поверх журнала с опережением записи?
Давайте проведем эксперимент и представим, что вы собираетесь написать собственную реализацию хранилища / базы данных. Несомненно, вы достаточно продвинуты, чтобы абстрагировать файловую систему и использовать блочное хранилище вместе с некоторыми дополнительными оптимизациями.
Некоторая базовая терминология:
- Состояние: сохраненная информация в данный момент времени
- Команда: директива для хранилища, чтобы изменить его состояние
Таким образом, ваша база данных может выглядеть следующим образом:
Следующим шагом является выполнение некоторой команды:
Обратите внимание на несколько важных аспектов:
- Команда может повлиять на многие сохраненные объекты, поэтому многие блоки будут испачканы
- Следующее состояние является функцией текущего состояния и команды
Некоторые промежуточные состояния можно пропустить, потому что вместо этого достаточно иметь цепочку команд.
Наконец, вам нужно гарантировать целостность данных.
- Журналирование с записью впереди - центральная концепция заключается в том, что изменения состояния должны регистрироваться перед любым серьезным обновлением постоянного хранилища. Следуя нашей идее, мы можем регистрировать пошаговые изменения для каждого блока.
- Ведение журнала команд - основная концепция состоит в том, чтобы регистрировать только команду, которая используется для создания состояния.
Есть плюсы и минусы для обоих подходов. Журнал записи впереди содержит все измененные данные. Журнал команд потребует дополнительной обработки, но быстрый и легкий.
VoltDB: регистрация команд и восстановление
Ключом к ведению журнала команд является то, что он регистрирует вызовы, а не последствия транзакций. Записывая только вызов, журналы команд сводятся к минимуму, что ограничивает влияние дискового ввода-вывода на производительность.
Дополнительные примечания
Традиционный журнал отката работает, записывая копию исходного неизмененного содержимого базы данных в отдельный файл журнала отката, а затем записывая изменения непосредственно в файл базы данных.
COMMIT происходит, когда к WAL добавляется специальная запись, указывающая на фиксацию. Таким образом, COMMIT может происходить без какой-либо записи в исходную базу данных, что позволяет читателям продолжать работу с исходной неизмененной базы данных, пока изменения одновременно вносятся в WAL.
PostgreSQL: ведение журнала записи (WAL)
Использование WAL приводит к значительному сокращению количества операций записи на диск, поскольку для сохранения транзакции требуется только файл журнала, а не каждый файл данных, измененный транзакцией.
Файл журнала записывается последовательно, поэтому стоимость синхронизации журнала намного меньше, чем стоимость очистки страниц данных. Это особенно верно для серверов, обрабатывающих множество небольших транзакций, затрагивающих различные части хранилища данных. Кроме того, когда сервер обрабатывает много небольших параллельных транзакций, одной фиксации файла журнала может быть достаточно для фиксации многих транзакций.
Заключение
Регистрация команд:
- быстрее
- имеет более низкую площадь
- имеет более тяжелую процедуру "Replay"
- требуется частый снимок
Write Ahead Logging - это метод обеспечения атомарности. Лучшая производительность ведения журнала команд также должна улучшить обработку транзакций. Базы данных на 1 фут
подтверждение
Блог VoltDB: введение в ведение журнала команд VoltDB
Одно из преимуществ журналирования команд по сравнению с журналированием в стиле ARIES состоит в том, что транзакция может регистрироваться до начала выполнения, а не выполнять транзакцию и ждать, пока данные журнала не будут сброшены на диск. Другое преимущество состоит в том, что пропускная способность ввода-вывода, необходимая для журнала команд, ограничена сетью, используемой для ретрансляции команд, и, в случае Gig-E, эта пропускная способность может быть удовлетворена дешевыми стандартными дисками.
Важно помнить, что VoltDB распространяется по своей природе. Таким образом, транзакции немного сложны в обращении, и влияние на производительность заметно.
Блог VoltDB: новая функция регистрации команд VoltDB
Журнал команд в VoltDB состоит из вызовов хранимых процедур и их параметров. Журнал создается на каждом узле, и каждый журнал реплицируется, потому что вся работа реплицируется на несколько узлов. Это приводит к репликации журнала команд, который может быть дублирован во время воспроизведения. Поскольку транзакции VoltDB строго упорядочены, журнал команд также содержит информацию об упорядочении. Таким образом, воспроизведение может происходить в точном порядке, в котором выполнялись исходные транзакции, с полной изоляцией транзакций, предлагаемой VoltDB. Поскольку сами вызовы часто меньше, чем измененные данные, и их можно зарегистрировать до того, как они будут зафиксированы, этот подход очень скромно влияет на производительность. Это означает, что пользователи VoltDB могут достичь тех же показателей производительности стратосферы с дополнительными гарантиями долговечности.
С WAL читатели читают со страниц из непроверенных журналов. В основную БД не вносятся изменения. При ведении журнала команд у вас нет возможности читать из журнала команд.
Поэтому ведение журнала команд сильно отличается. VoltDB использует ведение журнала команд для создания точек восстановления и, конечно же, обеспечения долговечности, но записывает данные в основное хранилище БД (ОЗУ) в режиме реального времени со всеми сопутствующими проблемами блокировки и т. Д.
Из описания записи в Postgres http://www.postgresql.org/docs/9.1/static/wal-intro.html и журнала команд VoltDB (на который вы ссылались) я не вижу большой разницы вообще. Похоже, это идентичная концепция с другим именем.
Оба синхронизируют на диске только файл журнала, но не данные, чтобы можно было восстановить данные путем воспроизведения файла журнала.
В разделе 10.4 VoltDB объясняется, что в их версии сообщества нет журнала команд, поэтому он не пройдет тест ACID. Даже в корпоративной версии я не вижу подробностей об их изоляции транзакций (например, http://www.postgresql.org/docs/9.1/static/transaction-iso.html), необходимых для того, чтобы мне было удобно, что VoltDB Серьезно, как Postges.
Это действительно просто вопрос гранулярности. Они регистрируют операции на уровне хранимых процедур, большинство СУБД регистрируют на уровне отдельных операторов (и "ниже"). Также их реклама о преимуществах - это немного красной сельди:
Одно из преимуществ журналирования команд по сравнению с журналированием в стиле ARIES состоит в том, что транзакция может регистрироваться до начала выполнения, а не выполнять транзакцию и ждать, пока данные журнала не будут сброшены на диск.
Они должны ждать, пока команда будет записана, это просто намного меньшая запись.
Если я не ошибаюсь, единица транзакции VoltDB - это сохраненный процесс. Традиционные СУБД обычно должны поддерживать специальные транзакции, содержащие любое количество операторов, поэтому ведение журнала на уровне процедур не может быть и речи. Кроме того, хранимые процедуры часто не являются по-настоящему детерминированными в традиционных СУБД (т. Е. Данные параметры +log+ данные всегда дают один и тот же вывод), которым они должны были бы быть, чтобы это работало.
Тем не менее, повышение производительности будет существенным для этой модели СУБД с ограничениями.
То, как я это читаю, таково: (Мое собственное мнение)
Ведение журнала команд, как описано здесь, регистрирует только транзакции по мере их возникновения, а не то, что происходит в них или с ними. Итак, вот волшебная часть... Если вы хотите откатить, вам нужно восстановить последний снимок, а затем вы можете воспроизвести все транзакции, которые были применены после этого (описано в ссылке выше). Таким образом, вы эффективно восстанавливаете резервную копию и повторно применяете все свои сценарии, только VoltDB теперь автоматизировал ее для вас.
Реальная разница, которую я вижу в этом, заключается в том, что вы не можете выполнить откат к моменту времени логически, как с обычным журналом транзакций. Обычные журналы транзакций (MSSQL, MySQL и т. Д.) Могут легко откатиться к моменту времени (при правильной настройке), поскольку транзакции могут быть "обращены".
Возникает интересный вопрос - ссылаясь на pos от pedz, он всегда будет проходить тест ACID, даже с журналом команд? Буду еще читать...
Add: Больше читал, и я не думаю, что это хорошая идея для очень больших и загруженных транзакционных баз данных. Снимок БД автоматически создается при заполнении журналов команд, чтобы спасти вас от больших журналов транзакций и ввода-вывода, использованных для этого? Вы будете подвергаться большим объемам ввода-вывода с вашими снимками, сделанными через регулярные промежутки времени, и вы также используете свою память на грани. Алос, на мой взгляд, вы теряете способность легко откатываться до момента времени, предшествующего последнему автоматическому снимку - думаю, с этим будет очень сложно справиться.
Я скорее буду придерживаться журналов транзакций для транзакционных систем. Это доказано, и это работает.
Несколько терминов, прежде чем я начну объяснять:
Схемы ведения журнала: база данных использует схемы ведения журнала, такие как теневое разбиение на страницы, предварительная запись журнала (WAL), для реализации параллелизма, изоляции и устойчивости (как это другой раздел).
Чтобы понять, почему WAL лучше, давайте рассмотрим проблему с теневым разбиением на страницы. При теневом разбиении на страницы база данных использует основную версию и теневую версию базы данных, поэтому, если размер таблицы составляет 1 миллиард, а диспетчер пула буферов не имеет достаточно памяти для хранения всех кортежей (записей) в памяти, грязные страницы не записываются в главную версию до тех пор, пока транзакция (транзакции) не будет зафиксирована.
Когда все транзакции зафиксированы, флаг переключается, и теневая версия становится основной. На диаграмме выше есть
Page 3 and Page 5 старые и могут быть собраны мусором.
Проблема с этим подходом заключается в большом количестве оставленных фрагментированных кортежей, которые располагаются случайным образом, это медленнее по сравнению с последовательным доступом к грязным страницам, и это то, что делает Write Ahead Log.
Другим преимуществом использования WAL является производительность во время выполнения (поскольку вы не выполняете случайный ввод-вывод для очистки страниц), но более медленное время восстановления. В то время как при теневом разбиении на страницы производительность восстановления выше (что иногда требуется).