PostgreSQL *

Нравится Kotlin? Считаешь SQL мощным инструментом? Подташнивает от слов ORM, JPA, Hibernate?

Есть выход! Автоматическая генерация SQL + JDBC без бойлер-плейта.

Привет!

Сегодня мы выпустили DataGrip 2021.1: наш самый мощный релиз за последние годы. И это не шутка!

Для приготовления асинхронных уведомлений listen/notify в реплике нам понадобится postgres. Как говорится в документации:

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

LISTEN, NOTIFY

Практически любая enterprise-система (под которой мы будем подразумевать некоторое ПО, где пользователи работают постоянно в течение всего рабочего дня) в современном мире стремится вырасти вместе с управляемым ей бизнесом в высоконагруженное web-решение вроде нашего СБИС.

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

Когда, где и как их может вызвать затаившийся до поры диверсант?

Привет, Хабр.

Несмотря на то, что на текущем месте работы взаимодействовать с PostgreSQL приходится значительно меньше, я продолжаю поддерживать свою библиотеку pg-index-health. Недавно я зарелизил версию 0.3.1, ключевой особенностью которой стала поддержка PostgreSQL 13.

Эта история началась достаточно давно, ещё в октябре 2020. В процессе мне пришлось отказаться от embedded версии СУБД в тестах, перейти на Testcontainers, столкнуться с ошибкой в PG13 и даже немного пообщаться в переписке с одним из разработчиков Постгреса... Но обо всем по порядку.

Гибридное Облако (Hybrid Cloud) - это общий архитектурный дизайн в любой компании. Эта концепция сочетает в себе публичное облако, частное облако и даже локальные решения, что позволяет компаниям иметь гибкость в отношении того, где хранить и как использовать свои данные. Она также помогает при реализации среды высокой доступности (High Availability environment). Проблема заключается в том, что развертывание такой среды может быть сложной и трудоемкой задачей. В этом блоге мы увидим, что такое гибридное облако, рассмотрим некоторые соображения, которые необходимо принять во внимание, прежде чем использовать его, а также то, как развернуть эту среду с помощью ClusterControl.

Привет, Хабр! Наш проект "Пятерочки #налету", описанный в статье "Как тебе такое, Джефф Безос?"продолжает развиваться - надеемся, что вскоре дадим по нему апдейт. Ну а пока расскажем о еще более масштабном проекте, в ходе которого удалось обновить систему мониторинга автотранспорта на 15 000 машин.

Зачем она нужна? Представьте, что у вас есть магазин с постоянными клиентами, которые каждый день приходят за нужными им товарами. И есть грузовик, который каждое утро привозит эти товары. И вдруг в одно прекрасное утро грузовик не приезжает, или приезжает, но гораздо позже обычного, либо приезжает, но привозит испорченные товары. Хаос и разочарование на лицах покупателей неминуемы. А ведь это только один магазин и один грузовик. А что, если магазинов и грузовиков - много тысяч? В этом случае нужна сверх -надежная система мониторинга транспорта, которая поможет навести порядок с доставкой товаров. Под катом - описание системы, рассказ о том, как однажды все (ну, почти) поломалось и о том, как мы все поправили, переделав систему.

"Шеф, всё пропало, у нас serial на мегатаблице кончился!" - а это значит, что либо вы его неаккуратно накрутили сами, либо у вас действительно данных столько, что разрядности integer-столбца уже не хватает для вашей большой и активной таблицы в PostgreSQL-базе.

Да и столбец этот не простой, а целый PRIMARY KEY, на который еще и ряд других немаленьких таблиц по FOREIGN KEY завязан. А еще и приложение останавливать совсем не хочется, ибо клиентам 24x7 обещано...

В общем, надо как-то с минимальными блокировками увеличить размер PK-поля в большой таблице, на которое многое завязано.

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

Что может показать нам PGHero:

• статистику по запросам: количество вызовов, среднее и суммарное время выполнения (с возможностью хранения истории);

• активные в данный момент запросы;

• информацию о таблицах: занимаемое на диске место, даты последних запусков VACUUM и ANALYSE;

• информацию об индексах: занимаемое на диске место, наличие дублируемых/неиспользуемых индексов. Также может порекомендовать добавить индекс при наличии сложных запросов с Seq Scan;

• статистику по открытым подключениям к БД;

• вывод основных настроек БД, влияющих на производительность (shared_buffers, work_mem, maintenance_work_mem и т.д.)

Прим. перев.: в конце января Percona опубликовала результаты своего небольшого сравнения производительности для СУБД PostgreSQL, запущенной на x86- и ARM-инстансах AWS. Результаты получились интересными даже с учетом всех допущений, сделанных самими авторами и отмеченных комментаторами оригинальной статьи. А чтобы вы могли сделать собственные выводы, предлагаем вниманию перевод этого материала.

Ожидаемый рост количества ARM-процессоров в дата-центрах уже довольно давно является горячей темой для обсуждения, и нам было любопытно узнать, как они справятся с PostgreSQL. Основным препятствием на этом пути была недоступность в целом серверов на базе ARM-чипов для тестирования и оценки. Все изменилось после того, как в 2018 году AWS представила линейку инстансов на основе ARM-процессоров. Впрочем, особого ажиотажа не последовало: многие посчитали их "экспериментальным" предложением. Мы тоже опасались рекомендовать эти инстансы для критически значимого применения и не прилагали особых усилий для их оценки. Но когда в мае 2020 было анонсировано второе поколение инстансов на основе Graviton2, решили пересмотреть свое отношение. Нужно было объективно взглянуть на показатель цена/производительность новых машин при работе с PostgreSQL.

Здравствуйте! В эфире снова Радио SQL.

Давненько не выходили в эфир, но тут братья-гуманоиды из соседнего Малого МакГеланового облака подкинули задачку. Сходу в один присест задачка не решилась, пришлось подумать. Значит и в Западном рукаве Галактики тоже могут найтись желающие поломать мозг об задачку. Сейчас изложу условие, а ответ следующим посланием уйдёт.

Можно ли достоверно предсказать будущее хоть на немного вперед? Иногда - вполне, надо только много везения... или немного знаний.

Сегодня пронаблюдаем сеанс черной магии с последующим разоблачением, или «Я угадаю твой рандом с 3 строк!»

Всем привет. Сегодня я хотел бы поделиться рецептом по обрезанию большой таблицы PostgreSQL в production.

Пример: мы имеем в БД достаточно большую таблицу (несколько сотен миллионов строк) с устаревшими данными, которые нам уже не нужны. Точнее, они мешают — БД долго дампится, а индексы становятся неэффективными.

Решение в лоб (delete from table where id < 1234567) работает очень долго из-за большого количества индексов и ограничений в таблице и нас не устраивает.

Более быстрый способ рассмотрим в этой статье.

Конференция PGConf.Online 2021

Статьи

• Могут ли диапазоны содержать пропуски значений?
• Зачем нужна индексная нотация типу json?
• Может ли индекс при частых обновлениях разрастаться меньше, чем таблица? А вообще не разрастаться?
• Сколько времени простаивали сеансы в idle_in_transaction?
• Как построить ER-диаграмму для таблиц системного каталога?

Как интегрировать БД с SSH-туннелем в PowerBI, как настроить SSH-туннель с приватным ключом, как обновлять данные по запросам к БД в PowerBI

Привет, друзья! Приглашаем на вебинар, посвященный продукту для углубленного мониторинга баз данных – DBmarlin, который:

– контролирует производительность баз данных – MySQL, MariaDB, PostgreSQL, Oracle, MS SQL Server, развернутых как в своей инфраструктуре, так и у облачного провайдера (AWS, Azure);

– предоставляет детальную видимость работы серверов, на которых развернуты БД;

– собирает statements и wait states, благодаря чему вы видите, на что именно тратится время внутри БД во время исполнения SQL запроса;

– автоматически обнаруживает изменения в объектах схемы БД, параметрах БД, собирает планы выполнения запросов, чтобы вы видели их влияние на производительность.

- регистрирует релизы и другие события для анализа их влияния на БД.

При возникновении проблемы с запросом к БД, инструменты мониторинга и APM, не специализирующиеся на БД, покажут вам SQL-запрос в трейсе, который долго исполнялся. Все, что вы сможете увидеть – это текст SQL запроса и длительность его исполнения. Причина, по которой он был таким медленным остается неизвестной. DBmarlin покажет, в чем именно была проблема в БД - вы увидите, например, что вызывает блокировку.

На вебинаре мы покажем и расскажем:

– Какие задачи должен решать современный продукт для мониторинга баз данных?

– Кто выигрывает от улучшения мониторинга СУБД (спойлер – не только DBA).

– Что отличает продукт DBMarlin от конкурентов?

Регистрация доступна прямо на этой странице ниже или по ссылке.

Добрый день уважаемые читатели! О данном методе сегментации клиентов по давности покупок, частоте и сумме сделок написано довольно много материалов. На просторах Интернета вы без труда найдете публикации с описанием теории и практики rfm-анализа. Он может выполняться как на платформе табличного редактора (при небольшом количестве данных), так и с помощью sql-запросов или силами тематических библиотек Python/R. Методология всех примеров одна и та же, расхождение будет только в деталях. Например, порядок присвоения номеров сегментам или принцип деления на группы. Ввиду всего вышеизложенного мне будет трудно привнести новизну в эту тему. В статье я лишь постараюсь заострить ваше внимание на некоторых моментах, которые могут помочь начинающим аналитикам данных.

Традиционную конференцию PGConf.Russia в этом году из за злобного вируса не удалось провести в обещанные сроки в традиционной форме. Поэтому пока онлайн, с надеждой на офлайн в будущем - но в запланированные дни - с 1 по 3 марта. Онлайн упрощает приглашение иностранных докладчиков, участники на подножном корме - в общем, онлайн обходится дешевле, поэтому мы смогли сделать конференцию бесплатно (благодаря уважаемым спонсорам, на текущий момент это Intel, Nutanix, Avito и Zabbix, список, скорее всего, пополнится.

Что же в программе?

Добрый день уважаемые читатели! Данная статья является продолжением публикации "Повторяем когортный анализ, выполненный в Power BI, силами Python" (ссылка). Настоятельно рекомендую познакомиться с ней хотя бы бегло, иначе последующее повествование будет вам малопонятным. С момента ее выхода на Хабр прошло достаточно времени. Я основательно пересмотрел методологию решения подобных задач. Первым желанием было просто переписать старый материал, но после недолгих размышлений я пришел к выводу, что более разумным шагом будет оформить наработки в новую рукопись.

Какова основная причина моего "недовольства" Python и Power BI? Язык Python/R c тематическими библиотеками и Power BI (Tableau, Qlik) могут на 70-80% закрыть потребности бизнеса в расчете сложных метрик и построении визуализаций. Но только если речь идет об обработке относительно небольших датасетов с уже агрегированными данными. Если мы говорим о предварительном манипулировании данными в промышленном масштабе, то здесь игра переходит на сторону сервера с БД и используется SQL. Данный момент я не осветил в предыдущей публикации, поэтому решил ликвидировать это упущение здесь.

Тема "распухания" таблиц и индексов из-за реализации MVCC - больная для пользователей и администраторов PostgreSQL.

Однажды я уже поднимал ее в статье "DBA: когда пасует VACUUM — чистим таблицу вручную", разобрав на конкретных примерах, насколько драматический эффект для производительности запросов может оказывать невовремя проведенный или бесполезно отработавший из-за конкурентных транзакций VACUUM.

Но, помимо влияния на скорость, есть еще и факт влияния на занятое место. Наверное, вы сильно удивитесь, если таблица с единственной "живой" записью после успешного прохода autovacuum продолжит занимать гигабайты пространства на дорогих SSD.

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