Hypertable

Иван Блинков — Sat, 05 Apr 2008 20:27:00 +0400

Hypertable является еще одним opensource проектом, направленным на воспроизведение функционала BigTable от Google. Поставленная перед проектом цель заключается в реализации системы хранения данных на базе распределенной файловой системы, позволяющей перейти на новый уровень производительности при работе с гигантскими объемами данных.

Принцип работы Hypertable прост до безобразия:

Hypertable хранит данные в табличном формате, сортируя записи по основному ключу;
для хранимых данных не используются какие-либо типы данных, любая ячейка интерпретируется как байтовая строка;
масштабируемость достигается путем разбиения таблиц на смежные интервалы строк и хранения их на разных физических машинах;
в системе используется два типа серверов:

Master Server

– как и во многих других подобных системах мастер-сервер выполняет обязанности скорее административного характера: он управляет работой Range серверов, работает с метаданными (которые хранятся просто в отдельной таблице, наравне с остальными).

Range Server

– их задача стоит в собственно в хранении диапазонов строк из различных таблиц. Каждый сервер может хранить несколько несмежных диапазонов строк, если диапазон превышает по объему определенный лимит (по-умолчанию - 200 MB), то он разбивается на пополам и одна половина обычно перемещяется на другой сервер. Если же на одном из серверов подходит к концу дисковое пространство, то под руководством мастер-сервера часть диапазонов с него перераспределяется на менее загруженные Range серверы.
Еще одним компонентом системы является Hyperspace, этот сервер предоставляет указатель на основную таблицу с метаданными, а также пространство имен. Помимо этого этот сервис выступает в роли lock-механизма для клиентов системы.

В качестве основы для этой системы может использоваться как входящая в состав Hadoop файловая система HDFS, так и KosmosFS, о которой я недавно рассказывал. Это позволяет Hypertable выступать в роли конкурента для HBase в рамках проекта Hadoop.

HBase и Hypertable выполняют достаточно похожие функции и преследуют практически одни и те же цели, но есть некоторые ньюансы. Одним из глобальных различий в этих системах является языки программирования, с использованием которого они реализованы. HBase написана на Java, в то время как разработчики Hypertable предпочли C++. Это повлекло за собой массу различий в инкапсулированной реализации различных операций.

Для доступа к данным каждая из систем использует язык HQL, только в одном случае аббревиатура расшифровывается как HBase Query Language, а в другом - Hypertable Query Language (как эгоистично :) ). По сути и то и другое является сильно упрощенным диалектом SQL, что позволяет сократить знакомство с синтаксисом HQL до пары минут при достаточном знании классического SQL. Хотелось бы отметить, что вся простота в сравнении с классическим SQL и реляционными СУБД вполне обоснована: обе системы хранения данных предназначены для использования в совокупности с MapReduce программами, что делает их просто хранилищем данных, а не средством их обработки.

После небольшого лирического отступления в виде сравнения с HBase хотелось бы все же вернуться к теме нашего разговора, а именно к организации хранения данных в Hypertable. Данные хранятся в виде пар ключ:значение, причем храняться все версии строк с указанием времени, когда они были созданы. Таким образом легко проследить за процессом изменения данных во времени, а также узнать какие именно операции проводились над ними в прошлом. Стандартный механизм работы с версиями данных может быть переопределен на хранения лишь фиксированного количества версий строки, позволяя использовать удаление устаревших записей для освобождения дополнительного дискового пространства.

Для более эффективной работы с обновлением случайных ячеек таблиц используется кэширование. Поступающие данные собираются в оперативной памяти и при достижении определенного лимита сжимаются и записываются на диск.

Для более эффективной работы с распределенной файловой системой используется механизм под названием Access Groups. Суть заключается в объединении колонок таблиц в группы, в которых они чаще всего используется вместе. Такие группы данных по возможности храняться вместе на физических носителях. Если запрос включает в себя только данные из колонок одной группы доступа, то с дисков считывается только эти колонки, в противном случае приходиться работать со всей строкой целиком. Такой подход позволяет существенно оптимизировать работу операций ввода/вывода.

Проект еще находится в стадии разработки и до стабильного релиза ему еще далеко, но тем не менее он уже вполне может себя показать в качестве конкурента как для других систем подобного класса, так и для более стандартных реляционных баз данных. Основными недостающими моментами в этой системе в данной системе является отсутствие некоторого порой необходимого функционала в HQL, а такжы некоторые проблемы с отказоустойчивостью, вызванные единственностью в рамках системы Master и Hyperspace серверов.

Файлы в космосе

Иван Блинков — Sun, 30 Mar 2008 23:06:00 +0400

...или Kosmos Distributed File System

Сегодня речь пойдет об еще одной распределенной файловой системе - KosmosFS. У русских людей название этого проекта определенно вызывает ассоциации с космосом, но изначально все же свою лепту в него внес изначальный разработчик - Kosmix. По большому счету KFS мало чем выделяется из множества своих конкурентов, по своей структуре она состоит из сервера метаданных и серверов блоков, доступ к системе производится средствами клиентской библиотеки, предоставляющей соответствующий API. Список возможностей файловой системы также вполне стандартен:

Инкрементальная масштабируемость. При добавлении дополнительных узлов в кластер, система сама адаптируется для вовлечения их в полноценную работу.
Стабильный доступ. Реплицируемость данных (по-умолчанию в трех экземплярах) позволяет гарантировать доступность данных вне зависимости от сбоев в работе отдельных узлов.
Балансировка блоков данных. Периодически сервер метаданных перераспределяет данные с целью более оптимального использования дискового пространства.
Целостность данных. Для обеспечения целостности данных вычисляются и сравниваются контрольные суммы блоков данных.
Кэширование. Для увеличения производительности используется кэширования на уровне клиентской библиотеки.
Прозрачная работа с недоступными узлами. Клиентская библиотека прозрачно для приложения переключается на альтернативный сервер с данными, если обнаруживает что один из них недоступен.
Поддержка языков программирования: C++, Java, Python.
Скрипты. С системой предоставляется набор скриптов для развертывания, запуска и остановки узлов.

Но написать этот пост меня подтолкнул вовсе не этот список. В комментариях к одной из предыдущих моих записей читатели подняли тему о целесообразности использования Java для реализации HDFS в частности и Hadoop в целом. В качестве альтернативы был предложен C++ (только на словах конечно же), аргументируя это тем, что такая реализация была бы эффективнее. KFS же как раз и является той самой альтернативой HDFS, написанной на C++. KFS тесно интегрируется с Hadoop с помощью его интерфейсов для файловой системы. Это позволяет Hadoop-приложениям незаметно работать с KFS точно так же, как если бы на ее месте была бы HDFS. Код для интеграции с Hadoop был выпущен в виде патча к Hadoop-JIRA-1963, а начиная с Hadoop версии 0.15 этот код входит в стандартный дистрибутив, ровно как и детальная инструкция по интеграции.

Insight IT

Hypertable

Файлы в космосе

...или Kosmos Distributed File System