Big Data’13Лекция VI: NoSQL и согласованность

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

Computer Science Center

28 марта 2013

1/54

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

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

2/54

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

CAP теорема

Модели согласованности

Percolator

3/54

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

CAP теорема

Модели согласованности

Percolator

4/54

CAP теорема

I Из этих трех вещей можно выбрать только две:I Consistency (согласованность)I Availability (доступность)I Partition tolerance (устойчивость к разделению)

Это теорема, но не догма

5/54

CAP теорема

I Из этих трех вещей можно выбрать только две:I Consistency (согласованность)I Availability (доступность)I Partition tolerance (устойчивость к разделению)

Это теорема, но не догма

5/54

Согласованность

I Согласованность в СУБД: выполнение всехограничений

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

I Модель согласованности: набор правил, в обменна соблюдение которых система дает какие-тогарантии согласованности

I Бывают разные модели согласованности

6/54

Доступность

I Любой запрос, полученный работоспособнымузлом, должен получить ответ, содержащийзапрошенные данные

I Ответ «ой, у нас модем сломался, приходитезавтра» ответом не считается

I Считается ли система из 10 идентичныхread-only серверов в одном ЦОД доступнойпосле попадания в ЦОД ядерной бомбы?

7/54

Доступность

I Любой запрос, полученный работоспособнымузлом, должен получить ответ, содержащийзапрошенные данные

I Ответ «ой, у нас модем сломался, приходитезавтра» ответом не считается

I Считается ли система из 10 идентичныхread-only серверов в одном ЦОД доступнойпосле попадания в ЦОД ядерной бомбы?

7/54

Устойчивость к разделению

I Потеря сообщений (частичная или полная)между компонентами системы не влияет наработоспособность системы.

I Речь в основном о сбоях в сетиI Самая спорная концепция

8/54

Устойчивость к разделению: критика

I Сбой одного узла – тоже разделение, ведьсообщения то к нему не ходят

I не совсем так: он ведь и на запросы не отвечает,то есть не является работоспособным

I Абсолютно надежных сетей не задерживающихсообщения не бывает!

I но если у двух машин нет общих атомных часовто и о 100% согласованности говорить сложно

I Окей, но ведь в любом случае нельзя просто такигнорировать разделение!

I можно например сразу выключить всю систему

9/54

Устойчивость к разделению: критика

I Сбой одного узла – тоже разделение, ведьсообщения то к нему не ходят

I не совсем так: он ведь и на запросы не отвечает,то есть не является работоспособным

I Абсолютно надежных сетей не задерживающихсообщения не бывает!

I но если у двух машин нет общих атомных часовто и о 100% согласованности говорить сложно

I Окей, но ведь в любом случае нельзя просто такигнорировать разделение!

I можно например сразу выключить всю систему

9/54

Устойчивость к разделению: критика

I Сбой одного узла – тоже разделение, ведьсообщения то к нему не ходят

I не совсем так: он ведь и на запросы не отвечает,то есть не является работоспособным

I Абсолютно надежных сетей не задерживающихсообщения не бывает!

I но если у двух машин нет общих атомных часовто и о 100% согласованности говорить сложно

I Окей, но ведь в любом случае нельзя просто такигнорировать разделение!

I можно например сразу выключить всю систему

9/54

Выбор CP

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

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

I только запросы на чтение (системы ссинхронной репликацией)

I обслуживать доступ к данным, целикомнаходящимся внутри одной сетевой компоненты(шардированные системы)

10/54

Выбор AP

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

I Гарантируем что все запросы будут обслужены,но в случае распада произойдетрассогласованность

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

I разные версии обновлений данных в разныхкомпонентах

I Тем не менее, хочется чтоб в конце концовсистема пришла в согласованное состояние

11/54

Выбор AP

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

I Гарантируем что все запросы будут обслужены,но в случае распада произойдетрассогласованность

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

I разные версии обновлений данных в разныхкомпонентах

I Тем не менее, хочется чтоб в конце концовсистема пришла в согласованное состояние

11/54

Выбор CA

I Однозначно работает если системанераспределенная

I В распределенной кажется неразумнымповедением. По Закону Мерфи, сетьобязательно упадет и нельзя это игнорировать

I никто впрочем не употребляет «игнорировать»по отношению к согласованности

I Система может просто прекратить работу принеустранимом распаде.

I И это, возможно, будет случаться не так часто

12/54

Выбор CA

I Однозначно работает если системанераспределенная

I В распределенной кажется неразумнымповедением. По Закону Мерфи, сетьобязательно упадет и нельзя это игнорировать

I никто впрочем не употребляет «игнорировать»по отношению к согласованности

I Система может просто прекратить работу принеустранимом распаде.

I И это, возможно, будет случаться не так часто

12/54

Выбор CA

I Однозначно работает если системанераспределенная

I В распределенной кажется неразумнымповедением. По Закону Мерфи, сетьобязательно упадет и нельзя это игнорировать

I никто впрочем не употребляет «игнорировать»по отношению к согласованности

I Система может просто прекратить работу принеустранимом распаде.

I И это, возможно, будет случаться не так часто

12/54

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

CAP теорема

Модели согласованности

Percolator

13/54

ACID vs BASE

I Атомарность, Согласованность,Изолированность и Долговечность

I Basically Available, Soft-state, Eventualconsistency

14/54

Спектр моделей согласованности

I Строгая согласованность (strong consistency)I все операции чтения возвращают данные,записанные последней из предыдущих операцийзаписи, вне зависимости от того, в каком узлеони сделаны

I Слабая согласованность (weak consistency)I операции чтения необязательно возвращаютпоследнее записанное значение

I восстановление согласованности требуетвыполнения каких-то условий

I окно несогласованности (inconsistency window) -интервал между обновлением игарантированной его видимостью всемчитателям

15/54

Согласованность в конечном счете

I Eventual consistencyI Любое обновление через некоторое времяраспространится и станет доступным длячтения при отсутствии последующихобновлений

eventual consistency is so eventual

16/54

Согласованность в конечном счете

I Eventual consistencyI Любое обновление через некоторое времяраспространится и станет доступным длячтения при отсутствии последующихобновлений

eventual consistency is so eventual

16/54

Бонусы к согласованности в конечном счете

I «Что запишешь то прочтешь» (Read Your OwnWrites)

I клиент может читать свои собственныеобновления немедленно, вне зависимости оттого, на каком узле они сделаны

I Сессионная согласованностьI что запишешь то прочтешь, но в рамках однойсессии

I Причинная согласованностьI если процессу сообщили о записи то он увидитизмененное значение

I Монотонное чтениеI номер версии объекта, читаемого процессом, неуменьшается

17/54

В практическом применении

I Монотонное чтение + сессионнаясогласованность – хороший практическийвариант

18/54

Модель распространения обновлений

I Синхронные и асинхронныеI Асинхронное распространение

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

I фоновый процесс рассылает обновления другимузлам

I разумеется не гарантирует строгуюсогласованность

I Синхронное распространениеI запись подтверждается только если ее принялии подтвердили W узлов

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

19/54

Немного синхронной математики

I Пусть N узлов хранят реплику объекта, записьидет на W узлов, чтение с R узлов

I Если W+ R > N то множества узлов записи ичтения пересекаются и можно обеспечитьстрогую согласованность

I если есть два MySQL сервера с синхроннойрепликацией то N = 2,W = 2,R = 1

I Если W+ R <= N то множества могут непересечься

I два MySQL сервера с асинхронной репликацией:N = 2,W = 1,R = 1

20/54

ВариацииI Системы, ориентированные на согласованность,будут устанавливать W = N,R = 1

I и будут отказывать в записи если какой-то из Wузлов упадет

I Системы, ориентированные на доступность,будут устанавливать W = 1 и разные варианты R

I интересный вариант W = 1,R = N,W+ R > N:чтение всегда может выбрать последнююверсию, но узел с ней может упасть

I Системы, допускающие запись в разные узлы,скорее всего захотят W >= N+1

2I иначе могут получиться разные версии объекта

I Если W+ R <= N то нет особого смысла иметьR > 1

I согласованности нет все равно, зачем же читатьнесколько реплик

21/54

Привязка сессии к серверу

I Поддержка RYOW и сессионнойсогласованности

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

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

22/54

Версионирование данных

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

I Нужна модель поведения, которая позволитобработать эти разные версии и сойтись кединой

23/54

Оптимистичные блокировки

I Каждый элемент данных имеет свою временнуюметку

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

I Если это не так, транзакция не принимаетсяI Если метки совпали то производится запись иметки записанных элементов обновляются

I сильно помогает атомарная операцияCompare-And-Swap (CAS)

I Много приложений: ETag и If-Match заголовки вHTTP, редактирование страниц в Wikipedia, etc.

24/54

Мультиверсионный протокол

I У каждого элемента есть временная метка икаждой метке соответствует ревизия элемента

I У каждой транзакции есть временная меткаI Метки монотонно увеличиваютсяI Транзакция с меткой ti читает элементы сметкой tj < ti, @k : tj < tk < ti

I При записи обновленные данные получаютметку от транзакции

25/54

Векторные часы

I У каждого значения на каждом узле есть своявременная метка

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

I Получается матрица, гдеI строка i – сведения узла i о часах других узловI диагональный элемент Vii - актуальныепоказания часов узла i

I столбец j – сведения других узлов о часах узла j

26/54

Векторные часы: правила

I Операция на узле i увеличивает значение viiI Если узел i посылает сообщение узлу j, онувеличивает показания своих часов и посылаетвесь свой вектор вместе с сообщением

I Если узел j принимает сообщение от узла i, онувеличивает показания своих часов исравнивает векторы.

Vi > Vj, if ∀kVi[k] > Vj[k]

Если Vi > Vj то выигрывает значениеотправителя, если Vj > Vi то выигрываетзначение получателя, если никто не больше тозначит конфликт

27/54

Векторные часы: пример

I Начальное состояние

1 2 3

1 5 13 02 5 14 13 4 14 1

I Изменение на узле 2

1 2 3

1 5 13 02 5 15 13 4 14 1

28/54

Векторные часы: пример

I Узел 2 звонит узлу 1: V2 > V1

1 2 3

1 5 15 12 5 15 13 4 14 1

I Узел 3 звонит узлу 1: V1 > V3

1 2 3

1 5 15 12 5 15 13 4 14 1

29/54

Преимущества

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

30/54

31/54

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

CAP теорема

Модели согласованности

Percolator

31/54

Проблема построения веб индекса

I Map-Reduce это прекрасно но он производитцелый индекс или никакого

I Хочешь обновить индекс – запускаешь цепьMap-Reduce’ов и ждешь

I Это плохо подходит для новостей и блоговI Хотелось бы обновлять индекс подокументно

32/54

Проблема подокументного обновления

I Map-Reduce неприменим: ему нужен весь входчтобы построить весь выход

I Наивное обновление индекса может нарушитьограничения целостности

I например если есть несколько дубликатовстраниц то в индексе должна быть страница ссамым высоким рангом и отдельный списокдубликатов

I Для высокогранулярного обновления нужнытранзакции

33/54

Проблемы с транзакциями

I DBMS либо разорвутся либо озолотятсяI Bigtable as is поддерживает атомарность записиодной строки

I Нужно что-то что обеспечивает ACID свойствадля групп строк

34/54

Percolator

I Percolator – протокол и библиотекареализующая ACID транзакции поверх Bigtable

I Это клиентская библиотека, не встроенная вBigtable

35/54

Действующие лица

I Bigtable и GFSI Клиентские бинарники, использующиеPercolator

I Сервер временных метокI Легковесный сервис блокировок

36/54

Что обещается и что нет

I ОбещаетсяI ACID семантикаI Snapshot isolationI использование императивного языка

I Не обещаетсяI быстрый отклик

37/54

Схема работы

I При старте транзакция получает метку начала tsI Транзакция читает данные с временной меткойt < ts и записывает изменения локально

I Когда клиентский код решает подтвердитьтранзакцию

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

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

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

38/54

Где держать блокировки?

I Сервис блокировок должен:I переживать сбоиI обепечивать относительно низкое времяотклика

I обеспечивать относительно высокуюпропускную способность

I То есть наверное быть распределенным,реплицируемым, сбалансированным

I Погодите, так это ж Bigtable

39/54

Где держать блокировки?

I Сервис блокировок должен:I переживать сбоиI обепечивать относительно низкое времяотклика

I обеспечивать относительно высокуюпропускную способность

I То есть наверное быть распределенным,реплицируемым, сбалансированным

I Погодите, так это ж Bigtable

39/54

Где держать блокировки?

I Сервис блокировок должен:I переживать сбоиI обепечивать относительно низкое времяотклика

I обеспечивать относительно высокуюпропускную способность

I То есть наверное быть распределенным,реплицируемым, сбалансированным

I Погодите, так это ж Bigtable

39/54

Организация Percolator-строки в Bigtable

I Для каждого столбца данных c создаются:c:data Собственно данные, как

подтвержденные, так инеподтвержденные

c:lock Блокировка. Наличие записиозначает что транзакция находится вкакой-то из стадий двухфазногопротокола

c:write Метка последнего подтвержденногозначения

40/54

Пример транзакции

I Транзакция переводит 7 долларов со счетаАлисы на счет Болванщика

I Начальное состояние

Name ts bal:data bal:lock bal:writeАлиса 6 @5

5 $10Болванщик 6 @5

5 $2

41/54

Получение блокировок

I Транзакция получила метку ts = 7 и сделалалокальную работу

I Время подтверждаться. Требуем блокировки изаписывамем значения в data

Name ts bal:data bal:lock bal:writeАлиса 7 $3 prim

6 @55 $10

Болванщик 7 $9 prim@Алиса.bal6 @55 $2

42/54

Возможные неприятности

I Наличие записи в bal:write с меткой > 7 – поводупасть

I Наличие записи с какой-либо меткой в bal:lock– повод задуматься

43/54

Подтверждение

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

I Время подтверждаться. Получаем меткукоммита tc, обновляем значения в столбце writeи чистим блокировки, начиная с главной

Name ts bal:data bal:lock bal:writeАлиса 8 @7

7 $36 @55 $10

Болванщик 7 $9 prim@Алиса.bal6 @55 $2

44/54

Главная блокировка

I Признак (не)подтвержденности транзакцииI Главная блокировка висит → транзакциянеподтверждена и возможно еще пишетизменения

I Главная блокировка снята → транзакциязаписала все изменения по крайней мере в data

I Все остальные взятые блокировки показываютна главную

45/54

Завершение подтверждения

I Продолжаем снимать блокировки иподтверждать значения

Name ts bal:data bal:lock bal:writeАлиса 8 @7

7 $36 @55 $10

Болванщик 8 @77 $96 @55 $2

46/54

Возможные неприятностиI Транзакция в клиенте может упасть призавершении подтверждения

I тогда кто-то может доделать ее работу.Например, следующая транзакция, котораяобнаружит вторичную блокировку, но не найдетглавной

I Транзакция может упасть между взятиемблокировок и подтверждением. Тогда ужевзятые замки будут мешать последующимтранзакциям

I вводится политика сборки мусора другимитранзакциями

I используется наличие главной блокировки какпризнак неподтвержденности транзакции (ивозможного ее падения)

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

47/54

Операция чтения

I Чтение просит значения с меткой меньше tsI Если чтение видит блокировку то оно ждет ееснятия

I Утверждение: чтение всегда будет получатьподтвержденные значения с меткой меньше ts

48/54

Корректность snapshot изоляции в PercolatorI пусть транзакция W с TW < TR пишет значенияпараллельно с R

I так как TW < TR то значит сервис часов выдалметку W в том же запросе что и метку R илираньше

I значит W попросила метку раньше чем R ееполучила

I W обязана все заблокировать, прежде чемполучить метку подтверждения

I R обязана попросить метку старта прежде чемначать читать

I значит W заблокировала < W запросила меткуподтверждения < R получила метку начала < Rчитает

49/54

Результат внедрения Percolator

I Медиана времени обновления документа сталаменьше в сотни раз

I Система стала проще в обслуживанииI Потребление ресурсов стало гораздо болеегладким

I хотя в целом и выросло

50/54

Занавес

I CAP теорема считается верной, но кроме ееэкстремальных случаев есть полутона

I Бывают разные модели согласованностиI Согласованности можно достичь дажевнешними средствами

51/54

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

Pa

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

alpha.papeeria.com

52/54

Литература I

Seth Gilbert and Nancy Lynch.Brewer’s conjecture and the feasibility of consistent,available, partition-tolerant web services.ACM SIGACT News, 33(2):51–59, 2002.Daniel Peng and Frank Dabek.Large-scale incremental processing usingdistributed transactions and notifications.In Proceedings of the 9th USENIX conference onOperating systems design and implementation,pages 1–15. USENIX Association, 2010.Michael Stonebraker.In search of database consistency.Commun. ACM, 53(10):8–9, October 2010.

53/54

Литература II

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

54/54