Все потоки
Поиск
Написать публикацию
Обновить
114.54

PostgreSQL *

Свободная объектно-реляционная СУБД

Сначала показывать
Порог рейтинга
Уровень сложности

Основы мониторинга PostgreSQL. Алексей Лесовский

Время на прочтение22 мин
Количество просмотров75K

Предлагаю ознакомиться с расшифровкой доклада Алексей Лесовский из Data Egret "Основы мониторинга PostgreSQL"


В этом докладе Алексей Лесовский расскажет о ключевых моментах постгресовой статистики, что они означают, и почему они должны присутствовать в мониторинге; о том, какие графики должны быть в мониторинге, как их добавить и как интерпретировать. Доклад будет полезен администраторам баз данных, системным администраторам и разработчикам, которым интересен траблшутинг Postgres'а.


SQL HowTo: пишем while-цикл прямо в запросе, или «Элементарная трехходовка»

Время на прочтение5 мин
Количество просмотров39K
Периодически возникает задача поиска связанных данных по набору ключей, пока не наберем нужное суммарное количество записей.

Наиболее «жизненный» пример — вывести 20 самых старых задач, числящихся на списке сотрудников (например, в рамках одного подразделения). Для различных управленческих «дашбордов» с краткими выжимками по участкам работы похожая тема требуется достаточно часто.



В статье рассмотрим реализацию на PostgreSQL «наивного» варианта решения такой задачи, «поумнее» и совсем сложный алгоритм «цикла» на SQL с условием выхода от найденных данных, который может быть полезен как для общего развития, так и для применения в других похожих случаях.
Читать дальше →

PostgreSQL 13: параллельный VACUUM

Время на прочтение3 мин
Количество просмотров10K
На днях Амит Капила закоммитил патч Масахико Савады, который позволяет выполнять очистку в параллельном режиме. Сама таблица по-прежнему очищается одним (ведущим) процессом, но для очистки индексов он теперь может запускать фоновые рабочие процессы, по одному на каждый индекс. В ручном режиме это позволяет ускорить очистку больших таблиц с несколькими индексами; автоматическая очистка пока не использует эту возможность.
Некоторые подробности

Знакомство с wal-g системой бекапирования PostgreSQL

Время на прочтение6 мин
Количество просмотров38K

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

Читать дальше →

PostgreSQL Antipatterns: ударим словарем по тяжелому JOIN

Время на прочтение6 мин
Количество просмотров23K
Продолжаем серию статей, посвященных исследованию малоизвестных способов улучшения производительности «вроде бы простых» запросов на PostgreSQL:


Не подумайте, что я так сильно не люблю JOIN… :)

Но зачастую без него запрос получается ощутимо производительнее, чем с ним. Поэтому сегодня попробуем вообще избавиться от ресурсоемкого JOIN — с помощью словаря.


Читать дальше →

Инструменты создания бэкапов PostgreSQL. Андрей Сальников (Data Egret)

Время на прочтение19 мин
Количество просмотров44K

Я из компании Luxoft.
Предлагаю ознакомиться с расшифровкой доклада Андрей Сальников из Data Egret "Инструменты создания бэкапов PostgreSQL" . В конце обновленная сводная таблица по инструментам


Данный доклад посвящен доступным инструментам бэкапирования PostgreSQL. Логические backup, бинарные backup, встроенные средства бэкапирования и сторонние инструменты. Нужны ли инкрементальные backup, когда они могут действительно помочь. Посмотрим, когда и какой инструмент уместнее использовать. Как лучше автоматизировать процесс бэкапирования и проверки целостности сделанного бэкапа. Посмотрим вблизи на инструменты, такие как pg_dump, pg_basebackup, barman, wal-e, wal-g, pgbackrest, BART и pg_probackup.


Читать дальше →

Разговоры про PostgreSQL. Интервью с Алексеем Лесовским в подкасте «Цинковый прод». Часть первая

Время на прочтение13 мин
Количество просмотров5K
Недавно мы пригласили в эфир "Цинкового прода" Алексея Лесовского из компании Data Egret. Разговор получился интересный и познавательный, поэтому предлагаю вашему вниманию расшифровку этого выпуска. Из-за внушительного объема пришлось разбить текст на части. Если лень ждать продолжения — можно просто послушать аудиоверсию здесь.

Всем привет, это сороковой выпуск подкаста "Цинковый прод", и с нами в студии постоянные ведущие Антон Околелов, Никита Васильченко и Грицак Олег.


Антон: Итак, у нас сегодня гость, Алексей Лесовский. Лёша, представься пожалуйста, кто ты, чем занимаешься и так далее.

Читать дальше →

Managed Databases в Selectel: приглашаем в бету

Время на прочтение5 мин
Количество просмотров3.7K

Сегодня мы представляем открытую для тестирования бета-версию Managed Databases для PostgreSQL, использование которой будет бесплатным на период бета-тестирования.

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

Почему нужна инструментальная поддержка пагинации на ключах

Время на прочтение5 мин
Количество просмотров21K

Всем привет! Я бэкэнд-разработчик, пишу микросервисы на Java + Spring. Работаю в одной из команд разработки внутренних продуктов в компании Тинькофф.



У нас в команде часто встает вопрос оптимизации запросов в СУБД. Всегда хочется еще чуть-чуть быстрее, но не всегда можно обойтись продуманно выстроенными индексами — приходится искать какие-то обходные пути. Во время одного из таких скитаний по сети в поисках разумных оптимизаций при работе с БД я нашел бесконечно полезный блог Маркуса Винанда, автора книги SQL Performance Explained. Это тот самый редкий вид блогов, в котором можно читать все статьи подряд.


Хочу перевести для вас небольшую статью Маркуса. Ее можно назвать в какой-то степени манифестом, который стремится привлечь внимание к старой, но до сих пор актуальной проблеме производительности операции offset по стандарту SQL.

Читать дальше →

PubSub почти бесплатно: особенности NOTIFY в PostgreSQL

Время на прочтение9 мин
Количество просмотров23K
Если ваши микросервисы уже используют общую базу PostgreSQL для хранения данных, или ей пользуются несколько экземпляров одного сервиса на разных серверах, можно относительно «дешево» получить возможность обмена сообщениями (PubSub) между ними без интеграции в архитектуру Redis, RabbitMQ-кластера или встройки в код приложения другой MQ-системы.

Для этого мы не будем писать сообщения в таблицы БД, поскольку это вызывает слишком большие накладные расходы сначала на запись передаваемого, а потом еще и на зачистку от уже прочитанного.

Передавать и получать данные мы станем с помощью механизма NOTIFY/LISTEN, а модельную реализацию соберем для Node.js.



Но на этом пути лежат грабли, которые придется аккуратно обойти.
Читать дальше →

PostgreSQL Antipatterns: редкая запись долетит до середины JOIN

Время на прочтение3 мин
Количество просмотров20K
Если писать SQL-запросы без анализа алгоритма, который они должны реализовать, ни к чему хорошему с точки зрения производительности это обычно не приводит.

Такие запросы любят «кушать» процессорное время и активно почитывать данные практически на ровном месте. Причем, это вовсе не обязательно какие-то сложные запросы, наоборот — чем проще он написан, тем больше шансов получить проблемы. А уж если в дело вступает оператор JOIN…


Само по себе соединение таблиц не вредно и не полезно — это просто инструмент, но и пользоваться им надо уметь.
Читать дальше →

Postgres-вторник №5: «PostgreSQL и Kubernetes. CI/CD. Автоматизация тестирования»

Время на прочтение15 мин
Количество просмотров11K


В конце минувшего года состоялся очередной прямой эфир российского PostgreSQL-сообщества #RuPostgres, в рамках которого его сооснователь Николай Самохвалов поговорил с техническим директором «Фланта» Дмитрием Столяровым про эту СУБД в контексте Kubernetes.

Мы публикуем стенограмму основной части этой дискуссии, а на YouTube-канале сообщества опубликована полная видеозапись:

DBA: перенос значений SEQUENCE между базами PostgreSQL

Время на прочтение3 мин
Количество просмотров8.5K
Как можно перенести в другую PostgreSQL-базу последнее назначавшееся значение «автоинкремент»-поля типа serial, если в таблице могли быть какие-то удаления, и «просто подставить max(pk)» уже не подходит?

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


Читать дальше →

Ближайшие события

SQL HowTo: собираем «цепочки» с помощью window functions

Время на прочтение6 мин
Количество просмотров7.4K
Иногда при анализе данных возникает задача выделения «цепочек» в выборке — то есть упорядоченных последовательностей записей, для каждой из которых выполняется некоторое условие.

Это может быть как условие от данных самой записи, так и сложное выражение относительно одной или нескольких предыдущих записей — например, длина интервала между близкими временными отсчетами.



Традиционные решения предусматривают разные варианты «self join», когда выборка соединяется с собой же, либо использование некоторых фактов «за пределами данных» — например, что записи должны иметь строго определенный шаг (N+1, «за каждый день», ...).

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

Но эту задачу нам помогут эффективно решить оконные функции в PostgreSQL.
Читать дальше →

БД мессенджера (ч.2): секционируем «наживую»

Время на прочтение4 мин
Количество просмотров11K
Мы удачно спроектировали структуру нашей PostgreSQL-базы для хранения переписки, прошел год, пользователи активно ее наполняют, вот в ней уже миллионы записей, и… что-то все начало подтормаживать.



Дело в том, что с ростом объема таблицы растет и «глубина» индексов — хоть и логарифмически. Но со временем это заставляет сервер для выполнения тех же задач чтения/записи обрабатывать в разы больше страниц данных, чем в начале.

Вот тут на помощь и приходит секционирование.
Читать дальше →

БД мессенджера (ч.1): проектируем каркас базы

Время на прочтение5 мин
Количество просмотров21K
Как можно перевести бизнес-требования в конкретные структуры данных на примере проектирования «с нуля» базы для мессенджера.



Наша база будет не такой масштабной и распределенной, как у ВКонтакте или Badoo, а «чтобы было», но было хорошо — функционально, быстро и умещалось на одном сервере PostgreSQL — чтобы можно было развернуть отдельный экземпляр сервиса где-то на стороне, например.

Поэтому не будем затрагивать вопросы шардинга, репликации и геораспределенных систем, а сосредоточимся на схемных решениях внутри БД.
Читать дальше →

Очереди сообщений в PostgreSQL с использованием PgQ

Время на прочтение4 мин
Количество просмотров33K


Очереди сообщений используются для выполнения: отложенных операций, взаимодействия сервисов между собой, «batch processing» и т.д. Для организации подобных очередей существуют специализированные решения, такие как: RabbitMQ, ActiveMQ, ZeroMQ и тд, но часто бывает, что в них нет большой необходимости, а их установка и поддержка причинит больше боли и страданий, чем принесет пользы. Допустим, у вас есть сервис, при регистрации в котором пользователю отправляется email для подтверждения, и, если вы используете Postgres, то вам повезло — в Postgres, почти из коробки, есть расширение PgQ, которое сделает всю грязную работу за вас.

В этой статье я расскажу об организации очередей сообщений (задач) в PostgreSQL с использованием расширения PgQ. Эта статья будет полезна, если вы еще не использовали PgQ или используете самописные очереди поверх Postgres.

Зачем вообще нужен PgQ, если можно просто создать табличку и записывать туда задачи? Казалось бы, можно, но вам придется учесть паралельный доступ к задачам, возможные ошибки (что будет, если процесс обрабатывающий задачу, упадет?), а также производительность (PgQ очень быстрый, а самописные решения, как правило, нет, особенно если транзакция в базе не закрывается во время всего выполнения задачи), но самое главное, почему на мой взгляд надо использовать PgQ, это то, что PgQ уже написан и работает, а самописное решение еще надо написать (UPD: про то, почему не стоит использовать самописные очереди, можно почитать, например, тут).
(UPD: т.к. PgQ работает поверх Postgres, все прелести транзакций можно использовать и в нем)

Но у PgQ есть один огромный минус — отсутствие документации, этот недостаток я и пытаюсь компенсировать этой статьей.
Читать дальше →

Multiprocessing и реконсиляция данных из различных источников

Время на прочтение9 мин
Количество просмотров8.8K
Привет, Хабр!

В условиях многообразия распределенных систем, наличие выверенной информации в целевом хранилище является важным критерием непротиворечивости данных.

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

Как реализовать этот кейс на старом-добром Python — читаем под катом! Поехали!


(Источник картинки)
Читать дальше →

SQL HowTo: рисуем морозные узоры на SQL

Время на прочтение2 мин
Количество просмотров7.1K


Немного SQL-магии под катом: математика, рекурсия, псевдографика.

Заодно вспоминаем под Новый год формулу угла между векторами:

Читать дальше →

Логическая репликация из PostgreSQL в Erlang

Время на прочтение5 мин
Количество просмотров6.9K

Довольно типичная схема при разработке системы, когда основная логика обработки сосредоточена в приложении (в нашем случае Erlang), а данные для работы этого приложения (настройки, профили пользователей и т. д.) в базе данных (PostgreSQL). Приложение Erlang кэширует настройки в ETS для ускорения обработки и снижения нагрузки на БД путём отказа от постоянных запросов. При этом изменение этих данных происходит через отдельный (возможно, внешний) сервис.


В таких ситуациях встаёт задача поддержания закэшированных данных в актуальном состоянии. Есть разные подходы для решения этой задачи. Один из них — это логическая репликация PostgreSQL. О нем и пойдёт речь ниже.

Читать дальше →

Вклад авторов