Библиотека сайта rus-linux.net
Экосистема NoSQL
Глава 13 из книги "Архитектура приложений с открытым исходным кодом", том 1.
Оригинал: The NoSQL Ecosystem
Автор: Adam Marcus
Перевод: А.Панин
13.3. Долговечность хранения данных
В идеальном случае модификации данных в системе для их хранения должны быть незамедлительно сохранены и скопированы на множество узлов для предотвращения потерь данных. Однако, поддержка механизмов безопасного хранения данных противоречит высокой производительности, поэтому различные системы NoSQL предоставляют различные гарантии в отношении долговечности хранения данных для повышения производительности. Сценарии неполадок достаточно многочисленны и значительно отличаются друг от друга, при этом не все системы NoSQL в состоянии защитить вас от них.
Простым и часто встречающимся сценарием неполадки является перезагрузка сервера или отключение энергоснабжения. Долговечность хранения данных в такой ситуации зависит от того, скопированы ли данные из оперативной памяти на жесткий диск, которому не требуется питания для их хранения. На случай отказа жесткого диска данные копируются на сторонние устройства, которые могут быть другими жесткими дисками этой же машины (зеркалирование RAID) или другими машинами в сети. Однако, датацентр может не пережить ситуации, которая приводит к различным неполадкам (например, торнадо), поэтому некоторые организации доходят до того, что копируют данные на серверы датацентров, находящихся на расстоянии нескольких фронтов ураганов. Запись данных на жесткие диски и копирование данных на множество локальных серверов или серверов в удаленных датацентрах обходятся достаточно дорого, поэтому различные системы NoSQL меняют гарантии долговечности хранения данных на возможность повышения производительности.
13.3.1. Долговечность хранения данных на отдельном сервере
Простейшей технологией длительного хранения данных является технология длительного хранения данных на отдельном сервере, которая позволяет быть уверенным в том, что любые модификации данных будут доступны после перезагрузки сервера или отключения энергоснабжения. Обычно эта технология предполагает запись измененных данных на диск, что является слабым местом при работе под нагрузкой. Даже если вы используете функцию вашей операционной системы для записи данных в файл на диске, операционная система может добавить данные в буфер, избегая незамедлительной модификации файла на диске таким образом, что несколько операций записи могут быть сгруппированы в одну. Только осуществление системного вызова fsync заставит операционную систему предпринять попытку записи и удостовериться в том, что буферизованные данные модификаций находятся на диске.
Стандартные жесткие диски могут выполнить 100-200 операций случайного доступа (переходов) в секунду и ограничены скоростью последовательной записи, равной 30-100 МБ/с. Операции в оперативной памяти могут быть на порядки быстрее в обоих случаях. Эффективная технология длительного хранения данных подразумевает ограничение количества случайных операций записи, осуществляемых в вашей системе, и повышение количества последовательных операций записи на жесткий диск. В идеальном случае вы пожелаете добиться от системы минимизации количества операций записи между вызовами fsync, а также максимизации количества последовательных записей, и предпочтете никогда не сообщать пользователю о том, что его данные были успешно записаны на диск до момента осуществления записи с помощью вызова fsync. Давайте рассмотрим несколько техник повышения производительности операций, необходимых для реализации гарантий длительного хранения данных на отдельном сервере.
Система Memcached14 является примером системы, не предоставляющей гарантий длительного хранения данных, при этом использующей возможность осуществления чрезвычайно быстрых операций в пределах оперативной памяти. При перезагрузке сервера данные на этом сервере пропадают: это подходит для кэширования, но не подходит для длительного хранения данных.
Система Redis предоставляет разработчикам возможность изменения параметров использования системного вызова fsync. Разработчики могут установить принудительный вызов fsync после каждой операции записи, что является медленным и безопасным решением. Для лучшей производительности система Redis может вызывать fsync через каждые N секунд. При самом плохом сценарии вы потеряете данные, записанные в ходе осуществления операций в течение последних N секунд, что может быть допустимо для определенных случаев использования системы. Наконец, для случаев использования системы, в которых долговечность хранения данных не важна (сбор неточной статистики или использование системы Redis для кэширования) разработчик может полностью отключить использование системного вызова fsync: операционная система в конечном счете все равно запишет данные на диск, но невозможно гарантировать то, что данные будут записаны в определенный момент.
Некоторые структуры данных, такие, как бинарные деревья (B+Trees) позволяют системам NoSQL быстро извлекать данные с диска. Обновления этих структур приводят к обновлению случайных участков файлов, хранящих структуры данных, что в итоге приводит к нескольким случайным записям при обновлении данных в случае использования вызова fsync после каждого обновления. Для снижения количества случайных записей такие системы, как Cassandra, Hbase, Redis и Riak добавляют данные операций обновления в последовательно записываемый файл, называемый журналом. В то время, как при записи других используемых системой структур данных вызов fsync используется периодически, при записи данных в журнал вызов fsync используется постоянно. Рассматривая журнал как отправную точку для восстановления состояния базы данных после краха, эти хранилища способны превращать случайные обновления данных в последовательные.
Хотя такие системы NoSQL, как MongoDB и выполняют непосредственную запись структур данных, другие системы еще больше развивают идею использования журнала. Системы Cassandra и HBase используют заимствованную из системы BigTable технику объединения журнала и структур для поиска в рамках одного дерева слияния со структурой журнала (log-structured merge tree). Система Riak предоставляет аналогичные функции в рамках хэш-таблицы со структурой журнала (log-structured hash table). Система CouchDB использует модификацию традиционного бинарного дерева (B+Tree) так, что все изменения структуры данных добавляются к структуре на физическом устройстве хранения. С помощью этих техник удается достичь повышенной пропускной способности, но становится необходимым постоянное уплотнение данных журнала с целью предотвращения неконтролируемого роста его размера.
Повышение пропускной способности путем группировки операций записи
Система Cassandra группирует множество параллельных обновлений данных, выполненных в течение короткого промежутка времени, для единственного вызова fsync после их записи. Это архитектурное решение, называемое групповой записью (group commit) приводит к задержке при обновлении данных, так как пользователям приходится ждать выполнения нескольких параллельных обновлений данных для того, чтобы их обновление получило подтверждение. Повышение задержки позволяет повысить пропускную способность, так как множество записей в журнал может быть произведено с использованием единственного вызова fsync. Если рассматривать запись, то каждое обновление данных системой HBase производится с использованием низкоуровневого хранилища, предоставляемого распределенной файловой системой Hadoop (Hadoop Distributed File System - HDFS)15, для которой недавно были применены патчи, реализующие поддержку дополнения файлов с учетом использования вызова fsync и групповую запись.
13.3.2. Долговечность хранения данных на множестве серверов
Так как жесткие диски и компьютеры обычно после выхода из строя не подлежат восстановлению, копирование важных данных на сторонние компьютеры необходимо. Многие системы NoSQL предоставляют функции для хранения данных на множестве серверов.
Система Redis использует традиционный подход с ведущим и ведомыми серверами для копирования данных. Все операции, выполняемые с ведущим сервером, передаются в подобном журналу виде ведомым серверам, которые повторяют операции, используя свое собственное аппаратное обеспечение. Если ведущий сервер отказывает, ведомый сервер может начать работу, используя полученные от ведущего сервера данные состояния из журнала операций. Эта конфигурация может привести к потере некоторого объема данных, так как ведущий сервер не проверяет, записал ли данные в журнал ведомый сервер перед отправкой подтверждения выполнения операции пользователю. Система CouchDB использует упрощенный вариант аналогичной системы направленной репликации, в которой серверы могут быть настроены таким образом, что изменения документов будут копироваться в сторонние хранилища данных.
Система MongoDB предоставляет механизм наборов копий, в котором некоторое количество серверов ответственно за хранение каждого документа. MongoDB предоставляет разработчикам возможность проверять, обновляются ли все копии, или продолжать работу без проверки обновления всех копий с использованием новейших данных. Множество других распределенных хранилищ систем NoSQL поддерживает возможность копирования данных на множество серверов. Система HBase, основанная на HDFS, распределяет данные между серверами средствами файловой системы HDFS. Все операции записи повторяются двумя или большим количеством серверов HDFS перед возвращением управления пользователю, что позволяет быть уверенным в долговечности хранения данных на множестве серверов.
Системы Riak, Cassnadra и Voldemort поддерживают более настраиваемые формы репликации. При наличии небольших отличий, все три системы позволяют пользователю задать значение параметра N, определяющего количество машин, которые в конечном итоге должны хранить копию данных, а также параметр WN, который устанавливает количество машин, которые должны убеждаться в завершении записи перед возвращением управления пользователю.
Для преодоления ситуации, при которой весь датацентр прекращает работу, необходима возможность копирования данных на серверы других датацентров. Системы Cassandra, HBase и Voldemort поддерживают независимые от стоек (rack aware) конфигурации, позволяющие задавать стойку или датацентр, в которых расположены различные машины. В общем случае, блокировка действий пользователя до того момента, как удаленный сервер подтвердит факт обновления данных, приводит к появлению очень большой задержки. Данные для обновлений передаются без подтверждений при работе в сетях большого размера и сохранении резервных копий данных в отдельных датацентрах.
Продолжение статьи: 13.4. Масштабирование с целью повышения производительности.