Избыточность данных и её оптимизация
Эта статья расскажет о том, что такое избыточность базы данных, и как использовать её для повышения производительности.
Избыточность RAID-массива
Избыточность RAID-массива – пожалуй, самый распространённый вид избыточности. RAID расшифровывается как «redundant array of independent disks» (избыточный массив независимых дисков), это значит, что в большинстве конфигураций диски так или иначе зеркалируют друг друга.
Зеркальный массив RAID 1 – базовая реализация избыточности RAID. Он состоит из нескольких (как правило, двух) дисков, которые полностью копируют друг друга. Если один из дисков выходит из строя, вся поддержка, обслуживание и запись данных выполняется вторым диском. Такой массив позволяет ускорить операции чтения, поскольку система может читать данные с любого диска.
В принципе, этот пример относится ко всем RAID-массивам. Теперь особенно хорошо заметно различие между RAID и резервными копиями: любое изменение диска применяется ко всем дискам сразу; то есть, если файл был удалён с одного диска, его сразу не станет и на втором.
Блочная избыточность
Следующий вид избыточности – зеркалирование целых блочных структур. Для этого используется DRBD (distributed replicated block device).
Этот метод чем-то похож на избыточность массивов RAID. Разница заключается в том, где происходит репликация. В RAID-массива, избыточность происходит на уровне приложения. Программное обеспечение RAID управляет физическими устройствами хранения и предоставляет данные приложения с одного из доступных устройств.
Настройки DRBD совсем другие. При этом полностью зеркалируется каждый аппаратный стек, а также каждый интерфейс приложения. Это означает, что так можно исправить отказ приложения, потому что, по сути, есть ещё одна отдельная машина с копией данных, необходимых для работы. Если у первого сервера выходит из строя блок питания, второй сервер будет по-прежнему эффективно работать.
Репликация SQL
При работе с базами данных SQL (MySQL, MariaDB, PostgreSQL и т.п.) можно использовать их встроенные функции репликации, чтобы обеспечить отказоустойчивость в случае сбоя основного сервера.
Репликация по типу Master-Slave
Это, пожалуй, самый базовый вид репликации данных SQL. В такой настройке есть один главный сервер, который называется ведущим, или master-сервером. Этот сервер отвечает за все операции записи и обновления данных. Затем данные с этого сервера копируются на ведомый сервер (или slave-сервер).
Эта настройка позволяет распределить операции чтения между несколькими машинами, что может значительно улучшить производительность приложения.
Конечно, увеличение производительности является важным преимуществом; однако не менее важно то, что такая репликация повышает отказоустойчивость. Если master-сервер по какой-либо причине недоступен, операции чтения могут выполняться на серверах slave. Более того, slave-сервер можно перенастроить в master-сервер в случае, если предыдущий master недоступен в течение длительного периода.
Именно на примере репликации master-slave можно увидеть, как репликация данных и резервное копирование могут дополнять друг друга. При такой настройке можно реплицировать данные от ведущего сервера к ведомому. Затем можно временно отключить репликацию, чтобы сохранить данные на slave-сервере в согласованном состоянии, и создать резервную копию базы данных при помощи любого удобного механизма
Примечание: Подробнее о настройке репликации данных по типу master-slave можно прочесть в руководствах:
Репликация по типу master-master
В такой настройке репликации каждый сервер является ведущим, то есть master. Это значит, что каждый сервер может принимать и обновлять данные, после чего изменения будут распространены на остальные серверы. Такая репликация имеет те же преимущества, что и master-slave, и, кроме того, позволяет увеличить производительность с помощью механизма балансировки нагрузки.
Таким образом, если один сервер выходит из строя, то другой может еще и принимать запросы. Конечно, такая конфигурация сложнее, зато она гораздо отказоустойчивее, ведь в случае сбоя не нужно перенастраивать серверы (как при репликации master-slave).
Эту настройку можно совместить с механизмами резервного копирования; для этого нужно отключить один из master-серверов, поскольку во время резервного копирования данные должны находиться в согласованном состоянии. После завершения резервного копирования можно возобновить репликацию.
Примечание: Подробнее о настройке репликации master-master можно прочесть здесь.
Распределение как альтернатива избыточности
Распределенные системы обладают многими преимуществами традиционных настроек избыточности.
Ранее в данном руководстве упоминались RAID-массивы, в частности RAID 1. Ещё один распространённый массив – это RAID 5. Он распределяет данные между несколькими накопителями, а также ведёт контроль по чётности. Информация о чётности хранится на отдельном контрольном диске. Это означает, что в случае отказа одного из дисков любая транзакция может быть восстановлена путём объединения информации о четности на других дисках.
Также существует немало баз данных и других программных решений, предназначенных для распределения данных.
В качестве примера можно привести Riak; это распределенная база данных. Ноды Riak работают точно так же. Между ними нет отношений типа ведущий-ведомый. Объекты, хранящиеся в базе данных, реплицируются.
Однако ноды при этом не содержат полной БД, данные равномерно распределяются между ними. Объекты после репликации размещаются на разных нодах, чтобы обеспечить доступ к данным в случае аппаратных сбоев.
Другим хорошим примером этого подхода является распределённая БД Cassandra. Она основана на тех же принципах, что и Riak, но реализована немного иначе.
Примечание: В следующих статьях можно найти дополнительную информацию по распределённым БД:
Заключение
Как видите, существует множество возможностей для оптимизации работы сервера при помощи избыточности данных. в основном, подход зависит от проблем, которые нужно устранить или предупредить. Кроме того, эти техники можно комбинировать.
Также это руководство хорошо иллюстрирует, что избыточность не заменяет резервное копирование, и наоборот. Избыточные системы всегда в работе и всегда зеркалируют изменения, а это может привести к полной потере данных.
Приложениям, в которых доступ и целостность данных имеют большое значение, необходимо и резервное копирование, и настройка избыточности. Надлежащая реализация этих механизмов гарантирует высокую производительность и надёжную защиту данных.
Tags: MySQL, PostgreSQL, RAID, SQL