26 ноября 2013

Bigtable. Хранилище для петабайтов данных Google

Bigtable. Хранилище для петабайтов данных Google

Статья из цикла «Google Platform»

Bigtable – высокопроизводительная база данных, реализующая колоночную схему хранения и построенная на основе GFS и некоторых других внутренних продуктах Google. Как и GFS, Bigtable – проприетарная система, внутреннее устройство которой, тем не менее, было подробно описано инженерами Google в research paper [3].

Bigtable – хорошо масштабирующееся хранилище данных, рассчитанное на хранение петабайтов информации и работающее на commodity-серверах. Bigtable работает на production-серверах с 2005 года. В разное время в BigTable хранили данные web-индексов, сервисов Google Analytics, Google Earth, Google Finance [3].

До появления Spanner и других более узкоспециализированных внутренних хранилищ данных в Google, Bigtable «работал» с клиентами с крайне разнообразными требованиями как по объему данных (от URL до снимков спутника), так и по задержки в ответе (от пакетных режимов до режимов близких к реальному времени). В свою очередь клиенты определяли схему хранимых структурированных/полуструктурированных данных.

Модель данных

Big Table представляет собой разреженную распределенную многомерную отсортированную карту (оригинал [3] - sparse, distributed, persistent multidimensional sorted map). Карты проиндексирована по ключу строки (row key), ключу столбца (column key) и временной метке (timestamp).

(row:string, column:string, timestamp:int64) -> string

На основе лексикографического анализа, поддерживаемого Bigtable, row key объединяются в диапазоны строк, которые в терминах Bigtable называются Tablet. Tablet может динамически партицироваться и является ключевым элементом балансировки нагрузки.

Column key, в свою очередь, объединяются в семейства столбцов (column family). Последние представляют собой простейшую единицу доступа к данным.

Timestamp позволяет добавить в Bigtable версионность данных, а также реализовать append-only модель хранения данных.

Базовые принципы

Основные компоненты, входящие в кластер Bigtable – это единственный Master-сервер, многочисленные tablet-сервера и клиенты.

Master – это процесс, выполняющийся на отдельном узле. Принципиальные цели Master-сервера – доступность, масштабируемость, отказоустойчивость. Поэтому в зону ответственности Mater-сервера входят:

  • балансировка нагрузки между tablet-серверами;
  • размещение tablet'ов на tablet-серверах;
  • добавление/удаление tablet-серверов в кластер.

Tablet-сервер содержит в себе, в общем случае, около сотни tablet'ов. Поэтому сфера ответственности tablet-сервера лежит в обработке запросов на чтение/запись к tablet'ам, а также разделении слишком больших tablet'ов.

Кроме Master-сервер и tablet-серверов в работа Bigtable-кластера участвует распределенный сервис блокировок Chubby (также внутренний продукт Google). Принципиальная цель Chubby в Bigtable – это синхронизация (вполне уместна будет аналогия, что Chubby предоставляет распределенные примитивы синхронизации).

Ограничения

Bigtable обладает рядом ограничений:

  1. Не поддерживаются транзакции на уровне нескольких строк (только на уровне одной строки);
  2. Определение способа хранения данных – RAM или диск – ответственность клиента. Bigtable не пытается определить наилучший способ хранения динамически;
  3. На момент публикации research paper [3], описывающего принципы построения Bigtable, система не обладала возможностью репликации через географически удаленные датацентры;
  4. На момент публикации [3], хранилище не обладало возможность построения вторичных индексов;
  5. Зависимость от сервиса распределенных блокировок Chubby – если Chubby не отвечает (такое бывает менее 0,01% времени, то и Bigtable-кластер не доступен.

Будущее и итоги

Bigtable, без сомнения, была самой большим по объему хранимых данных NoSQL базой в мире. Более того, концепции, лежащие в основе Bigtable и описанные в [3], легли в основу многих популярных сегодня NoSQL-решений, в т.ч. HBase – NoSQL БД, входящая в экосистему Hadoop.

Тем не менее, хорошо знакомые сообществу достоинства и ограничения NoSQL-решений также свойственны и Bigtable. В какой-то момент времени у некоторых из сервисов Google появилось критичное требование – поддержка принципа ACID для распределенных транзакций. Ни NoSQL-решения, в общем случае, ни Bigtable, в частности, не могли реализовать поддержку данного требования.

Так инженерами Google была начата работа над распределенным хранилищем нового поколения, которое можно отнести к классу NewSQL. На сегодняшний день это хранилище известно как Spanner. Архитектура этого хранилища будет описана в одной из следующих статей из цикла.

Список источников*

  • [3] Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A.Wallach, et al. Bigtable: A Distributed Storage System for Structured Data. Proceedings of OSDI, 2006.

* Полный список источников, используемый для подготовки цикла.

Комментариев нет:

Отправить комментарий

Автор статьи

,
Machine Learning Preacher, Microsoft AI MVP && Coffee Addicted