Настал момент очередного сохранения знаний. На этот раз небольшой кусочек годной инфы о том как работает няка PostgreSQL, да и наверное многие другие ACID базы данных (те, которые надежные, если по-пацански), к которым конечно же не принадлежит MongoDB.
PostgreSQL использует WAL (Write-Ahead Logging). Суть WAL такова. При изменении данных в базе файлы, содержащие данные, не меняются на лету. Вместо этого изменения сперва логгируются в отдельные WAL-файлы, то есть в WAL-файлах сохраняется полное описание производимых изменений. Полное описание означает, что если с самого начала жизни БД изменения вообще не отражать в БД, а только логировать WAL-файлами, то в любой момент можно будет скормить эти WAL-файлы базе и получить в итоге то же состояние БД, как если бы мы отражали изменения в БД сразу.
Благодаря этой технологии нам не обязательно сразу сбрасывать произведенные изменения на файлы данных по окончании каждой транзакции. Даже если база навернется мы сможем восстановить изменения по WAL-файлам. Это дает определенные преимущества при работе с файлами. Во-первых можно одним махом сбрасывать сразу несколько изменений на файлы данных, во-вторых запись WAL-файлов последовательная, а изменения в базе во многих случаях предполагают random access на диске. Так что вместо того, чтобы постоянно дергаться в разные места на диске наша база сперва собирает определенный объем изменений и только потом начинает его выполнять.
Часто с помощью WAL организуют онлайн backup - архивируют все WAL логи. Благодаря этому можно восстановить базу на любой момент времени.
Как часто в PG происходит синхронизация изменений на файлы данных? Точки в последовательности транзакций когда происходит такая синхронизация называются Checkpoint-ами. После синхронизации соответствующие WAL-файлы могут быть удалены. Чекпоинты определяются двумя настройками постгреса: checkpoint_segments и checkpoint_timeout. Первый определяет максимальное число сегментов WAL-файла, по достижении которого нужно производить синхронизацию, второй - максимальное число секунд. по прошествии которых нужно синхронизировать. Что первее происходит, то и генерит чекпоинт. По дефолту это 3 сегмента (48 мегов) WAL-логов и 300 сек соответственно.
Папка с WAL-файлами в постгресе зовется pg_xlog. И для лучшей производительности при обильных записях ее помещают на отдельный диск. Это позволяет избавиться от прыганий головки диска - от данных к WAL-файлам и обратно.
Как правило в папке не более чем (2 + checkpoint_completion_target) * checkpoint_segments + 1 файлов (каждый из которых по умолчанию 16 мегов). checkpoint_completion_target - значение от 0 до 1 для балансировки нагрузки при синхронизации изменений. По умолчанию 0.5 - означает, что в среднем синхронизация изменений будет заканчивать на половине времени до начала следующей синхронизации. Указанный порог файлов в pg_xlog может быть превышен в случае длительных транзакций.
Информация указана для PostgreSQL 9.0
PostgreSQL использует WAL (Write-Ahead Logging). Суть WAL такова. При изменении данных в базе файлы, содержащие данные, не меняются на лету. Вместо этого изменения сперва логгируются в отдельные WAL-файлы, то есть в WAL-файлах сохраняется полное описание производимых изменений. Полное описание означает, что если с самого начала жизни БД изменения вообще не отражать в БД, а только логировать WAL-файлами, то в любой момент можно будет скормить эти WAL-файлы базе и получить в итоге то же состояние БД, как если бы мы отражали изменения в БД сразу.
Благодаря этой технологии нам не обязательно сразу сбрасывать произведенные изменения на файлы данных по окончании каждой транзакции. Даже если база навернется мы сможем восстановить изменения по WAL-файлам. Это дает определенные преимущества при работе с файлами. Во-первых можно одним махом сбрасывать сразу несколько изменений на файлы данных, во-вторых запись WAL-файлов последовательная, а изменения в базе во многих случаях предполагают random access на диске. Так что вместо того, чтобы постоянно дергаться в разные места на диске наша база сперва собирает определенный объем изменений и только потом начинает его выполнять.
Часто с помощью WAL организуют онлайн backup - архивируют все WAL логи. Благодаря этому можно восстановить базу на любой момент времени.
Как часто в PG происходит синхронизация изменений на файлы данных? Точки в последовательности транзакций когда происходит такая синхронизация называются Checkpoint-ами. После синхронизации соответствующие WAL-файлы могут быть удалены. Чекпоинты определяются двумя настройками постгреса: checkpoint_segments и checkpoint_timeout. Первый определяет максимальное число сегментов WAL-файла, по достижении которого нужно производить синхронизацию, второй - максимальное число секунд. по прошествии которых нужно синхронизировать. Что первее происходит, то и генерит чекпоинт. По дефолту это 3 сегмента (48 мегов) WAL-логов и 300 сек соответственно.
Папка с WAL-файлами в постгресе зовется pg_xlog. И для лучшей производительности при обильных записях ее помещают на отдельный диск. Это позволяет избавиться от прыганий головки диска - от данных к WAL-файлам и обратно.
Как правило в папке не более чем (2 + checkpoint_completion_target) * checkpoint_segments + 1 файлов (каждый из которых по умолчанию 16 мегов). checkpoint_completion_target - значение от 0 до 1 для балансировки нагрузки при синхронизации изменений. По умолчанию 0.5 - означает, что в среднем синхронизация изменений будет заканчивать на половине времени до начала следующей синхронизации. Указанный порог файлов в pg_xlog может быть превышен в случае длительных транзакций.
Информация указана для PostgreSQL 9.0
Комментариев нет:
Отправить комментарий