Вводный доклад в кластерные СУБД. Зачем нужна репликация, шардирование. Сложность: легко

1. Как и зачем готовить
«кластерные» СУБД?
Анатолий Попов
Director of Engineering
IDT Minsk (net2phone)

2. Повестка дня
• Зачем нужны кластерные СУБД?
• Примеры (если успеем), на самом деле нет
2

3. Обо мне
•Программирую с 2006 года
•Закрывал роль DBA с 2010 по 2018й год
3

4. Зачем программисту знать о СУБД?
• Структуры данных определяют ваш код
• Изменение структуры данных – дорого
• Код практически ничего не стоит*
4

5. Термины
• Replica set – набор реплик одного набора данных
• Шард – replica set, который хранит часть вашей СУБД
• Кластер – набор шардов
5

6. Сколько у вас данных?
1 GB+
6

7. Сколько у вас данных?
10 GB+
7

8. Сколько у вас данных?
100 GB+
8

9. Сколько у вас данных?
1 TB+
9

10. Один шард
• Microsoft SQL Server
• ~100 ГБ данных, 10М строк
• 96-128 ГБ ОЗУ
• 16 ядер
10

11. Один шард (Key-Value)
• ~5 ТБ
• 10М+ файлов
• Смигрировали в S3
11

12. Один шард знакомого
• Microsoft SQL Server
• 50-70 ТБ данных, 10 млрд+ записей
• 4 ТБ ОЗУ
• 8 сетевух
12

13. Зачем нам кластера?
13

14. Поехали в облака!
14

15. СУБД требует
• Гарантированной памяти
• Гарантированных IOPS
• Сеть, CPU – вторично
• Спот-инстансы вряд ли подойдут
15

16. Стоимость
• Server: 4 TB RAM, 4 TB SSD
• Instance Type: x1e.32xlarge (~4 TB RAM, ~4 TB SSD)
• Rent: 32 GB RAM, 256 GB SSD
16

17. Стоимость
17
0
100
200
300
400
500
600
700
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
Price of hardware stack, ~4 TB RAM, ~4 TB SSD
Server Cloud Cloud, 1y Rent

18. Стоимость
18
0
500
1000
1500
2000
2500
3000
3500
4000
4500
0
20
40
60
80
100
120
140
160
180
200
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
Gradual growth of needed RAM and SSD up to 4 TB
RAM Server Rent Cloud

19. Выводы
19
• Перевозить много – дорого
• Лучше расти постепенно

20. Добавление железки, обычно
20

21. Добавление железки, обычно
21

22. Добавление железки, обычно
22

23. Добавление железки, обычно
23

24. Добавление железки, обычно
24

25. Сколько это занимает?
25
14.22
1.42
-
5.00
10.00
15.00
20.00
25.00
30.00
35.00
100 1000 10000
Replication time in hours
100 1000 5000

26. Добавление железки, хочется
26

27. Добавление железки, хочется
27

28. Добавление железки, хочется
28

29. Выводы
• Шарды проще добавлять
• Подготовка всё равно требуется
29

30. Бэкапы обязательны*
• Каждый шард бэкапим
• Бэкапы тестируем
30

31. Репликация
• Иногда заменяет бэкапы*
• Иногда помогает в масштабировании
31

32. Репликация: идеал
32

33. Репликация: антипаттерн
33

34. Репликация: антипаттерн
• Конфликты
• Запись не масштабируется: WAL!
34

35. Шардинг: антипаттерны
• По дате
• Mod
• Автоматический*
35

36. Шардинг
• Корзины
• Размер
36

37. Шардинг: размер
• Неструктурированные данные – да
• Структурированные данные – нет
37

38. Шардинг: корзины
• Остаток от деления
• Дата
• Количество строк
38

39. Шардинг: по дате
39
Date-based sharding
Size

40. Шардинг: изменение остатка
40
1, 3, 5, 7, 9, 11 2, 4, 6, 8, 10, 12

41. Шардинг: изменение остатка
41
1, 3, 5, 7, 9, 11 2, 4, 6, 8, 10, 12

42. Шардинг: изменение остатка
42
1, 4, 7, 10 2, 5, 8, 11
3, 6, 9, 12

43. Шардинг: остаток
• Выбираем очень большой
• Redis: 16384
• Tarantool.VSHard: 3000
43

44. Шардинг: автоматический
44

45. Шардинг: неавтоматический
45
5
5
5
5
5
5
5

46. Шардинг: неавтоматический
46
1, 3, 5, 7, 9, 11 2, 4, 6, 8, 10, 12

47. Шардинг: неавтоматический
47
1, 3, 5, 7, 9, 11 2, 4, 6, 8, 10, 12

48. Шардинг: неавтоматический
48
1, 3, 5, 7, 9, 11 2, 4, 6, 8, 10
12

49. Шардинг: неавтоматический
• Redis: {hash}:key_part
• tarantool/vshard: bucket_id
49

50. Выводы
• Репликация => read scale
• Шардинг => read & write scale
• Шардинг => сразу много шардов
50

51. Литература
• “Designing Data-Intensive Applications” Martin Kleppmann
• https://about.gitlab.com/2017/02/10/postmortem-of-database-
outage-of-january-31/
• https://habr.com/ru/company/mailru/blog/436916/
• Elasticsearch 1 shard by default
51