Upload
fuenteovejuna
View
2.048
Download
0
Embed Size (px)
DESCRIPTION
Citation preview
Вы решили написать собственное хранилище данных
Илья Космодемьянский
Данные
• Традиционно хранят в СУБД • Данные нужно хранить надежно • С данными нужно производить действия: CRUD • CR – «просто», UD – «сложно» • Хранилища данных имеют специализацию
Зачем писать свое хранилище? Распростарненные случаи
• «Делали на MySQL, устали – теперь хотим чего-‐либо более светлого»
• Уперлись в мастер • Медленные join’ы
• «И вообще все криво» • «Хотим искать максимальную клику графа и чтоб нам за это ничего не было»
Зачем писать свое хранилище? Распростарненные случаи
• «Делали на MySQL, устали – теперь хотим чего-‐либо более светлого»
• «Делали на Postgres, устали – теперь хотим чего-‐либо более светлого»
• «Не репликация а черти что» • «Не смогли научить использовать правильный индекс» • «И вообще все криво» • «Хотим найти все циклы в произвольном графе и чтобы нам за это ничего не было»
Зачем писать свое хранилище? Распростарненные случаи
• «Делали на MySQL, устали – теперь хотим чего-‐либо более светлого»
• «Делали на Postgres, устали – теперь хотим чего-‐либо более светлого» • «Делали на Oracle, устали – теперь хотим чего-‐либо более светлого»
• «Хотим мультимастер в две стороны» • «Не смогли научить использовать правильный индекс» • «Очень сложно, Concepts читать долго, много воды» • «Хотим перемножать матрицы за O(1) и чтоб золотая рыбка была у меня на посылках»
Зачем писать свое хранилище? Распростарненные случаи
• «Делали на MySQL, устали – теперь хотим чего-‐либо более светлого»
• «Делали на Postgres, устали – теперь хотим чего-‐либо более светлого» • «Делали на Oracle, устали – теперь хотим чего-‐либо более светлого» • «Делали на DB2/MSSQL/Sybase … whatever»
Зачем писать свое хранилище? Распростарненные случаи
• «Делали на MySQL, устали – теперь хотим чего-‐либо более светлого»
• «Делали на Postgres, устали – теперь хотим чего-‐либо более светлого» • «Делали на Oracle, устали – теперь хотим чего-‐либо более светлого» • «Делали на DB2/MSSQL/Sybase … whatever»
• «А давайте запилим что-‐нибудь высокотехнологичное – будем как…»
Зачем писать свое хранилище? Распростарненные случаи
• «Делали на MySQL, устали – теперь хотим чего-‐либо более светлого»
• «Делали на 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
send_money(S, B, 200 ) A2
S = 900RUR ?
S = 800RUR ?
S = 700RUR !
A1
A1
A2
A2
затем
затем или
Конкурентный доступ S = 1000RUR
send_money(S, B, 100 ) A1
send_money(S, B, 200 ) A2
S = 900RUR ?
S = 800RUR ?
S = 700RUR !
A1
A1
A2
A2
затем
затем или
Изоляция
Конкурентный доступ S = 1000RUR
send_money(S, B, 100 ) A1
send_money(S, B, 200 ) 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
Возвращаемся к постановке задачи
• Данные не должны браться из ниоткуда и не должны пропадать • Данные связаны между собой • Устранены-‐ли проблемы по которым нас не устраивала СУБД • Сколько мы на это все потратитли и сколько еще потратим?