PostgreSQL worst practices / Илья Космодемьянский (Data Egret)
0 likes345 views
Документ содержит список 'худших практик' работы с PostgreSQL, представленный Ильей Космодемьянским. Он включает в себя рекомендации, которые противоречат общепринятым правилам, например, избегание использования индексов и foreign keys, использование ORM, а также предпочтение загрузки данных параллельно и настройке оптимизатора. Главное внимание уделяется тому, как ошибочные подходы могут привести к проблемам с производительностью и надежностью базы данных.
![17. Код надо писать, читать его не обязательно! 19
genre_id IN
( SELECT id FROM genres WHERE genres.id IN
(SELECT * FROM unnest(array[155]))
)
dataegret.com](https://image.slidesharecdn.com/2-171113102736/85/PostgreSQL-worst-practices-Data-Egret-38-320.jpg)
PostgreSQL worst practices / Илья Космодемьянский (Data Egret)
- 2. Best practices - это уныло 2 • Никогда им не следуйте, попробуйте worst practices • Потомучто только worst practices позволяют по-настоящему все испортить • Будет о чем рассказать на Highload! • Консультанты по PostgreSQL - милейшие люди, они будут довольны dataegret.com
- 3. Как устроен этот доклад? 2 • У меня есть длинный список - больше 100 способов сделать больно базе данных и себе • Я ничего сам не придумал, это всё они! • Обычно я выбираю случайный набор этих способов для доклада • Ну на самом деле не вполне случайно - некоторые грабли я люблю больше • И потом некоторые грабли часто идут вместе dataegret.com
- 4. 0. Никогда не используйте индексы! (тестовый пример) 2 • И в самом деле - нет ни малейшей разницы между между seq scan и index scan • Это легко проверить: просто сделайте тестовую таблицу на 10 строк на вашем тестовом сервере и сами убедитесь • В продакшене у вас никогда не будет больше чем 10 строк! dataegret.com
- 5. 1. Чем больше count(*), тем лучше 3 • Цифра 301083021830123921 очень информативна и нужна вашим пользователям • Даже если через долю секунды она уже 30108302894839434020, это по прежнему информативно и нужно • select count(*) from sometable это простой и легкий для базы запрос • Приблизительная оценка из pg_catalog конечно же недостаточно точна для вас dataegret.com
- 6. 2. Используйте ORM 4 • Все базы данных используют единственный диалект SQL • Код должен быть универсальным независимо от того, с какой базой работаем • Кто слышал о каких-то там специфичных для определенной СУБД приемах улучшения прозводительности? • Новая навороченная технология - это всегда здорово! dataegret.com
- 7. 3. JOIN’ам в базе не место! 5 • Просто достаем по select * пару таблиц целиком в приложение, написанное на вашем любимом языке программирования • Теперь джойним все это прямо в приложении dataegret.com
- 8. 3. JOIN’ам в базе не место! 5 • Просто достаем по select * пару таблиц целиком в приложение, написанное на вашем любимом языке программирования • Теперь джойним все это прямо в приложении • Всё, что остается ”доделать” - это nested loop join, hash join и merge join ну и оптимизатор да page cache dataegret.com
- 9. 4. Будь модным, будь schema-less 6 • Вам не нужно дизайнить схему • Нужна просто одна таблица из двух колонок: id bigserial и extra jsonb • Тип JSONB в PostgreSQL очень эффективный, его можно мучать запросами точно так же как хорошо структурированную таблицу • Даже если в каждый JSONB вы положите 100M JSON • И даже если это будет 1000+ tps dataegret.com
- 10. 5. Будь гибким, используй EAV 7 • На самом деле нужно 3 таблицы: entity, attribute, value dataegret.com
- 11. 5. Будь гибким, используй EAV 7 • На самом деле нужно 3 таблицы: entity, attribute, value • На каком-то этапе неизбежно понадобится 4я: attribute_type dataegret.com
- 12. 5. Будь гибким, используй EAV 7 • На самом деле нужно 3 таблицы: entity, attribute, value • На каком-то этапе неизбежно понадобится 4я: attribute_type • И когда это все начнет тормозить, просто назовите эти 4 таблицы Ядро и добавьте к нему 1000+ денормализованных преставлений dataegret.com
- 13. 5. Будь гибким, используй EAV 7 • На самом деле нужно 3 таблицы: entity, attribute, value • На каком-то этапе неизбежно понадобится 4я: attribute_type • И когда это все начнет тормозить, просто назовите эти 4 таблицы Ядро и добавьте к нему 1000+ денормализованных преставлений • И если все же будет недостаточно меденно, добавьте value_version dataegret.com
- 14. 6. Чем больше создать индексов, тем лучше 8 • Индексы не занимают место на диске • Индексы не не занимают место в shared_bufers • С ростом количества индексов оверхэд на DML не растет • Если вы создали индекс, оптимизатор конечно же будет его использовать • Keep calm and create more indexes dataegret.com
- 15. 7. Даже если вы решили настроить backup своей базы... 9 • Вы всегда можете использовать в качестве оного дополнительную реплику dataegret.com
- 16. 7. Даже если вы решили настроить backup своей базы... 9 • Вы всегда можете использовать в качестве оного дополнительную реплику • Использовать pg_dump вместо pg_basebackup dataegret.com
- 17. 7. Даже если вы решили настроить backup своей базы... 9 • Вы всегда можете использовать в качестве оного дополнительную реплику • Использовать pg_dump вместо pg_basebackup • Написать свой собственный управляющий скрипт dataegret.com
- 18. 7. Даже если вы решили настроить backup своей базы... 9 • Вы всегда можете использовать в качестве оного дополнительную реплику • Использовать pg_dump вместо pg_basebackup • Написать свой собственный управляющий скрипт • Чем сложней, чем лучше - возьмите побольше сторонних приложений dataegret.com
- 19. 7. Даже если вы решили настроить backup своей базы... 9 • Вы всегда можете использовать в качестве оного дополнительную реплику • Использовать pg_dump вместо pg_basebackup • Написать свой собственный управляющий скрипт • Чем сложней, чем лучше - возьмите побольше сторонних приложений • И никогда, никогда не делайте тестовых восстановлений dataegret.com
- 20. 8. Первым делом выключите autovacuum 10 • Это просто вспомогательный процесс, его можно безболезненно выключить • Не будет никаких проблем если у вас в базе размером 1Tb всего 100Gb полезных данных • 2-3Tb RAM сейчас стоят дешего, IO это самый дешевый ресурс в современных компьютерах • Ну и потом все любят BigData dataegret.com
- 21. 9. Никогда не архивируйте старые данные 11 • Time series данные (таблицы логов, статистика посещений) никогда нельзя удалять, на всякий случай надо держать все! dataegret.com
- 22. 9. Никогда не архивируйте старые данные 11 • Time series данные (таблицы логов, статистика посещений) никогда нельзя удалять, на всякий случай надо держать все! • Во-первых, вы всегда будете знать куда смотреть, если закончилось место на диске dataegret.com
- 23. 9. Никогда не архивируйте старые данные 11 • Time series данные (таблицы логов, статистика посещений) никогда нельзя удалять, на всякий случай надо держать все! • Во-первых, вы всегда будете знать куда смотреть, если закончилось место на диске • BigData опять-таки, будет о чем рассказать на Highload dataegret.com
- 24. 9. Никогда не архивируйте старые данные 11 • Time series данные (таблицы логов, статистика посещений) никогда нельзя удалять, на всякий случай надо держать все! • Во-первых, вы всегда будете знать куда смотреть, если закончилось место на диске • BigData опять-таки, будет о чем рассказать на Highload • В конце концов вас всегда спасет партиционирование... partition на каждый час или на каждую минуту - самое то dataegret.com
- 25. 10. Переизобретите Slony 12 • Если вам нужно реплицировать данные - реализуйте свой метод репликации dataegret.com
- 26. 10. Переизобретите Slony 12 • Если вам нужно реплицировать данные - реализуйте свой метод репликации • Всегда есть минимум 10 аргументов, почему имеющиеся вам не подходят dataegret.com
- 27. 10. Переизобретите Slony 12 • Если вам нужно реплицировать данные - реализуйте свой метод репликации • Всегда есть минимум 10 аргументов, почему имеющиеся вам не подходят • И это дает потрясающую возможность прочувствовать все проблемы репликации в PostgreSQL которые случились с момента написания Slony dataegret.com
- 28. 11. Мастер и реплика должны жить на разном железе 13 • Это повысит шансы, что failover пойдет как-то не так dataegret.com
- 29. 11. Мастер и реплика должны жить на разном железе 13 • Это повысит шансы, что failover пойдет как-то не так • Чтобы было еще лучше - настройте на реплике только параметры реплики, ну и оставьте дефолтные shared_buffers. dataegret.com
- 30. 12. Синхронную реплику - в другой ДЦ 14 • Ну конечно, high availability! dataegret.com
- 31. 12. Синхронную реплику - в другой ДЦ 14 • Ну конечно, high availability! • Особенно, если реплика на другом континенте dataegret.com
- 32. 13. Никогда не используйте Foreign Keys 15 • Контроль целостности на стороне приложения всегда работает так, как думают его авторы • Никогда и ничего не будет потеряно, если у вас нет констрейнтов • СУБД это проверенный веками framework для поддержания целостности, но кого когда это останавливало? dataegret.com
- 33. 14. Самый правильный тип данных это text 16 • Всегда интересно написать свою валидацию дат или IP-адресов в приложении • Как еще переконвертировать ”12-31-2015 03:01AM” в например ”15:01 12 of undef 2015” используя специализированные типы? dataegret.com
- 34. 15. Всегда используйте ”улучшенную” версию PostgreSQL 17 • Ванильный PostgreSQL не идеален, кому как ни вам этого не знать • Все вот это вот унылое MVCC, 32 bit xid и autovacuum, бессмысленный и беспощадный, это потому что хакеры зашоренные ретрограды и не видят гениального в простоте • К черту их с их сообществом, напишите patch и сразу в продакшн • У вас никогда не возникнет проблем бежать следом за развитеим ванильного PostgreSQL dataegret.com
- 35. 16. Postgres любит динные транзакции 18 • Хранимка - это правильное место, откуда вызывать внешний сервис dataegret.com
- 36. 16. Postgres любит динные транзакции 18 • Хранимка - это правильное место, откуда вызывать внешний сервис • Ну тут можно поспортить... можно было бы, если бы 100% разработчиков знало слово таймаут dataegret.com
- 37. 16. Postgres любит динные транзакции 18 • Хранимка - это правильное место, откуда вызывать внешний сервис • Ну тут можно поспортить... можно было бы, если бы 100% разработчиков знало слово таймаут • В любом случае, открыть транзакцию и пойти пить пиво всегда хорошая идея dataegret.com
- 38. 17. Код надо писать, читать его не обязательно! 19 genre_id IN ( SELECT id FROM genres WHERE genres.id IN (SELECT * FROM unnest(array[155])) ) dataegret.com
- 39. 18. Есть проблемы с PostgreSQL? 20 • Любые проблемы можно решить с помощью контейнеров! dataegret.com
- 40. 18. Есть проблемы с PostgreSQL? 20 • Любые проблемы можно решить с помощью контейнеров! • Которые нельзя - надо решать с помощью облаков dataegret.com
- 41. 18. Есть проблемы с PostgreSQL? 20 • Любые проблемы можно решить с помощью контейнеров! • Которые нельзя - надо решать с помощью облаков • Оптимизация запросов - прошлый век! dataegret.com
- 42. 19. Переизобретать нужно не только Slony! 21 • Сконвертировать timestamp? Хранимая процедура на C! dataegret.com
- 43. 19. Переизобретать нужно не только Slony! 21 • Сконвертировать timestamp? Хранимая процедура на C! • Очередь сообщений? Пишем свою! dataegret.com
- 44. 19. Переизобретать нужно не только Slony! 21 • Сконвертировать timestamp? Хранимая процедура на C! • Очередь сообщений? Пишем свою! • Не нашли подходящий ORM? Пишем свой на plpgsql dataegret.com
- 45. 20. Никогда не используйте exceptions! 22 • В документации написано что они всё замедляют dataegret.com
- 46. 20. Никогда не используйте exceptions! 22 • В документации написано что они всё замедляют • Используйте raise notice при ошибках - все всегда читают логи! dataegret.com
- 47. 20. Никогда не используйте exceptions! 22 • В документации написано что они всё замедляют • Используйте raise notice при ошибках - все всегда читают логи! • Зачем вообещ приложению знать об ошибках? dataegret.com
- 48. 20. Никогда не используйте exceptions! 22 • В документации написано что они всё замедляют • Используйте raise notice при ошибках - все всегда читают логи! • Зачем вообещ приложению знать об ошибках? • Лучше их вообще suppress! dataegret.com
- 49. 21. Приложению не хватает соединений с базой? 23 • Выставляем max_connections в 1000 dataegret.com
- 50. 21. Приложению не хватает соединений с базой? 23 • Выставляем max_connections в 1000 • Ну да, сервера с 1000 CPU теперь дешевые dataegret.com
- 51. 21. Приложению не хватает соединений с базой? 23 • Выставляем max_connections в 1000 • Ну да, сервера с 1000 CPU теперь дешевые • Оверхэд на создание worker’а PostgreSQL? Нет, не слышали! dataegret.com
- 52. 21. Приложению не хватает соединений с базой? 23 • Выставляем max_connections в 1000 • Ну да, сервера с 1000 CPU теперь дешевые • Оверхэд на создание worker’а PostgreSQL? Нет, не слышали! • И никогда, никогда не используйте pgbouncer! dataegret.com
- 53. 22. Вместо него используйте pgpool-II 24 • pgpool очень прост в использовании, особенно как пул... dataegret.com
- 54. 22. Вместо него используйте pgpool-II 24 • pgpool очень прост в использовании, особенно как пул... • Почти как текстовый редактор в операционной системе Emacs... dataegret.com
- 55. 22. Вместо него используйте pgpool-II 24 • pgpool очень прост в использовании, особенно как пул... • Почти как текстовый редактор в операционной системе Emacs... • Простой конфиг, все фичи полезны dataegret.com
- 56. 22. Вместо него используйте pgpool-II 24 • pgpool очень прост в использовании, особенно как пул... • Почти как текстовый редактор в операционной системе Emacs... • Простой конфиг, все фичи полезны • Как консультант, я его очень люблю! dataegret.com
- 57. 23. Всегда, начинайте настраивать PostgreSQL... 25 • С настроект оптимизатора в postgresql.conf dataegret.com
- 58. 23. Всегда, начинайте настраивать PostgreSQL... 25 • С настроект оптимизатора в postgresql.conf • Забудьте про shared_buffers и checkpoint’ы! dataegret.com
- 59. 23. Всегда, начинайте настраивать PostgreSQL... 25 • С настроект оптимизатора в postgresql.conf • Забудьте про shared_buffers и checkpoint’ы! • geqo - вот с чего надо начинать! dataegret.com
- 60. 24. Новая классная фича? 26 • Сразу в продакшн! dataegret.com
- 61. 24. Новая классная фича? 26 • Сразу в продакшн! • Кто знает про доклад MVCC Unmasked Брюса Момжана? ( Кто не знает, найдите на YouTube) dataegret.com
- 62. 24. Новая классная фича? 26 • Сразу в продакшн! • Кто знает про доклад MVCC Unmasked Брюса Момжана? ( Кто не знает, найдите на YouTube) • Там есть про метаколонки xmin и xmax dataegret.com
- 63. 24. Новая классная фича? 26 • Сразу в продакшн! • Кто знает про доклад MVCC Unmasked Брюса Момжана? ( Кто не знает, найдите на YouTube) • Там есть про метаколонки xmin и xmax • Постройте не них логику вашего приложения! dataegret.com
- 64. 25. Никогда не используйте графический мониторинг 27 • Графики не нужны! • Вы и без них будете знать что произошло позавчера в 02:04 ночи с bgwriter dataegret.com
- 65. 26. Загружайте данные в PostgreSQL изошренно! 28 • Напишите loader, 100 параллельных потоков минимум dataegret.com
- 66. 26. Загружайте данные в PostgreSQL изошренно! 28 • Напишите loader, 100 параллельных потоков минимум • Никога не используйте COPY - эта штука специально предназначена для этого dataegret.com
- 67. Не забывайте 29 That was WORST practices talk dataegret.com
- 68. Поделитесь своими любимыми worst practice! 30 [email protected] dataegret.com