Big Data’13Лекция V: NoSQL СУБД. Google Bigtable

Дмитрий Барашевbigdata@barashev.net

Computer Science Center

21 марта 2013

1/54

Этот материал распространяется под лицензией

Creative Commons ”Attribution - Share Alike” 3.0http://creativecommons.org/licenses/by-sa/3.0/us/deed.ru

2/54

Сегодня в программе

Шаблоны доступа к данным

Реляционные СУБД и модные приложения

Таксономия NoSQL

Колоночные СУБД

Bigtable

3/54

Анекдот для затравки

A DBA walks into a NOSQL bar, but turns and leavesbecause he couldn’t find a table

then he walks into Google bar and finds a big tablethere

4/54

Анекдот для затравки

A DBA walks into a NOSQL bar, but turns and leavesbecause he couldn’t find a table

then he walks into Google bar and finds a big tablethere

4/54

Сегодня в программе

Шаблоны доступа к данным

Реляционные СУБД и модные приложения

Таксономия NoSQL

Колоночные СУБД

Bigtable

5/54

Последовательный доступ

I Map-Reduce, Pregel: последовательный доступ ипакетная обработка

I Читается много, записывается многоI Результат используется напрямую или подаетсяследующим звеньям, но не меняется

I Прекрасно для индексирования всего интернета

6/54

Другие приложения

I Твиты, шаринги, лайки, котики, ботнетыI Много данных, постоянно добавляются именяются

I Случайный доступ к даннымI Зато данные достаточно локальны

7/54

Варианты хранения

I Классическая реляционная СУБДI Oracle, SQL Server, MySQL, etc.

I Модная NoSQL СУБДI MongoDB, Cassandra, HBase, etc.

8/54

Классическая реляционная СУБД

I Заранее известная структураI Данные хранятся построчноI Отношения нормализованы и связаны друг сдругом

I ACID транзакцииI SQL, позволяющий выразить очень сложныезапросы

I Архитектура, выжимающая на high-end машиневсё из сравнительно медленных дисков

Это прекрасно и зачастую ненужно

9/54

Классическая реляционная СУБД

I Заранее известная структураI Данные хранятся построчноI Отношения нормализованы и связаны друг сдругом

I ACID транзакцииI SQL, позволяющий выразить очень сложныезапросы

I Архитектура, выжимающая на high-end машиневсё из сравнительно медленных дисков

Это прекрасно и зачастую ненужно

9/54

WAT? Это ненужно?

I Если у вас банк или ERP система то вашиданные – это ваши деньги

I Конечно же вам нужны ACID транзакции инормализация

I Но никому не интересно, будет на светекотиком больше или лайком меньше

I Зато хочется чтобы сервис был доступен ифренд-лента не тупила

10/54

WAT? Это ненужно?

I Если у вас банк или ERP система то вашиданные – это ваши деньги

I Конечно же вам нужны ACID транзакции инормализация

I Но никому не интересно, будет на светекотиком больше или лайком меньше

I Зато хочется чтобы сервис был доступен ифренд-лента не тупила

10/54

Сегодня в программе

Шаблоны доступа к данным

Реляционные СУБД и модные приложения

Таксономия NoSQL

Колоночные СУБД

Bigtable

11/54

Строгая схема и нормализация

I Не дублируй факты! Не допускай аномалий!НФБК! Ключи!

I Это все так – там где данные стоят денегI Но абстракции текут уже в РСУБД: клиентскиепрограммы объектно-ориентированы, ORM isPITA

I Модные приложения не хотят структуры инормализации, они хотят ключ-значение

12/54

Заранее известная схема

I ALTER TABLE User ADD COLUMN friend_count INT

I ALTER command denied to user ’***’ fortable ’User’

I Модные приложения не знают заранее, что импонадобится в будущем

I или знают, что поле «номер паспорта» в соцсетизаполнит не так много пользователей какхотелось бы

13/54

Заранее известная схема

I ALTER TABLE User ADD COLUMN friend_count INTI ALTER command denied to user ’***’ fortable ’User’

I Модные приложения не знают заранее, что импонадобится в будущем

I или знают, что поле «номер паспорта» в соцсетизаполнит не так много пользователей какхотелось бы

13/54

Заранее известная схема

I ALTER TABLE User ADD COLUMN friend_count INTI ALTER command denied to user ’***’ fortable ’User’

I Модные приложения не знают заранее, что импонадобится в будущем

I или знают, что поле «номер паспорта» в соцсетизаполнит не так много пользователей какхотелось бы

13/54

Сложные запросы

I 30 лет назад перед терминалом сидел оператори писал запросы на SQL или другом языке

I он мог написать любой запросI Сейчас пользователи смотрят френдленту,жмут лайки и посылают друг другу сообщения

I запросы модного приложения не отличаютсяразнообразием

I Значит и движок общего назначения не оченьнужен

14/54

Одна high-end машина

I К сожалению на IBM System Z у модногоприложения нет денег

I Даже если бы они и были, модные приложенияне хотят

I зависеть от одного сервераI от одного датацентраI от одного континента

15/54

Одна high-end машина

I К сожалению на IBM System Z у модногоприложения нет денег

I Даже если бы они и были, модные приложенияне хотят

I зависеть от одного сервераI от одного датацентраI от одного континента

15/54

Масштабируемость

I Вторую high-end машину так быстро невключишь как минимум нужен банкет

I И вообще выгодней арендовать (виртуальные)машины в ДЦ чем держать свои

I Значит СУБД должна работать на low-endжелезе и считать отказ нормальным явлением

I а значит реплицироваться и шардироваться

16/54

Транзакционная семантика

I Как только СУБД становится распределенной,сразу возникают проблемы с ACID транзакциямии доступностью системы

I Но модному приложению неважно, когда суммалайков увеличится на 1: в тот момент когдалайк добавлен, или через 5 минут.

I На смену ACID спешит BASE: Basic Availability,Soft state, Eventually consistent

17/54

Железо вообще

I 30 лет назад оперативная память стоиладорого; процессоры были слабые

I Сейчас оперативная память измеряетсятерабайтами и у каждого в кармане по 4процессорных ядра

I Время позиционирования диска и времядоступа к RAM изменилось не сильно(20ms→ 4ms для диска и 200µs→ 100µs для RAM)

I Зато появилось три уровня кеша которыесущественно быстрее (≈ 1µs)

Есть место для других алгоритмов

18/54

Железо вообще

I 30 лет назад оперативная память стоиладорого; процессоры были слабые

I Сейчас оперативная память измеряетсятерабайтами и у каждого в кармане по 4процессорных ядра

I Время позиционирования диска и времядоступа к RAM изменилось не сильно(20ms→ 4ms для диска и 200µs→ 100µs для RAM)

I Зато появилось три уровня кеша которыесущественно быстрее (≈ 1µs)

Есть место для других алгоритмов

18/54

Ситуация не нова: OLAP vs OLTP

19/54

OnLine Transaction Processing

I данные обновляются, часто параллельноI часто затрагивают одну таблицу и почти всеатрибуты

I запросы высокоселективныI ожидается низкое время отклика

20/54

OnLine Analytical Processing

I read-only запросыI у сущностей много атрибутов но запросинтересуется небольшим подмножеством

I низкая селективностьI всякого рода агрегированиеI время выполнения запроса ожидаемо велико

21/54

В середине 90-х появились специальные OLAPсистемы

22/54

Сегодня в программе

Шаблоны доступа к данным

Реляционные СУБД и модные приложения

Таксономия NoSQL

Колоночные СУБД

Bigtable

23/54

Классификация по модели данных

I «Ключ-значение»: мало чем отличается отхештаблицы, значением обычно являетсястрока

I тыщи их. Redis из самых популярныхI «Ключ-документ»: значением являетсядокумент, который может быть как BLOB’ом таки сложной структурой. СУБД можетподдерживать поиск по структуре документа

I яркий представитель MongoDBI «Ключ-расширяемая структура»: можно считатьразреженной таблицей с бесконечным числомстолбцов.

I Google Bigtable, HBase, Cassandra

24/54

Классификация по организации храненияданных

I Построковое хранениеI Колоночное хранениеI Журнальное хранение

25/54

Классическое построковое хранение

I все атрибуты кортежа плотно сидят рядом водном дисковом блоке

I атомарное чтение/запись одного кортежа

26/54

Колоночное хранение

I в один блок упаковываются значения одного итого же атрибута разных кортежей

I кортеж разнесен по нескольким блокамI доступ к одному столбцу существенноэффективнее

27/54

Журнальное хранение

I дисковые блоки для чтения read-onlyI данные для чтения сидят в RAMI обновления записываются в RAM и в журналI периодически журнал и основные данныеобъединяются

28/54

Сегодня в программе

Шаблоны доступа к данным

Реляционные СУБД и модные приложения

Таксономия NoSQL

Колоночные СУБД

Bigtable

29/54

Быстрое получение всех значений атрибута

I Пусть в кортеже в таблице Webtable 1000атрибутов.

I Атрибут site – адрес сайта страницы, атрибутvisits – число посещений сегодня Какая схемахранения выиграет при выполнении запроса?

1 SELECT site, SUM(visits) FROM Url GROUP BY site

30/54

Построчное хранение

site …+ 500 … visits …+ 500 …a.example.com … 5 …a.example.com … 15 …a.example.com … 45 …b.example.com … 3 …b.example.com … 0 …b.example.com … 4 …b.example.com … 8 …

31/54

Колоночное хранение

site …+ 500 … visits …+ 500 …a.example.com … 5 …a.example.com … 15 …a.example.com … 45 …b.example.com … 3 …b.example.com … 0 …b.example.com … 4 …b.example.com … 8 …

32/54

Локальность данных в кеше

I Кеш процессора не такой уж большойI При построчном хранении будет использоватьсямалая часть

I При колоночном все нужные значения идут другза другом – кеш используется эффективнее

33/54

Сжатие значений

I Пусть на каждом сайте от 10 до 1000 страниц, всреднем 500.

I Пусть всего миллион сайтовI Пусть средняя длина адреса 20 байтI Сколько понадобится места для храненияадресов в построчном хранении и сколько вколоночном?

34/54

Сжатие значенийI Строковое хранение

site …+ 500 … visits …+ 500 …a.example.com … 5 …

и еще 400 страницa.example.com … 45 …b.example.com … 3 …

и еще 400 страницb.example.com … 8 …

I колоночное хранениеsitea.example.com+400a.example.comb.example.com+400b.example.com

35/54

Сегодня в программе

Шаблоны доступа к данным

Реляционные СУБД и модные приложения

Таксономия NoSQL

Колоночные СУБД

Bigtable

36/54

Bigtable

I Google, первая половина 2000-х годовI Разреженный распределенный многомерныйсортированный хранимый словарь

I или, ммм... большая таблица со строчками,колонками и версиями значений

I Значение – неинтерпретируемый BLOBI (row: string, column: string, time: int64)

→ byte[]

37/54

Кортежи таблицы

I Ключ – произвольная последовательностьсимволов

I Кортежи отсортированы в порядкелексикографического возрастания ключей

I Все множество кортежей разбито на таблеты –непересекающиеся непрерывные диапазоны

I Таблет – единица распределения работы инагрузки

I Чтение и запись значений одного кортежаатомарны

38/54

Столбцы таблицы

I Семейство: группа однотипных столбцовI В таблице обычно не очень много семейств новнутри семейства может быть много столбцов

I Группы хранения (locality groups) - наборсемейств, которые обычно используются вместе

39/54

SSTable

I Сортированное отображение строк в значенияI Сортированный массив с разреженныминдексом поверх

I SSTable создается для каждой группы храненияI SSTable доступна только на чтениеI SSTable живет на GFS

40/54

Жизнь системы

I Таблеты обслуживаются таблет-серверами N:1I В специальной таблице METADATA записанораспределение диапазонов ключей по таблетами таблетов по серверам

I Расположение таблетов METADATA записано вкорневом таблете

I Расположение корневого таблета системеизвестно

I Мастер следит за состоянием таблет-серверов изанимается назначением таблетов

41/54

Жизнь клиента

I Клиент читает информацию о том где искатькорневой таблет

I Обращается к корневому таблету заинформацией о METADATA

I Обращается к METADATA за информацией о томгде прописаны таблеты нужной ему строки

I Звонит соответствующему таблет-серверуI Клиенты кешируют метаинформацию

42/54

Жизнь записи в таблете

I Запись производится в redo-журнал,подтверждается и записывается в изменяемыйсловарь в памяти (memtable)

I Если кортеж удаляется то записывается«могильный камень»

I Minor compaction: когда memtable становитсядостаточно большим, его замораживают исоздают набор новых SSTable

43/54

Жизнь чтения в таблете

I Запрос на чтение должен объединить данныеиз memtable и соответствующих SSTable

I Так как все отсортировано по ключу то этонедорогой процесс

44/54

Важные события в жизни таблета

I Разделение (split)I Большое уплотнение (major compaction)

45/54

Разделение таблета

46/54

Равномерно распределенные ключи

47/54

Неравномерно распределенные ключи

48/54

Большое уплотнение

I В процессе записи постоянно создаются новыенебольшие SSTable

I Время от времени новые и старые SSTable надообъединять

I После уплотнения данные из одного диапазоналежат в одном SSTable и удалены всемогильные камни

49/54

Реализации Bigtable

I Закрытая в Google (торчит наружу в App Enginedatastore)

I Apache HBase Cassandra (родом из Facebook)

50/54

Занавес

I Не все большие данные обрабатываютсяконвейерно

I Не всем приложениям нужны возможности игарантии реляционных СУБД

I NoSQL СУБД осблуживают приложения сдругими требованиями

I Google Bigtable – одна из самых ранних NoSQLСУБД

I Реализаций NoSQL СУБД очень многоI Традиционные СУБД тоже начинаютподдерживать NoSQL фичи

I А NoSQL СУБД начинают поддерживать ACIDтранзакции

51/54

Эта презентация сверстана в

Pa

peeria1LTEX в вашем браузере

alpha.papeeria.com

52/54

Литература IFay Chang, Jeffrey Dean, Sanjay Ghemawat,Wilson C Hsieh, Deborah A Wallach, Mike Burrows,Tushar Chandra, Andrew Fikes, and Robert EGruber.Bigtable: A distributed storage system forstructured data.ACM Transactions on Computer Systems (TOCS),26(2):4, 2008.Ikai Lan.App engine datastore tip: monotonically increasingvalues are bad.http://ikaisays.com/2011/01/25/app-engine-datastore-tip-monotonically-increasing-values-are-bad/,2011.[Online; accessed 21-March-2013].

53/54

Литература II

Christof Strauch, Ultra-Large Scale Sites, and WalterKriha.Nosql databases.Lecture Notes, Stuttgart Media University, 2011.

54/54