PostgreSQL

Привет. Сегодня я расскажу о работе с геоданными в PostgreSQL и немного о том, как это сделать в своем Java/Kotlin-приложении.

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

Не раз наша команда сталкивались с задачей, связанной с хранением и использованием IP-адресов в базе данных. Предположим, что есть типичная задача: необходимо парсить огромное количество диапазонов адресов (~300k) с известного ресурса, а далее определять страну по IP-адресу клиента. Кажется, ничего особенного. Это довольно просто решается любым ниже описанным способом при малых нагрузках. Но если у нас тысячи пользователей или наш сервис является прокси перед всеми остальными? В этом случае не хочется быть бутылочным горлышком и приходится бороться за каждую долю секунды.

Есть проверенная архитектура, которую я видел много раз для поддержки ваших веб-сервисов и приложений:

• PostgreSQL для хранения данных
• Redis для координации очередей фоновых заданий (и некоторых ограниченных атомарных операций)

Redis — это фантастика, но что, если бы я сказал вам, что его наиболее распространенные варианты использования этого стека на самом деле могут быть достигнуты с использованием только PostgreSQL?

Сценарий 1: очередь заданий

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

Если ваша жизнь DBA, сопровождающего PostgreSQL, наполнена вопросами "а почему так медленно?" и "как сделать, чтобы запрос не тормозил?", наш сервис анализа и визуализации планов запросов explain.tensor.ru сделает ее немного легче за счет привлечения коллег и обновленных подсказок.

Это вольный перевод поста одного из сильных разработчиков Postgres - Andres Freund. Кроме того что разработчик сильный, так еще и статья довольно интересная и раскрывает детали того как работает ОС Linux.

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

Как по мне, здесь есть что обсудить...

Автор — Игорь Косенков, инженер Postgres Professional

Привет всем! Сегодня речь пойдет о кластере. Да, снова об отказоустойчивом кластере на базе Corosync/Pacemaker. Только настраивать мы его будем не как обычно — с помощью утилиты pcs, а с помощью мало используемой утилиты crm.

С точки зрения использования этих утилит (pcs и crm) весь мир Unix-like операционок делится на два вида:

• содержит пакеты утилиты pcs (RHEL, CentOS, Debian, Ubuntu);
• содержит пакеты утилиты crm (SLES, Opensuse, Elbrus, Leningrad и т.д.).

crm — cluster resource manager — специальная утилита, которая используется для создания и управления отказоустойчивым кластером. Она включена в пакет crmsh, который обычно не входит в состав самых распространенных дистрибутивов Linux.

Идея написать статью об этой утилите пришла однажды, когда я спросил у поисковика: «Как настроить отказоустойчивый кластер с помощью crm». В ответ не получил ничего нужного и полезного, т.к. поисковик мне предложил много вариантов, никак не связанных с crm.

В то же время, если спросить у поисковика про утилиту настройки кластера pcs, которая является по функционалу такой же утилитой, как и crm, то информации будет много. Есть даже несколько статей на Хабре (в том числе и моя статья Кластер pacemaker/corosync без валидола).

Неделю назад я делал анонс про pgSCV новом экспортере метрик для PostgreSQL. После анонса мне ожидаемо стали писать читатели с намеком что неплохо бы и дашборды сделать. Эта задача есть у меня в списке и этот запрос не оказался для меня сюрпризом. Оно и понятно, метрик ого-го сколько и даже продвинутому DBA понадобится довольно много времени чтобы разобраться в них и соорудить более-менее вменяемый дашборд.

Я занялся вопросом и сделал базовые дашборды которые покрывают некий (но не весь) объем метрик которые есть в pgSCV. А в этом посте я сделаю быстрый обзор и расскажу что там есть.

Статья о том, как реляционная СУБД может выполнить JOIN. Для лучшего понимания мы попробуем своими руками написать такую же реализацию на языке C#. Что позволит нам лучше вникнуть в детали.

А чтобы было не совсем скучно - мы зададимся вопросом производительности. Что работает быстрее C# или SQL? И хоть сам по себе вопрос не корректен, к этому пониманию мы как раз и придем.

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

Видеть происходящее на шлюзах, при этом не вдаваясь в особенности пользовательского интерфейса Gravitee, а администраторам - не тратить время на создание пользователей и разделение ролей и привилегий внутри Gravitee.

Всем привет. В этом посте я расскажу про pgSCV - новый экспортер метрик для PostgreSQL (и не только), чем он так хорош и какие проблемы решает.

В прошлом году популярный сервис мониторинга Zabbix представил Agent 2, призванный сократить число TCP-подключений и обеспечить удобную расширяемость за счёт плагинов на Golang.

Меня зовут Даша и я один из разработчиков плагина мониторинга PostgreSQL для Zabbix Agent 2. В этой статье я расскажу об основных “фишках” использования Zabbix Agent 2 для мониторинга PostgreSQL, о принципе работы плагина, дам советы по его настройке, а также объясню на примере, как кастомизировать плагин.

Всем привет, на этой неделе вышел бета-релиз PostgreSQL 14. В этом небольшом посте я сделаю краткий обзор того что есть нового и полезного в плане мониторинга и наблюдения.

По идее пост должен быть интересен тем кому небезразлична тема мониторинга и поиска проблем в PostgreSQL — системные администраторы, DBA, SRE, DBRE.

Для организации совместного доступа к данным в PostgreSQL программисты часто использую row-level локи. В статье поговорим об оверхеде, который получается от такого подхода и какие есть альтернативы. Давайте посмотрим, как можно поторопить слона!

Источник изображения

В эфире снова Радио SQL, здравствуйте, согалактчики!

Сегодня у нас обещанный разбор задачи на поиск последней цены.

Постановка задачи

От бизнеса поступила задача — необходимо регулярно сохранять копии отдельных баз данных, расположенных в разных кластерах PostgreSQL.

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



Первое и самое очевидное решение — pg_dump

Достоинства — простота решения. Штатные методы. Все отработано, документации и материалов великое множество.

Но, достоинства есть продолжения недостатков.
Во-первых: объемы дампов.
Во-вторых: и это самое неприятное, были случаи несовпадения исходной и целевой БД при восстановлении из дампа.

Возможно этот случай заслужит отдельной заметки. Как оказалось, не все так однозначно, с pg_dump

В-третьих: время, сначала на создание дампа, потом на восстановление БД из дампа.

В итоге — нужно искать другой путь копирования БД между серверами. Бизнес требовал, задача интересная.

Не факт, что решение получилось максимально эффективным и не будет изменено/улучшено. Но как этюд на тему использования возможностей PostgreSQL, идея показалась как минимум интересной.

Иногда при выполнении длительных или плохо написанных запросов в PostgreSQL происходят разные неприятные вещи типа внезапного сбоя процесса или краша всего сервера.

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

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

Надеемся, что вы хорошо отдохнули и попраздновали. А мы предлагаем вам очередную сводку Postgres-новостей.

PostgreSQL 14 Beta 1

Релизная группа в составе Пит Гейган (Pete Geoghegan, Crunchy Data), Мишель Пакье (Michael Paquier, VMWare) и Эндрю Данстан (Andrew Dunstan, EDB) предлагают опубликовать бету 20-го мая, как это и происходило с предыдущими бетами.

Commitfest afterparty

PostgreSQL 14: Часть 5 или «весенние заморозки» (Коммитфест 2021-03)

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

Вот авторский тизер:

• Может ли один запрос параллельно выполняться на разных серверах?
• Как найти запрос из pg_stat_activity в pg_stat_statements?
• Можно ли добавлять и удалять секции секционированной таблицы не останавливая приложение?
• Как пустить разработчиков на прод чтобы они могли всё видеть, но ничего не могли изменить?
• Почему VACUUM после COPY FREEZE заново переписывает всю таблицу и что с этим делать?
• Можно ли сжимать TOAST чем-то кроме медленного zlib?
• Как понять сколько времени длится блокировка найденная в pg_locks?
• Для чего нужны CYCLE и SEARCH рекурсивному запросу?
• Текст функций на каких языках (кроме C) не интерпретируется при вызове?

В конце прошлого года Иван Панченко предложил мне рассказать на внутреннем семинаре Postgres Pro, чего, по нашему опыту использования PostgreSQL в "кровавом энтерпрайзе" "Тензора", не хватает в этой СУБД.

С докладом пока так и не сложилось, зато появилась эта статья, в которой я постарался собрать наиболее показательные вещи, которые вызывают "напряги" при активном использовании PostgreSQL в реальном бизнесе.

В рамках проекта Фото-Географического Атласа России (photogeomap.ru) мы собрали ряд фотографий различных ландшафтов страны. Многие из них сделаны в достаточно труднодоступных местах.  Именно эту труднодоступность на качественном уровне мы и хотим оценить для каждой точки (фотографии).

Меня зовут Алексей Казаков, я техлид команды «Клиентские коммуникации» в ДомКлик. В большинстве приложений, с которыми мне приходилось иметь дело, при взаимодействии с БД не ограничиваются лишь драйвером, который позволяет выполнять сырые запросы. Для удобства и избавления от SQL-запросов внутри, например, Python-кода дополнительно используют библиотеки (Object Relational Mapper, ORM).

Это первая статья в серии, посвященной различным ORM. Начнём мы с DjangoORM.