#dotnetby meetup - 32 Как и зачем готовить ’кластерные’ СУБД
- 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
- 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 • Перевозить много – дорого • Лучше расти постепенно
- 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
- 29. Выводы • Шарды проще добавлять • Подготовка всё равно требуется 29
- 30. Бэкапы обязательны* • Каждый шард бэкапим • Бэкапы тестируем 30
- 31. Репликация • Иногда заменяет бэкапы* • Иногда помогает в масштабировании 31
- 34. Репликация: антипаттерн • Конфликты • Запись не масштабируется: WAL! 34
- 35. Шардинг: антипаттерны • По дате • Mod • Автоматический* 35
- 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
- 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