#databases #postgres
Немного лучших практик Постгрес в ленту.
https://www.youtube.com/watch?v=0_CwH_lrPp0&ab_channel=HighLoadChannel
ORM: не пробовал, ни разу не увидел выгоды от них. Может, просто не разобрался.
Репликация: знаю интересный кейс с pg_logical: https://habr.com/en/company/alfa/blog/539350/.
Партицирование: для меня хорошо сработало расширение TimescaleDB, сделанное, по словам Панченко, на основе pg_partman. Не только создаёт партиции автоматически, но и может архивировать их, имеет мощные time_bucket функции. Пока не работает с PG15 (решают). На голову выше коробочного партицирования: не засоряет схему тысячами партиций (потому что пишет в отдельную схемку), не требует ручного создания разделов, поддерживает политики управления данных. Прозрачный бэкап, единственное, при восстановлении расширение уже должно стоять. Если у Вас (будет) большая база, сразу используйте таймскейл. Уж тем более, если данные представляют собой временные ряды - сам Бог велел.
По шардингу: в TimescaleDB он есть, но я ещё не пробовал. Распределённая гипертаблица сразу же подпадает под значительное число ограничений (https://docs.timescale.com/timescaledb/latest/overview/limitations/#distributed-hypertable-limitations). Citus/Greenplum было бы интересно попробовать тоже.
Config tuning: вот тут у постгреса (да и почти всех остальных СУБД) слабое место, разработчики ядра очень консервативны. Казалось бы, век информации, ML, DS, AI, а тут на тебе, СУБД даже не может посчитать сама оптимальные параметры для железа, на котором запущена, я уже не говорю о динамическом перераспределении параметров в зависимости от нагрузки. На Хабре даже ругался по этому поводу: https://habr.com/en/post/444018/, https://habr.com/en/post/458952/. Опять же, таймскейл предлагает при установке свои настройки в конфиг, не тестировал их преимуществ, но от дефолтных они сильно отличаются, это точно.
Немного лучших практик Постгрес в ленту.
https://www.youtube.com/watch?v=0_CwH_lrPp0&ab_channel=HighLoadChannel
ORM: не пробовал, ни разу не увидел выгоды от них. Может, просто не разобрался.
Репликация: знаю интересный кейс с pg_logical: https://habr.com/en/company/alfa/blog/539350/.
Партицирование: для меня хорошо сработало расширение TimescaleDB, сделанное, по словам Панченко, на основе pg_partman. Не только создаёт партиции автоматически, но и может архивировать их, имеет мощные time_bucket функции. Пока не работает с PG15 (решают). На голову выше коробочного партицирования: не засоряет схему тысячами партиций (потому что пишет в отдельную схемку), не требует ручного создания разделов, поддерживает политики управления данных. Прозрачный бэкап, единственное, при восстановлении расширение уже должно стоять. Если у Вас (будет) большая база, сразу используйте таймскейл. Уж тем более, если данные представляют собой временные ряды - сам Бог велел.
По шардингу: в TimescaleDB он есть, но я ещё не пробовал. Распределённая гипертаблица сразу же подпадает под значительное число ограничений (https://docs.timescale.com/timescaledb/latest/overview/limitations/#distributed-hypertable-limitations). Citus/Greenplum было бы интересно попробовать тоже.
Config tuning: вот тут у постгреса (да и почти всех остальных СУБД) слабое место, разработчики ядра очень консервативны. Казалось бы, век информации, ML, DS, AI, а тут на тебе, СУБД даже не может посчитать сама оптимальные параметры для железа, на котором запущена, я уже не говорю о динамическом перераспределении параметров в зависимости от нагрузки. На Хабре даже ругался по этому поводу: https://habr.com/en/post/444018/, https://habr.com/en/post/458952/. Опять же, таймскейл предлагает при установке свои настройки в конфиг, не тестировал их преимуществ, но от дефолтных они сильно отличаются, это точно.
YouTube
Postgres Highload Checklist / Иван Панченко (Postgres Professional)
Saint HighLoad++ 2019
Тезисы и презентация:
https://www.highload.ru/spb/2019/abstracts/4433
* Почему СУБД часто становится узким местом проекта, и как этого избежать?
* Как снизить нагрузку на СУБД? Как распределить (расшардить) её?
...
--------
Нашли ошибку…
Тезисы и презентация:
https://www.highload.ru/spb/2019/abstracts/4433
* Почему СУБД часто становится узким местом проекта, и как этого избежать?
* Как снизить нагрузку на СУБД? Как распределить (расшардить) её?
...
--------
Нашли ошибку…
#databases #postgres
А тем временем вышла 17-я постгре! Много улучшений. Я не понимаю, как у них поднимается рука релизить заведомо слабые решения, а потом течение лет и десятилетий их постепенно допиливать, но хоть так.
https://www.postgresql.org/about/news/postgresql-17-beta-1-released-2865/
А тем временем вышла 17-я постгре! Много улучшений. Я не понимаю, как у них поднимается рука релизить заведомо слабые решения, а потом течение лет и десятилетий их постепенно допиливать, но хоть так.
https://www.postgresql.org/about/news/postgresql-17-beta-1-released-2865/
PostgreSQL News
PostgreSQL 17 Beta 1 Released!
The PostgreSQL Global Development Group announces that the first beta release of PostgreSQL 17 is now [available for download](https://www.postgresql.org/download/). This …