Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

10 способов достижения HighLoad'а и BigData на ровном месте / Илья Космодемьянский (PostgreSQL-Consulting LLC)

1,284 views

Published on

Веб-сайт нужно делать так, чтобы о перипетиях его разработки и поддержки бессонными ночами через пару лет можно было рассказать на конференции Highload++, а тамошнюю аудиторию сложно удивить велосипедом с треугольными каменными колесами. Большинство разработчиков свято следуют этому принципу то ли в силу природной любознательности и трудолюбия, то ли по причине отсутствия конференции LowLoad--.

Примерно такие мысли приходят в голову практически любому специалисту по хранилищам данных, когда он видит успешный веб-проект, испытывающий стандартные проблемы с базой данных.

В этом докладе я расскажу о 10-ти очень распространенных ошибках проектирования и эксплуатации хранилища в веб-проекте — от преждевременного шардирования базы и непродуманной системы архивации ненужных данных до особенностей работы всеми любимых фреймворков. Про каждую из них я расскажу подробно и поделюсь рецептами, как такие ошибки исправлять.

Published in: Engineering
  • Be the first to comment

10 способов достижения HighLoad'а и BigData на ровном месте / Илья Космодемьянский (PostgreSQL-Consulting LLC)

  1. 1. 10 способов достижения HighLoad'а и BigData на ровном месте Илья Космодемьянский ik@postgresql-consulting.com
  2. 2. С базами данных бывает две главных проблемы • То, что должно лежать в базе, лежит не в базе • То что не должно лежать в базе, тем не менее лежит в базе
  3. 3. 1. Масштабирование • Масштабирование это хорошо • Потому что хорошо • Все знают что scale-out это хорошо, а scale up - плохо
  4. 4. 1. Масштабирование • Типичный случай: • У нас будет миллион пользователей • Давайте поставим 100 инстансов PostgreSQL и будем шардить по created_at • Собрать данные о пользователях на разных нодах – боль • Ой, а у нас 100% утилизованы 10 машин кластера, а 90 не заняты вообще ничем • Ой, а когда мы обращаемся к незанятой машине запрос почему-то выполняется в разы дольше • Ой, шардить надо было по user_id • Нам снова есть чем заняться • А давайте подумаем, так ли это много, 1M пользователей для одного инстанса PostgreSQL на современном железе
  5. 5. 2. Бизнес хочет хранить данные за все время© • Тайм-сериал статистика, прирост 100500 тысяч строк в день • Строим агрегаты для отчетов • Через несколько лет получаем BIG data • Зачем нам данные за все время? • Почему нельзя в нагруженной базе держать агрегаты + свежи данные, а остальное держать в архиве?
  6. 6. 3. EAV упрощает проектирование • Entity–attribute–value • Все данные лежат в 3-4 гигантских таблицах • Эти таблицы надо джойнить друг с другом • Как результат – EAV гордо переименовывается в ядро и обрастает витринами и представлениями с денормазованными данными в реляционном виде • Проектирование упрощено до предела • Чтобы его упростить, приходится выкидывать «ядро»
  7. 7. 4. ORM упрощает разработку • Универсальный способ убить производительность любой базы • Например SELECT * FROM foo where ID IN(123,355,2,4,6,90,35, … )
  8. 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. 9. 6. JOIN это зло – они медленные • Вытягиваем в контроллер две таблицы из базы • Джойним их средствами нашего любимого языка программирования • Добавляем выбор алгоритма – nested loop, hash, merge и получаем самодельную базы данных, только плохую
  10. 10. 7. Давайте изобретем Slony • Существующих методов репликации баз данных явно недостаточно • Давайте изобретем что-нибудь новое
  11. 11. 8. У меня в тесте все работает • Хороший разработчик знает что нужно использовать EXPLAIN • Он его и использует – у себя на dev-машине • А на продакшне внезапно данных в 1000 раз больше! • А еще бывают админы, которые стараются на пушечный выстрел не подпустить разработку к продакшну
  12. 12. 9. Be smart, as a java-developer! • Параллелизм это быстро. Нужно сделать много апдейтов в базе – давайте делать это в 500 трэдов • SQL-запрос через ко-рутины python может быть в 10 раз медленней чем без них
  13. 13. 10. Приятные мелочи • Если запрос возвращает 1M строк, то: • Он никогда не будет работать достаточно быстро для веба • А зачем для веба такой запрос? • 20 счетчиков с count(*) на главной странице сайта • Не нужны • Никогда не будут работать быстро • Know your data!
  14. 14. Вопросы? ik@postgresql-consulting.com

×