2013 03 28_big_data_lecture_06
Transcript of 2013 03 28_big_data_lecture_06
Big Data’13Лекция VI: NoSQL и согласованность
Дмитрий Барашев[email protected]
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