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

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

3. Зачем
писать
свое
хранилище?
Распростарненные
случаи
•
«Делали
на
MySQL,
устали
–
теперь
хотим
чего-­‐либо
более
светлого»
•
Уперлись
в
мастер
•
Медленные
join’ы
•
«И
вообще
все
криво»
•
«Хотим
искать
максимальную
клику
графа
и
чтоб
нам
за
это
ничего
не
было»

4. Зачем
писать
свое
хранилище?
Распростарненные
случаи
•
«Делали
на
MySQL,
устали
–
теперь
хотим
чего-­‐либо
более
светлого»
•
«Делали
на
Postgres,
устали
–
теперь
хотим
чего-­‐либо
более
светлого»
•
«Не
репликация
а
черти
что»
•
«Не
смогли
научить
использовать
правильный
индекс»
•
«И
вообще
все
криво»
•
«Хотим
найти
все
циклы
в
произвольном
графе
и
чтобы
нам
за
это
ничего
не
было»

5. Зачем
писать
свое
хранилище?
Распростарненные
случаи
•
«Делали
на
MySQL,
устали
–
теперь
хотим
чего-­‐либо
более
светлого»
•
«Делали
на
Postgres,
устали
–
теперь
хотим
чего-­‐либо
более
светлого»
•
«Делали
на
Oracle,
устали
–
теперь
хотим
чего-­‐либо
более
светлого»
•
«Хотим
мультимастер
в
две
стороны»
•
«Не
смогли
научить
использовать
правильный
индекс»
•
«Очень
сложно,
Concepts
читать
долго,
много
воды»
•
«Хотим
перемножать
матрицы
за
O(1)
и
чтоб
золотая
рыбка
была
у
меня
на
посылках»

6. Зачем
писать
свое
хранилище?
Распростарненные
случаи
•
«Делали
на
MySQL,
устали
–
теперь
хотим
чего-­‐либо
более
светлого»
•
«Делали
на
Postgres,
устали
–
теперь
хотим
чего-­‐либо
более
светлого»
•
«Делали
на
Oracle,
устали
–
теперь
хотим
чего-­‐либо
более
светлого»
•
«Делали
на
DB2/MSSQL/Sybase
…
whatever»

7. Зачем
писать
свое
хранилище?
Распростарненные
случаи
•
«Делали
на
MySQL,
устали
–
теперь
хотим
чего-­‐либо
более
светлого»
•
«Делали
на
Postgres,
устали
–
теперь
хотим
чего-­‐либо
более
светлого»
•
«Делали
на
Oracle,
устали
–
теперь
хотим
чего-­‐либо
более
светлого»
•
«Делали
на
DB2/MSSQL/Sybase
…
whatever»
•
«А
давайте
запилим
что-­‐нибудь
высокотехнологичное
–
будем
как…»

8. Зачем
писать
свое
хранилище?
Распростарненные
случаи
•
«Делали
на
MySQL,
устали
–
теперь
хотим
чего-­‐либо
более
светлого»
•
«Делали
на
Postgres,
устали
–
теперь
хотим
чего-­‐либо
более
светлого»
•
«Делали
на
Oracle,
устали
–
теперь
хотим
чего-­‐либо
более
светлого»
•
«Делали
на
DB2/MSSQL/Sybase
…
whatever»
•
«А
давайте
запилим
что-­‐нибудь
высокотехнологичное
–
будем
как…»
•
«Чтоб
разгрузить
БД,
нужно
простенькое
быстрое
хранилище»
!!!

9. Вобщем
решили
писать
с
нуля
Ну
или
почти
с
нуля
–
не
суть
;-­‐)

10. Надежность
хранилища
Mission
cri>cal?
Перевод
денег
со
счета
на
счет
в
банке
Где
граница?
Порядок
постов
во
френдленте

11. Надежности
мешают
отказы
Хороший
термин
Failure,
переведем
его
как
Падение
•
Падает
железо
•
Падает
ПО
•
Непродуманый
дизайн
ПО
ведет
к
падениям
•
Нерадивый
админ
нажал
не
на
ту
кнопку
и
все
упало
Потенциальная
Случившаяся
Ошибка
Падение
проблема
проблема
(ошибка
которую
нельзя
обработать)

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

13. Добавляем
надежность
Простое
и
логичное
решение!
D1
D2
D3
Dm

14. Это
был
подход
«Чтобы
не
падало»
Почему
плохо
•
Сразу
две
проблемы
–
и
с
чтением
и
записью
•
Непроизводительно

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

16. Атомарность
D1
D2
Такая
последовательность
действий
восстановима

17. Конкурентный
доступ
S
=
1000RUR
send_money(S,
B,
100
)
A1
A1
затем
A2
или
send_money(S,
B,
200
)
A2
A2
затем
A1
S
=
900RUR
?
S
=
800RUR
?
S
=
700RUR
!

18. Конкурентный
доступ
S
=
1000RUR
send_money(S,
B,
100
)
A1
A1
затем
A2
или
send_money(S,
B,
200
)
A2
A2
затем
A1
S
=
900RUR
?
S
=
800RUR
?
Изоляция
S
=
700RUR
!

19. Конкурентный
доступ
S
=
1000RUR
send_money(S,
B,
100
)
A1
A1
затем
A2
или
send_money(S,
B,
200
)
A2
A2
затем
A1
S
=
900RUR
?
S
=
800RUR
?
Изоляция
S
=
700RUR
!
Восстановимость
+
изоляция
=
атомарность

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

21. Быстрая
восстановимость
•
Версии
D0
D1
VN
Если
все
действие
прошло
успешно,
А
если
упали
на
смене
VN?
достигнут
Commit
point

22. Быстрая
восстановимость
•
Версии
•
Пишем
лог
Изоляция/корректность
–
легко
без
производительности

23. T1
T2
r1[x]
w2[x]
w1[y]
w2[y]
-­‐
корректная
история
История
корректна
если
r1[x]
w2[x]
эквивалентна
Направление
стрелок
–
последовательному
w1[y]
w2[y]
порядок
выполненения
выполнению
транзакций
–
сериализуема
конфликтующих
действий
Граф
действий
/
граф
T2
конфликтов
T4
Некорректная
история
–
T1
Если
нет
циклов,
то
историю
на
которой
он
падение
и
нарушение
целостности
построенможно
T3
сериализовать

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

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

26. Нерассмотренные
важные
моменты
• Сеть и производительность
•
Мониторинг
•
capex/opex

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