Можно ли достоверно предсказать будущее хоть на немного вперед? Иногда - вполне, надо только много везения... или немного знаний.
Сегодня пронаблюдаем сеанс черной магии с последующим разоблачением, или «Я угадаю твой рандом с 3 строк!»
Всем привет. Сегодня я хотел бы поделиться рецептом по обрезанию большой таблицы PostgreSQL в production.
Пример: мы имеем в БД достаточно большую таблицу (несколько сотен миллионов строк) с устаревшими данными, которые нам уже не нужны. Точнее, они мешают — БД долго дампится, а индексы становятся неэффективными.
Решение в лоб (delete from table where id < 1234567) работает очень долго из-за большого количества индексов и ограничений в таблице и нас не устраивает.
Более быстрый способ рассмотрим в этой статье.
idle_in_transaction?
Как интегрировать БД с 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:
- эффективная обработка потока «фактов»
И сегодня поговорим о том, как можно снизить суммарные задержки на вставку множества изменений в таблицы агрегатов за счет использования промежуточных таблиц и внешней обработки.
При поиске проблем в RDBMs разработчик обычно подозревает медленные запросы. А что, если дело не в них? О том, какого типа запросы дают нагрузку на базу данных, не позволяя вашему приложению работать должным образом, рассказал в своем докладе на конференции Saint HighLoad++ Online 2020 администратор баз данных Data Egret Андрей Сальников.
Он поделился тем, как backend-разработчику определять такие запросы, и каким инструментом для этого лучше воспользоваться. Особенно эти знания пригодятся в случае, если нужно найти проблемы в работающей системе здесь и сейчас, когда дорога каждая минута, а работа приложения с базой данных тормозит.
В прошлой статье мини-цикла о работе с агрегатами я рассказывал, как организовать эффективное многопоточное преобразование потока первичных данных в данные агрегированные. Там мы рассматривали задачу "свертки" продаж в агрегаты вида товар/дата/кол-во.
Сегодня мы рассмотрим более сложный вариант, который зачастую начинается со слов "А заказчик захотел…" и приводит нас к иерархичным агрегатам в нескольких одновременных разрезах, которые позволяют нам в СБИС практически мгновенно строить оперативные отчеты в подсистемах организации торговли, бухгалтерского учета и даже управления активными продажами.
PostgreSQL хранит данные на каких-то носителях. И между PostgreSQL и, например, магнитной поверхностью диска находится несколько кешей: кеш самого винчестера, кеш RAID-контроллера или винчестерной полки, кеш файловой системы на уровне операционной системы и кеш самого PostgreSQL. Если первыми перечисленными кешами мы практический не можем управлять, то последними, находящимися в ОЗУ сервера, управлять можем: например, выделяя больше ОЗУ под кеш PostgreSQL в ущерб кешу ОС, или наоборот. В официальной документации можно прочитать ничем не подтвержденные рекомендации, типа выделять под PostgreSQL четверть ОЗУ. Это вызывает сомнения. PostgreSQL в виде Postgres95 впервые появился в 1995 году и, кто знает, быть может и эти рекомендации относятся к тому же году. Поэтому появилась идея эксперимента с целью разобраться, как лучше распределять ОЗУ.
Как сообщает telegram-канал Cross Join, в репозиторий Postgres упал комит, упрощающий работу с jsonb. Теперь можно обращаться к частям jsonb с помощью квадратных скобок, причем это работает как на чтение, так и на запись.
Прощай jsonb_set и прочие костыли типа data = data - 'a' || '{"a":5}'
Обновляем значение объекта по ключу. 25 здесь является числом, но взято в кавычки, потому что присваиваемое значение должно быть jsonb
-- (person_data имеет тип jsonb)
UPDATE users
SET person_data['age'] = '25'; 
Данный пост ни на что не претендует, а написан мной в целях помочь таким-же недопрограммистам как я. Возможно, если бы я прочитал документацию по этой API полностью, то этой статьи бы и не понадобилось. Однако, в свою защиту скажу, что я не нашел внятной инструкции для чайников.
Я столкнулся с рядом проблем при попытке подключить libpq в VS 2017: начиная с несоответствия документации по данной API с инструкциями по подключению, заканчивая умолчанием некоторых ключевых моментов.
В общем по порядку.