PostgreSQL *

Привет, Хабр! Наш проект "Пятерочки #налету", описанный в статье "Как тебе такое, Джефф Безос?"продолжает развиваться - надеемся, что вскоре дадим по нему апдейт. Ну а пока расскажем о еще более масштабном проекте, в ходе которого удалось обновить систему мониторинга автотранспорта на 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, чтобы понять, как можно определить таблицы, которые явно занимают подозрительно много места.

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

Мы заканчиваем мини-серию статей о работе с агрегатами в PostgreSQL:

- зачем, как, а стоит ли?

- эффективная обработка потока «фактов»

- многомерные суперагрегаты

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

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

При поиске проблем в RDBMs разработчик обычно подозревает медленные запросы. А что, если дело не в них? О том, какого типа запросы дают нагрузку на базу данных, не позволяя вашему приложению работать должным образом, рассказал в своем докладе на конференции Saint HighLoad++ Online 2020 администратор баз данных Data Egret Андрей Сальников. 

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

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

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