Избыточность данных и её оптимизация

Published by Leave your thoughts

Эта статья расскажет о том, что такое избыточность базы данных, и как использовать её для повышения производительности.

Избыточность 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: , , ,

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *


*

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>