Документ описывает 10 способов достижения highload'а и управления big data в контексте использования баз данных, акцентируя внимание на проблемах масштабирования, хранения данных и производительности. Автор выделяет проблемы, такие как неправильно организованное шардирование, избыточное хранение данных и ограничения ORM, а также предлагает альтернативные подходы к проектированию и репликации баз данных. В конце приводятся советы о том, как избежать распространенных ошибок и оптимизировать работу с данными.

1. 10 способов достижения
HighLoad'а и BigData на
ровном месте
Илья Космодемьянский
ik@postgresql-consulting.com

2. С базами данных бывает две главных
проблемы
• То, что должно лежать в базе, лежит не в базе
• То что не должно лежать в базе, тем не менее лежит в базе

3. 1. Масштабирование
• Масштабирование это хорошо
• Потому что хорошо
• Все знают что scale-out это хорошо, а scale up - плохо

4. 1. Масштабирование
• Типичный случай:
• У нас будет миллион пользователей
• Давайте поставим 100 инстансов PostgreSQL и будем шардить по created_at
• Собрать данные о пользователях на разных нодах – боль
• Ой, а у нас 100% утилизованы 10 машин кластера, а 90 не заняты вообще ничем
• Ой, а когда мы обращаемся к незанятой машине запрос почему-то выполняется
в разы дольше
• Ой, шардить надо было по user_id
• Нам снова есть чем заняться
• А давайте подумаем, так ли это много, 1M пользователей для одного
инстанса PostgreSQL на современном железе

5. 2. Бизнес хочет хранить данные за все
время©
• Тайм-сериал статистика, прирост 100500 тысяч строк в день
• Строим агрегаты для отчетов
• Через несколько лет получаем BIG data
• Зачем нам данные за все время?
• Почему нельзя в нагруженной базе держать агрегаты + свежи
данные, а остальное держать в архиве?

6. 3. EAV упрощает проектирование
• Entity–attribute–value
• Все данные лежат в 3-4 гигантских таблицах
• Эти таблицы надо джойнить друг с другом
• Как результат – EAV гордо переименовывается в ядро и обрастает
витринами и представлениями с денормазованными данными в
реляционном виде
• Проектирование упрощено до предела
• Чтобы его упростить, приходится выкидывать «ядро»

7. 4. ORM упрощает разработку
• Универсальный способ убить производительность любой базы
• Например SELECT * FROM foo where ID IN(123,355,2,4,6,90,35, … )

8. 5. Главное зло в PostgreSQL - autovacuum
• Он постоянно работает и всему мешает
• А давайте его выключим?
• Фрагментированная таблица на 100К строк занимает 100Gb или
даже больше
• Big Data – есть о чем рассказать!
• Подробности: http://www.slideshare.net/PostgreSQL-
Consulting/autovacuum-explained-for-engineers-new-improved-
version-pgconfeu-2015-vienna

9. 6. JOIN это зло – они медленные
• Вытягиваем в контроллер две таблицы из базы
• Джойним их средствами нашего любимого языка
программирования
• Добавляем выбор алгоритма – nested loop, hash, merge и
получаем самодельную базы данных, только плохую

10. 7. Давайте изобретем Slony
• Существующих методов репликации баз данных явно
недостаточно
• Давайте изобретем что-нибудь новое

11. 8. У меня в тесте все работает
• Хороший разработчик знает что нужно использовать EXPLAIN
• Он его и использует – у себя на dev-машине
• А на продакшне внезапно данных в 1000 раз больше!
• А еще бывают админы, которые стараются на пушечный выстрел
не подпустить разработку к продакшну

12. 9. Be smart, as a java-developer!
• Параллелизм это быстро. Нужно сделать много апдейтов в базе –
давайте делать это в 500 трэдов
• SQL-запрос через ко-рутины python может быть в 10 раз
медленней чем без них

13. 10. Приятные мелочи
• Если запрос возвращает 1M строк, то:
• Он никогда не будет работать достаточно быстро для веба
• А зачем для веба такой запрос?
• 20 счетчиков с count(*) на главной странице сайта
• Не нужны
• Никогда не будут работать быстро
• Know your data!

14. Вопросы?
ik@postgresql-consulting.com