Вы решили написать собственное хранилище (Илья Космодемьянский)

Вы решили написать собственное хранилище данных

Илья Космодемьянский

Данные

•  Традиционно хранят в СУБД •  Данные нужно хранить надежно •  С данными нужно производить действия: CRUD •  CR – «просто», UD – «сложно» •  Хранилища данных имеют специализацию

Зачем писать свое хранилище? Распростарненные случаи

•  «Делали на MySQL, устали – теперь хотим чего-‐либо более светлого»

•  Уперлись в мастер •  Медленные join’ы

•  «И вообще все криво» •  «Хотим искать максимальную клику графа и чтоб нам за это ничего не было»



•  «Делали на Postgres, устали – теперь хотим чего-‐либо более светлого»

•  «Не репликация а черти что» •  «Не смогли научить использовать правильный индекс» •  «И вообще все криво» •  «Хотим найти все циклы в произвольном графе и чтобы нам за это ничего не было»



•  «Делали на Postgres, устали – теперь хотим чего-‐либо более светлого» •  «Делали на Oracle, устали – теперь хотим чего-‐либо более светлого»

•  «Хотим мультимастер в две стороны» •  «Не смогли научить использовать правильный индекс» •  «Очень сложно, Concepts читать долго, много воды» •  «Хотим перемножать матрицы за O(1) и чтоб золотая рыбка была у меня на посылках»



•  «Делали на Postgres, устали – теперь хотим чего-‐либо более светлого» •  «Делали на Oracle, устали – теперь хотим чего-‐либо более светлого» •  «Делали на DB2/MSSQL/Sybase … whatever»




•  «А давайте запилим что-‐нибудь высокотехнологичное – будем как…»




•  «А давайте запилим что-‐нибудь высокотехнологичное – будем как…» •  «Чтоб разгрузить БД, нужно простенькое быстрое хранилище» !!!

Вобщем решили писать с нуля

Ну или почти с нуля – не суть ;-‐)

Надежность хранилища Mission cri>cal?

Перевод денег со счета на счет в банке

Порядок постов во френдленте

Где граница?

Надежности мешают отказы Хороший термин Failure, переведем его как Падение

•  Падает железо •  Падает ПО •  Непродуманый дизайн ПО ведет к падениям •  Нерадивый админ нажал не на ту кнопку и все упало

Потенциальная проблема

Случившаяся проблема

Ошибка Падение (ошибка которую

нельзя обработать)

Начинаем с простого

D

Добавляем надежность

D3 D1 D2

Dm

Простое и логичное решение!

Это был подход «Чтобы не падало»

Почему плохо

•  Сразу две проблемы – и с чтением и записью •  Непроизводительно

Быстро поднятое не считается упавшим

•  Исходим из того, что система всё равно когда-‐нибудь может упасть •  Минимизируем потери

Атомарность

D1 D2

Такая последовательность действий восстановима

Конкурентный доступ S = 1000RUR

send_money(S, B, 100 ) A1


S = 900RUR ?

S = 800RUR ?

S = 700RUR !

A1

A1

A2

A2

затем

затем или




S = 900RUR ?

S = 800RUR ?

S = 700RUR !

A1

A1

A2

A2

затем

затем или

Изоляция




S = 900RUR ?

S = 800RUR ?

S = 700RUR !

A1

A1

A2

A2

затем

затем или

Изоляция

Восстановимость + изоляция = атомарность

Свойства действий с блоками данных •  Атомарность •  Целостность – набор правил для данных •  Долговечность

Действие, обладающее такими свойствами есть транзакция

Быстрая восстановимость

•  Версии

D0 D1 VN

А если упали на смене VN? Если все действие прошло успешно,

достигнут Commit point

Быстрая восстановимость

•  Версии •  Пишем лог

Изоляция/корректность – легко без производительности

T1 T2

r1[x] w2[x]

w2[y] w1[y]

w2[y] w1[y] r1[x] w2[x] -‐ корректная история

Направление стрелок – порядок выполненения конфликтующих действий

История корректна если эквивалентна последовательному выполнению транзакций – сериализуема

T2

T3

T4 T1

Граф действий / граф конфликтов

Если нет циклов, то историю на которой он построенможно сериализовать

Некорректная история –

падение и нарушение целостности

2PL •  с конфликтами борятся блокировками – блокирующий шедулер •  двухфазное блокирование – сначала выставляем все блокировки, ни одна блокировка не может быть снята пока не выставлены все

•  С помощью 2PL мы добиваемся изоляции при сохранении производительности

Мы построили хранилище на отдельно взятой машине

•  Объективно машина не справляется. Что дальше? •  Scale out – репликация и шардинг •  Асинхронный месседжинг – очереди – что они дают •  Распределенные транзакции – если до этого было еще не страшно

Нерассмотренные важные моменты

•  Сеть и производительность •  Мониторинг

•  capex/opex

Возвращаемся к постановке задачи

•  Данные не должны браться из ниоткуда и не должны пропадать •  Данные связаны между собой •  Устранены-‐ли проблемы по которым нас не устраивала СУБД •  Сколько мы на это все потратитли и сколько еще потратим?

Documents

Вы решили написать собственное хранилище (Илья Космодемьянский)