Содержание
Вступление (и некоторые общие сведения)
Немного теории
Используемые функции PostgreSQL
Описание используемого примера данных
Предварительные шаги
Запросы
Краткий итог
«Задачи»
В работе с базами данных ключевым аспектом является не только отслеживание изменений в их структуре, но и подробная документация таблиц и их полей. Это особенно важно для проектов с быстро изменяющейся архитектурой, где ясность и точность данных играют решающую роль. Например, в крупных веб-приложениях часто требуется фиксировать новые таблицы, обновления полей или удаление устаревших элементов.
Для решения данной задачи разработаны два PHP-скрипта, предназначенные для работы с PostgreSQL. Эти скрипты выполняют две основные функции:
1. Сравнение старой и новой структуры базы данных с выявлением добавленных, удалённых и изменённых таблиц.
2. Создание Markdown-документации, которая содержит подробное описание назначения таблиц и характеристик их полей, что делает изменения в структуре базы данных прозрачными для разработчиков.
Всем привет, после публичного релиза pgpro-otel-collector, хочется продолжить рассказывать про инструмент и начать с серии постов про Коллектор. В этой серии постараюсь подробнее и на примерах познакомить читателя с коллектором и продемонстрировать сценарии использования. Рассказывать буду и про коллектор, и про разные вещи связанные с настройкой/мониторингом Postgres. Рассчитываю что посты будут полезны Linux администраторам, PostgreSQL DBA и тем кому интересен мониторинг Postgres.
Первый пост ознакомительный, в нем расскажу как установить, настроить и запустить коллектор. И конечно же, как посмотреть что-то что отдает коллектор и начнем мы с метрик Postgres.
Уже лет 20 существует миф (или не миф), что современный Highload-проект невозможен без кэшей. Они всегда нас выручали, когда не справлялись базы данных. Но с тех пор, как появились первые кэши, key-value баз данных и другие технологии, многое изменилось и традиционные СУБД значительно эволюционировали. И так ли теперь нужен кэш?
Мы протестировали самые известные кэш-сервисы и СУБД и попробовали выжать из них миллион запросов в секунду в разных условиях. Делимся с вами результатами в этой статье.
Привет, Хабр! Я Алексей Рыбак, предприниматель и основатель R&D-лаборатории DevHands, автор телеграм-канала про System Design и Highload. В прошлом — СТО и руководитель московского офиса Badoo. Работал во втором по размеру такси-сервисе «Везёт», который мы после продажи интегрировали с Яндекс.Такси. Сейчас наша компания разрабатывает образовательные программы по Highload и перформансу.
Здравствуйте! Меня зовут Алексей Калинин. Это вторая статья, посвященная разработанному мною Интерпретатору. На просторах интернета мне встретилась вот эта интересная статья, в которой автор описал возможности расширения функциональности БД PostgreSQL. После ее прочтения я решил попробовать встроить разработанный мною интерпретатор в БД PostgreSQL (тем более сам автор статьи предлагал это попробовать). За одно и проверить две вещи: легко ли добавить новый язык (новое расширение) в PostgreSQL и хватит ли возможностей моего интерпретатора для работы внутри БД. И если эксперимент по встраиванию нового языка в PostgreSQL пройдет успешно, тогда код, написанные на нем, можно использовать в реальных проектах.
Привет, Хабр. Всё, что пишет PostgreSQL в /var/log/postgresql/, можно разбирать, фильтровать, анализировать и автоматизировать. Не нужно вручную листать гигабайты логов — научимся вытягивать полезные данные и работать с конфигами в пару команд. О чём поговорим в статье:
grep — быстро ищем ошибки, медленные запросы, аномалии;sed — редактируем конфиги PostgreSQL, комментируем, заменяем настройки;awk — превращаем сырые логи в отчёты.
Как заставить работать pgcopydb для миграции штатного PostgreSQL 11 AstraLinux 1.7 в штатный PostgreSQL 15 AstraLinux 1.8?
Зачем это все понадобилось?
Многие в настоящее время сталкиваются с необходимостью миграции с AstraLinux 1.7 на AstraLinux 1.8.
Для тех, кто пользуется штатной PostgreSQL 11 из поставки AstraLinux 1.7, встает во весь рост вопрос, как перетащить существующие базы на новую версию. Если базы маленькие, особых проблем нет. А вот если базу под 1ТБ, то проблемы встают в полный рост.
Для штатной pg_upgrade требуются обе версии (PostgreSQL-11 и PostgreSQL-15). Но в поставке AstraLinux 1.8 нет PostgreSQL 11. При этом, так как Astra PostgreSQL не совместим бинарно с «Ванилью», то и не получится собрать самому нужную версию для Astra 1.8.
«Вкорячить» его из поставки Astra 1.7 можно, но не гарантирует работоспособность. (Напишу заметку об этом позже).
Штатный pg_dump | pg_restore в одну нитку, для базы 1.1 Тб у нас на стенде работал аж 27 часов. Максимальный размер технологического окна при этом установлен 24 часа.
Поиск решения (помимо логической репликации), навел на утилиту pgcopydb.
В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.
Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.
Сегодняшняя задача заставила попотеть и разработать различные способы оптимизации рекурсивного запроса как по количеству итераций, так и по объему используемой памяти.
Если вы когда-нибудь запускали несколько экземпляров PostgreSQL или другого ПО на одной машине (виртуальной или физической), то наверняка сталкивались с эффектом шумного соседа, когда инстансы мешали друг другу работать. Так как же примирить соседей? У нас есть ответ!
Хеш-индексы в PostgreSQL - мощный, но недооценённый инструмент.
Когда они быстрее B-Tree, а когда наоборот?
Простое объяснение, тесты и ключевые нюансы, которые помогут ускорить запросы...
После ухода западных вендоров в 2022 году российские компании столкнулись с необходимостью массовой миграции с Oracle и MS SQL на PostgreSQL и другие открытые СУБД. Теперь к вопросам миграции приходится относиться ответственнее: самостоятельно оценивать риски и прогнозировать работу систем после переезда.
Как перфоманс-инженер, я часто сталкиваюсь с вопросами типа: справится ли PostgreSQL с текущей нагрузкой? Потребуется ли обновление железа? Какие проблемы могут возникнуть после перехода? К сожалению, готовых инструментов для оценки производительности СУБД на рынке фактически нет. Это заставило нас разработать собственную методологию тестирования, которая позволяет выявить потенциальные проблемы и точно оценить необходимые ресурсы.
В этой статье я поделюсь практическим опытом нагрузочного тестирования баз данных и расскажу об инструментах, которые мы используем для анализа производительности. Наш подход не требует существенных затрат и может быть адаптирован под задачи любой компании, планирующей миграцию на PostgreSQL.
Удивился, что про столь популярный продукт не было статьи на Хабре, срочно это исправляю. Drizzle ORM — это #2 самая желаемая ORM по опросам, и она даже вошла в top 50 JavaScript Rising Stars 2024, заняв 27 место.
Всем привет! Я Тимур, инженер в команде Databases Т-Банка. Занимаюсь решением проблем и настройкой производительности СУБД Oracle и PostgreSQL.
По мере увеличения числа инстансов PostgreSQL оптимизация вычислительных ресурсов становится все более актуальной. Рассмотрим простую, но эффективную оптимизацию — prepared statements. В статье расскажу о некоторых особенностях custom и generic планов в PostgreSQL при выполнении prepared statements.
Защитите Postgres от квантов!
Why quantum-safe PostgreSQL is critical today
Только свыклись с мысльюо сосуществовании с LLM, и нате — новая напасть! Как сделать Postgres непробиваемым для квантов? Как, уже и об этом пора думать?
Автор — Тимоти Стюард (Timothy Steward) — считает, что да, пора. Статья в блоге Fujitsu Fastware, а Тимоти — главный архитектор данных по направлению энтерпрайз (Principal Enterprise Data Architect), там сейчас продвигают Fujitsu Enterprise Postgres 17.
Он говорит вот о чём: квантовые компьютеры пока мало что могут, но уже навострились ломать криптозащиту. Во всяком случае, надо к этому готовиться. Не то, чтобы заметка выдающаяся, но тема любопытная. Там есть ликбез, есть общеизвестные вещи, но есть и сведения, знакомые, наверное, только специалистам по шифрованию, есть красивые имена IBM‑овских птичек, оформленные в табличку (справа — число кубитов):
Операция VACUUM FULL полностью пересоздаёт таблицу, предельно оптимизируя её. Она требует полной блокировки таблицы, поэтому высоконагруженные таблицы обрабатывать ею без простоя системы нельзя. Вместо VACUUM FULL можно использовать расширение pg_repack. Оно создаёт на обрабатываемой таблице триггер, отслеживающей модификации, создаёт копию таблицы, догоняет набежавшие изменения. В конце работы берётся короткая блокировка, старая таблица удаляется, новая становится на её место.
Недостатком pg_repack является то, что она работает СЛИШКОМ БЫСТРО – фактически данные копируются и удваиваются в объёме (по отношению к исходной таблице). Каталог pg_wal забивается с такой скоростью, что архиватор не успевает обрабатывать файлы.
Далее описывается способ замедления работы pg_repack с использованием механизма cgroup.
Продолжаю делиться своими размышлениями в поисках оптимального решения разных проблем производительности ИТ-систем в рамках рубрики «Мысли в слух». Напомню, размышления больше теоретические и практических подтверждений могут как иметь, так и не иметь. Но поскольку исследования проводятся, часть из них, несомненно, войдёт в будущие практические решения, а часть так и останется теорией.
Хочу поднять проблему как объективно посчитать размер потребляемой оперативной памяти конкретным запросом в PostgreSQL. И предлагаю использовать для этого автоматическое нагрузочное тестирование. Такая вот сегодня постановка задачи.
В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.
Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.
Многие слышали о классической игре сокобан, а кто-то наверняка играл в "Мудрого крота" из Роботландии. В этой части мы будем двигать ящики по складу, используя возможности json[b] и геометрического типа point.
Приветствуем вас на заключительном этапе в цикле статей о Greenplum. Ранее мы уже обсудили то, как выглядит архитектура системы. Посмотрели «под капот», подробнее обсудили виды хостов и их предназначение, узнали, как обрабатываются запросы пользователей.
Во второй статье погрузились в то, какие виды таблиц бывают, что такое дистрибьюция и партиционирование, как можно начать оптимизировать работу с таблицами ещё на этапе их создания.
Освежить память о содержании предыдущих статей можно здесь и здесь.
В данной статье мы совместно с @omoskvinрасскажем о том, что влияет на оптимальность выполнения запросов, как отслеживать различные проблемы и, конечно же, как с ними справляться.
Речь здесь пойдёт о стабильности стандартной статистики Postgres и об идее очередного расширения - на этот раз альтернативы команде ANALYZE. Всё началось с того, что заканчивая работу над предыдущей статьёй я вдруг заметил, что результат выполнения одного и того же запроса теста Join Order Benchmark (JOB) в серии последовательных прогонов может отличаться в разы и даже на порядки - причем как по значению параметра execution-time, так и по pages-read. Это выглядело очень странно, поскольку и тест и ноутбук и все настройки оставались теми же - даже погода за окном. И я решил расследовать, что происходит …
