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»
•
«А
давайте
запилим
что-‐нибудь
высокотехнологичное
–
будем
как…»
•
«Чтоб
разгрузить
БД,
нужно
простенькое
быстрое
хранилище»
!!!
10. Надежность
хранилища
Mission
cri>cal?
Перевод
денег
со
счета
на
счет
в
банке
Порядок
постов
во
френдленте
Где
граница?
11. Надежности
мешают
отказы
Хороший
термин
Failure,
переведем
его
как
Падение
•
Падает
железо
•
Падает
ПО
•
Непродуманый
дизайн
ПО
ведет
к
падениям
•
Нерадивый
админ
нажал
не
на
ту
кнопку
и
все
упало
Потенциальная
проблема
Случившаяся
проблема
Ошибка
Падение
(ошибка
которую
нельзя
обработать)
14. Это
был
подход
«Чтобы
не
падало»
Почему
плохо
•
Сразу
две
проблемы
–
и
с
чтением
и
записью
•
Непроизводительно
15. Быстро
поднятое
не
считается
упавшим
•
Исходим
из
того,
что
система
всё
равно
когда-‐нибудь
может
упасть
•
Минимизируем
потери
16. Атомарность
D1
D2
Такая
последовательность
действий
восстановима
17. Конкурентный
доступ
S
=
1000RUR
send_money(S,
B,
100
)
A1
send_money(S,
B,
200
)
A2
S
=
900RUR
?
S
=
800RUR
?
S
=
700RUR
!
A1
A1
A2
A2
затем
затем
или
18. Конкурентный
доступ
S
=
1000RUR
send_money(S,
B,
100
)
A1
send_money(S,
B,
200
)
A2
S
=
900RUR
?
S
=
800RUR
?
S
=
700RUR
!
A1
A1
A2
A2
затем
затем
или
Изоляция
19. Конкурентный
доступ
S
=
1000RUR
send_money(S,
B,
100
)
A1
send_money(S,
B,
200
)
A2
S
=
900RUR
?
S
=
800RUR
?
S
=
700RUR
!
A1
A1
A2
A2
затем
затем
или
Изоляция
Восстановимость
+
изоляция
=
атомарность
20. Свойства
действий
с
блоками
данных
•
Атомарность
•
Целостность
–
набор
правил
для
данных
•
Долговечность
Действие,
обладающее
такими
свойствами
есть
транзакция
21. Быстрая
восстановимость
•
Версии
D0
D1
VN
А
если
упали
на
смене
VN?
Если
все
действие
прошло
успешно,
достигнут
Commit
point
23. T1
T2
r1[x]
w2[x]
w2[y]
w1[y]
w2[y]
w1[y]
r1[x]
w2[x]
-‐
корректная
история
Направление
стрелок
–
порядок
выполненения
конфликтующих
действий
История
корректна
если
эквивалентна
последовательному
выполнению
транзакций
–
сериализуема
T2
T3
T4
T1
Граф
действий
/
граф
конфликтов
Если
нет
циклов,
то
историю
на
которой
он
построенможно
сериализовать
Некорректная
история
–
падение
и
нарушение
целостности
24. 2PL
•
с
конфликтами
борятся
блокировками
–
блокирующий
шедулер
•
двухфазное
блокирование
–
сначала
выставляем
все
блокировки,
ни
одна
блокировка
не
может
быть
снята
пока
не
выставлены
все
•
С
помощью
2PL
мы
добиваемся
изоляции
при
сохранении
производительности
25. Мы
построили
хранилище
на
отдельно
взятой
машине
•
Объективно
машина
не
справляется.
Что
дальше?
•
Scale
out
–
репликация
и
шардинг
•
Асинхронный
месседжинг
–
очереди
–
что
они
дают
•
Распределенные
транзакции
–
если
до
этого
было
еще
не
страшно
27. Возвращаемся
к
постановке
задачи
• Данные не должны браться из ниоткуда и не должны пропадать
• Данные связаны между собой
•
Устранены-‐ли
проблемы
по
которым
нас
не
устраивала
СУБД
•
Сколько
мы
на
это
все
потратитли
и
сколько
еще
потратим?
