10 способов достижения HighLoad'а и BigData на ровном месте / Илья Космодемьянский (PostgreSQL-Consulting LLC)
1 like1,840 views
Документ описывает 10 способов достижения highload'а и управления big data в контексте использования баз данных, акцентируя внимание на проблемах масштабирования, хранения данных и производительности. Автор выделяет проблемы, такие как неправильно организованное шардирование, избыточное хранение данных и ограничения ORM, а также предлагает альтернативные подходы к проектированию и репликации баз данных. В конце приводятся советы о том, как избежать распространенных ошибок и оптимизировать работу с данными.
10 способов достижения HighLoad'а и BigData на ровном месте / Илья Космодемьянский (PostgreSQL-Consulting LLC)
- 1. 10 способов достижения HighLoad'а и BigData на ровном месте Илья Космодемьянский [email protected]
- 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 гордо переименовывается в ядро и обрастает витринами и представлениями с денормазованными данными в реляционном виде • Проектирование упрощено до предела • Чтобы его упростить, приходится выкидывать «ядро»
- 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!