Pull to refresh
5
0
Vitaliy Kukharik @Vitaly2606

Founder & CTO at autobase.tech

Send message

UPD: проект postgresql_cluster переименован в autobase. Теперь продукт называется Autobase for PostgreSQL®.

Не надо ничего бояться, надо жить и улыбаться :)

Мы разместили проект на Product Hunt: https://www.producthunt.com/posts/postgresql-cluster-org

Буду благодарен за вашу поддержку!

Этот отзыв действительно от пользователя, который работает с нашим продуктом, я не просил его оставлять.

Спасибо за отзыв! Рад, что инструментарий полезен для Вас.

Была когда то мысль тоже большую базу (более 30TB) запихнуть в ZFS для сжатия, но решил попробовать timescaledb расширение задействовать его компрессию (детали https://www.timescale.com/blog/time-series-compression-algorithms-explained/), поскольку данные time siries это оказалось подходящее решение. В результате пожал данные более чем в 10 раз (пример https://twitter.com/vkukharik/status/1396827117976002560?s=61&t=-fTOgLwm9frBPcq560_sEA) и примерно во столько же уменьшилось время выполнения аналитических запросов (пример https://twitter.com/vkukharik/status/1397552808514179073?s=61&t=U-YnfyEoacmBtZ1qkWjOPQ) поскольку меньше сидели в disk I/O в пользу CPU (запаса ресурсов cpu было достаточно).

Отличная статья, спасибо!

Чуть более года назад тоже разбирались с проблемой связанной с подтранзакциями в нагруженной системе. Я тестировал патч v17 - https://gitlab.com/postgres-ai/postgresql-consulting/tests-and-benchmarks/-/issues/22

В результате была написана статья, рекомендую почитать https://postgres.ai/blog/20210831-postgresql-subtransactions-considered-harmful

Смотрю уже доступен патч v24, надо будет выделить время и проверить что изменилось. А пока, пришли к выводу что надо выпиливать использование подтранзакций в нагруженных системах.

При этом используется pg_basebackup. Если существующая база — большая, может потребоваться много времени для завершения этой операции. Например, в реальном кейсе, который дал начало этой статье, была база объёмом в 2,8 ТБ, и её бутстрап занимал около 10 часов на гигабитном канале.

Наливайте ваши реплики из бэкапа, пример pgbackrest, или wal_g, или pg_probackup). Таким образом Вы избавляете узлы текущего кластера от дополнительной нагрузки вызванной копированием данных с помощью basebackup. Параметр create_replica_methods - https://patroni.readthedocs.io/en/latest/replica_bootstrap.html#building-replicas

У меня обычно это сводится к одной команде: ansible-playbook add_pgnode.yml

Желательно выносить ETCD кластер на отдельные сервера. Это даст несколько преимуществ:

  1. Упрощение администрирования. Например, перезапуск сервера без влияния на работу кластера etcd

  2. Возможность использовать один кластер etcd для нескольких кластеров Patroni

  3. Снижение рисков ухудшения стабильности кластера etcd, вызванного скачками нагрузки на базу данных.

@Kilorбольшое Вам спасибо!

Я давно мечтаю о подобном инструменте для мониторинга и детального анализа Query Plans.

у проекта pgwatch2 свое видение дашбордов, у меня другое. Переделывал лично для себя, и уже несколько лет развивается параллельно, по части метрик и дашбордов, сам код сборщика не менял.

Либо просто запустить pgwatch2 Postgres.ai Edition - https://gitlab.com/postgres-ai/pgwatch2 который уже содержит множество "полезных SQL-запросов" и получить графики состояния базы данных (в Grafana) за неделю, месяц, и год (при необходимости).

Demo: https://pgwatch.postgres.ai

demo/demo

вот мастер-класс от авторов проекта (в том числе о алгоритме работы Patroni) - https://pgconf.ru/2018/108567

а вот автоматизация деплая таких кластеров - https://github.com/vitabaks/postgresql_cluster

Логическое декодирование применимо при не больших нагрузках. Когда мы говорим о 2 и более WAL в секунду то уже могут быть проблемы с лагом репликации.

https://gitlab.com/postgres-ai/postgresql-consulting/tests-and-benchmarks/-/issues/32

Думаю будет полезно упомянуть, что подобную функциональность поддерживает и pgbackrest
pgbackrest.org/user-guide.html#restore/option-db-include
Также наши нагрузочные тесты показали что при определенном уровне нагрузки Etcd начинает давать ошибки по IO

Для нагруженной, и тем более боевой среды, не стоит размещать данные etcd на тех же дисках что и база данных (как и любые другие сервисы интенсивно использующие ресурсы дисковой подсистемы).

Сам же etcd кластер, если он выделен только под кластер patroni, не требует ssd, и может стабильно работать и на обычных дисках, так как нагрузка от Patroni на etcd совсем не большая.

Если в Вашей инфраструктуре множество (сотни и тысячи) кластеров Patroni, и вы используете общий — выделенный кластер etcd, тогда желательно использовать ssd диски, а так же выделить уже больше ядер CPU и оперативной памяти.
Большое Вам спасибо!
но лучше все-таки использовать

Ну это ведь спорный вопрос. Нельзя сказать, что всем нужна именно VictoriaMetrics, так как каждый выбирает систему из своих каких-либо личных соображений, что больше всего подходит под его задачи, что он понимает.
нормальный язык запросов

Для этого критерия я бы выбрал PostgreSQL с расширением timescaledb. Во первых — потому что я специализируюсь по СУБД PostgreSQL, во вторых — это действительно SQL, в третьих — мне вполне достаточно того уровня сжатия который может предоставить timescaledb для секций.
1

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity

Specialization

Chief Technology Officer (CTO), Database Administrator