Google BigTable

Основа модели данных BigTable проста: строки (rows), столбцы (columns) и временн ы е метки (timestamps). В базе поисковика именами строк могут служить адреса документов в интернете, а именами столбцов — особенности этих документов (например, содержание документа может храниться в столбце «content:», а ссылки на дочерние страницы — в столбцах «anchor:»). Другой пример — карты Google, состоящие из миллиардов изображений, каждое из которых детализирует тот или иной географический участок планеты. В BigTable карты Google структурируются следующим образом: каждой строке соответствует один географический сегмент, а столбцами являются изображения, из которых этот сегмент состоит, причем в разных столбцах хранятся изображения с разной детализацией.

Пример модели хранения данных BigTable для предметной области «Содержимое сайта».

Если в нескольких столбцах хранятся данные одного типа, такие столбцы, согласно модели BigTable, образуют семейство (column family). Использовать семейство столбцов удобно хотя бы для того, чтобы сжать однородные данные, тем самым уменьшив хранимый объём. Именно семейства столбцов являются единицей доступа к данным.

Строки BigTable (их максимальная длина может достигать 64 килобайта) тоже важны. Операция обращения к строке является атомарной (это значит, что, пока одна программа обращается к строке, ни одна другая не имеет права изменять данные в семействах столбцов этой строки). А ещё строки удобно сортировать. В примере с URL документа, сделав его запись реверсивной, легко отсортировать все строки по имени домена третьего уровня.

Содержимое страниц в интернете постоянно меняется. Чтобы учесть эти изменения, каждой копии данных, хранящихся в столбце, присваивается временн а я метка (timestamp). В BigTable временн о й меткой служит 64-разрядное число, которое может кодировать время и дату так, как это требуется клиентским программам. Например, timestamp для копий веб-страницы в столбце «contents:» является датой и временем создания этих копий. Используя временн ы е метки, приложения могут задать в BigTable поиск, например, только самых последних копий данных, информации, созданной за прошедшую неделю, или же данных, появившихся в момент с определённой датой и временем.

Но главный плюс такого подхода состоит в том, что подобную базу не трудно порезать на независимые кусочки и распределить по множеству серверов. Отсортированные по алфавиту строки делятся на диапазоны, которые именуются «таблетами» (tablet) — несамостоятельными таблицами. Поскольку строки в каждом таблете отсортированы по ключевому имени, клиентским приложениям очень просто найти нужный таблет, а в нём – нужную строку.

Какой бы большой ни была исходная таблица BigTable, её всегда можно разделить на отдельные таблеты и раздать множеству обрабатывающих узлов.

Процесс, обслуживающий таблеты, называется таблет-сервером. Для него не выделяют специальный компьютер. Таблет-сервер делит компьютерные ресурсы с исполнителями заданий системы MapReduce и драйвером файловой системы GFS. Страшного в этом ничего нет. На один таблет-сервер приходится не более тысячи таблетов величиной по 100–200 мегабайтов. Такие небольшие объёмы оправданы с точки зрения отказоустойчивости. В случае выхода из строя сервера системе управления BigTable несложно найти таблет-серверы, которым можно перепоручить обработку таблетов «погибшего товарища».

Дирижирование согласованной работой множества таблет-серверов в архитектуре BigTable берёт на себя BigTable Master — процесс, выполняющийся на одном из серверов Google. Он отвечает за размещение таблетов на таблет-серверах, обнаружение, добавление или удаление таблет-серверов в уже существующей их инфраструктуре и балансировку их загрузки. Кроме того, BigTable Master поддерживает схему изменений общей таблицы BigTable — например, редактирование состава семейства столбцов или форматов timestamps.

Управление синхронизацией операций чтения/записи одних и тех же данных множеством клиентов не входит в задачу мастера BigTable. В системах обработки информации с этой проблемой обычно справляются сами обработчики. Но BigTable — это чересчур большая и распределённая система для таких синхронизирующих объектов, поэтому вместо них применяется распределённый сервис блокировок (distributed lock service), который в Google именуют Chubby. Его роль в BigTable можно сравнить с ролью транзакций в обычных СУБД.

В кластере BigTable два дирижёра — BigTable Master и сервис блокировок Chubby. Первый отвечает за масштабируемость и отказоустойчивость, а второй — за синхронизацию и учёт данных.

Для каждого таблет-сервера Chubby создает специальный chubby-файл. Благодаря этому файлу BigTable Master всегда в курсе того, какие из серверов работоспособны. Ещё один chubby-файл содержит ссылку на расположение корневого таблета (Root-tablet) с данными о расположении всех остальных таблетов. Этот файл сообщает мастеру, какой из серверов какими таблетами управляет.

Процесс взаимодействия всех компонентов BigTable и используемые для этого информационные структуры.

Дата добавления: 2015-07-15