PostgreSQL *

Эта статья открывает цикл о новостях будущей, 18-ой, версии PostgreSQL. Рассмотрим следующие возможности попавшие в июльский коммитфест.

Планировщик: поддержка правого полусоединения хешированием
Планировщик: материализация внутреннего набора строк для соединения вложенными циклами в параллельном плане
Вспомогательные функции планировщика для generate_series
EXPLAIN (analyze): статистика рабочих процессов узла Parallel Bitmap Heap Scan
Функции min и max для составных типов
Имена параметров для функций regexp*
Режим отладки в pgbench
pg_get_backend_memory_contexts: столбец path вместо parent и новый столбец type
Функция pg_get_acl
pg_upgrade: оптимизация работы pg_dump
Предопределенная роль pg_signal_autovacuum_worker

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

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

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

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

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

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

Опять-двадцать пять, или резервное копирование баз данных PostgreSQL по новому. Снова.

В прошлой публикации мы обсудили механизм парсинга, оптимизации и исполнения запроса в PostgreSQL. В процессе обсуждения, был также затронут WAL (Write-Ahead Log). Давайте разберемся, что же это такое.

WAL, он же Write Ahead Log - бинарный лог, хранящий в бинарном виде непоcредственные результаты исполнения транзакций, модифицирующих текущее состояние данных. Речь идет о запросах INSERT, UPDATE и DELETE.

WAL обеспечивает Durability из ACID, т.е. сохранность данных в случае любых возможных сбоев.  Тем не менее, ошибочно представлять себе WAL как бэкап данных. Смысл данного механизма не в хранении копии всех созданных и измененных данных с момента создания бд.

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

MariaDB Server исполняется 15 лет! Вот 15 причин, по которым разработчики и администраторы баз данных любят его!

Буквально месяц назад, мы с моим коллегой участвовали в HAKATON. Наша команда взялась за интересную задачу от компании МТС: на основе тысяч опросов, найти усредненный синоним к определенной категории ответов и визуализировать это в виде графика, либо облака слов.

После выполнения задачи и защиты проекта мы задумались...

Третья статья цикла по асинхронному SQLAlchemy 2 посвящена оптимизации кода, обновлению и удалению данных. Рассмотрены улучшения базового класса, подходы к обновлению записей и методы удаления, с акцентом на повышение производительности. Нажмите «Читать», чтобы ознакомиться с материалом.

Здравствуйте, дорогие друзья! Сегодня мы окунёмся в мир SQL запросов и рассмотрим различные подходы, которые разработчики используют для работы с данными в БД. В современном мире разработки, где информация становитесь все больше и больше, и скорость получения данных имеет большое значение, умение эффективно извлекать и обрабатывать данные становится неотъемлемой частью работы многих SQL специалистов (особенно тех кто работает с нагруженными системами и DWH). Мы поговорим о таких методах, как Common Table Expressions (CTE), подзапросы, представления и материализованные представления.

Как известно, многие реляционные базы данных, а в данном конкретном случае PostgreSQL, обещают нам, что наши транзакции будут обладать соответствовать критериям ACID (Атомарность, Согласованность, Изолированность, Сохраняемость), при должном уровне конфигурирования тех или иных настроек.

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

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

Давайте представим ситуацию, что у нас есть база данных, в которой есть простенькая таблица:

Задача такая: искал Open Source БД для своего пет-проекта. Решил посмотреть в интернете новые решения в рамках БД. После чтения статей и отбора из 6-7 БД остались три (3), которые понравились лично мне. Больше ничего путного не нашел. 

Почему именно эти? Во-первых, они Open Source, а во-вторых, у них есть ответы на два главных моих вопроса «Для чего это нужно?» и «Работает ли из коробки?».

Давайте покажу на примерах.

Привет! Меня зовут Полина Кудрявцева, я инженер DBA в Авито. В этой статье я расскажу о том, как мы внедрили CockroachDB на DBaaS в компанию классических СУБД, а также опишу его плюсы, минусы и особенности работы.

PostgreSQL: PostgreSQL 17 Released!

Новшества давно известны (в том числе из обзоров Павла Лузанова PostgreSQL 17: Часть 5, 4, 3, 2, 1), но интересно, что выбрали в сообществе как самое-самое важное. Выбрали вот что:

Производительность:

переработанное управление памятью (overhauled memory management) при вакууме,

оптимизация доступа к хранению и улучшение работы при параллельных нагрузках (high concurrency workloads),

ускорение при массовой загрузке и экспорте,

улучшения работы с индексами.

Работа с новыми типами нагрузок:

реализация SQL/JSON JSON_TABLE .

Для высококритичных систем:

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

А вот что привлекло внимание сразу нескольких комментаторов: изменения в оформлении самих пресс-релизов:

More Release Note Details

Этой статьей мы начинаем цикл, посвященный различным настройкам по оперативной памяти в PostgreSQL. Тема непростая, даже сложная. Понятной информации по ней крайне мало (по состоянию на октябрь 2024). Поэтому будем разбираться, шаг за шагом, вдумчиво и, как принято у нас в блоге, подкреплять все выводы исследованиями и картиной из программы мониторинга PERFEXPERT (версия для PG).

Привет всем!

Я — Ипатов Александр, backend‑разработчик в ГК Юзтех. Сегодня хочу поделиться своим опытом в интересном проекте, связанном с миграцией БД MsSQL на PostgreSQL в разрезе оптимизации хранимых процедур и функций (далее — хранимых процедур, так как процесс оптимизации не сильно завязан на том, что именно имеем на выходе).

Актуальность проектов, связанных с миграциями серверов и баз данных с зарубежных платных продуктов (Microsoft, Oracle) на аналогичные отечественные или зарубежные open‑source решения (в разрезе статьи будем рассматривать Postgres) в 2024 году очень велика. Те решения, которые были реализованы и поддерживались на протяжении 5–10 лет, потребовалось практически в формате «пожара» переносить на аналогичные. А бизнес, который привык к уже полностью сформированным и отработанным рабочим процессам, не готов к потере эффективности и, как следствие, потере клиентов сервисов, заказов и бизнес‑метрик.

В одном из таких проектов мне удалось поучаствовать. Из начальных условий: проект по переносу БД из MsSQL начался примерно 3 года назад.

На самом деле, проект был более обширный — перенос монолитного сервиса на микросервисы, в том числе, как один из элементов — перенос БД.

Хочется отметить, что перенос схем, таблиц, индексов и других элементов базы данных прошел относительно спокойно. Чего не скажешь о переносе хранимых процедур. Язык T‑SQL, на котором пишутся хранимые процедуры в MsSQL, конечно же имеет отличия от PL/pgSQL, который используется в PostgreSQL. В связи с чем, непосредственно миграция хранимых процедур заняла много времени: точное число хранимых процедур я не назову, но порядок — около 800 штук (среди которых 500 стали работать хуже после миграции, их то и предстояло оптимизировать).

В этой статье мы расскажем о том, как эффективно реализовать полнотекстовый поиск с помощью PostgreSQL. Узнайте, как улучшить скорость и точность поиска по текстовым данным, используя такие инструменты, как tsvector, tsquery и индексы GIN, и как эти возможности могут значительно повысить производительность вашего приложения.

В очередной рабочий день поступила задача обновить Gitlab. Задача в общем-то не сложная, ни смотря на то, что там он установлен в докере из многим знакомого образа от sameersbn, что впоследствии было переделано на omnibus (что бы это не значило), т.к. по моему опыту omnibus версия (установка на чистый линукс) гораздо проще и предсказуемей в эксплуатации. Впрочем статья совсем не об этом.

Но как можно понять из наличия этой статьи, что-то пошло не так...

Так исторически сложилось, что задача организации простого и понятного резервного копирования в мире PostgreSQL до сих пор не решена. Есть набор комьюнити утилит, у каждой из которых есть некие плюсы, но всегда в нагрузку будет прорва минусов (тут нет инкрементных копий, там нет внятного расписания, это может только весь сервер вместо конкретной базы увозить и так далее). Да, есть тяжёловесный энтерпрайзный софт за много денег, зачастую требующий странного и работающий по какой-то своей логике, но это тоже не панацея. А вот чтобы просто и понятно, без головных болей организовать прозрачный процесс банального бекапа с инкрементами, работающим расписанием и восстановления только того что надо - вот такого нет.

Но буквально на днях вышел PostgreSQL 17 и может там что-то изменилось? И да, и нет. Та самая мана небесная в виде pg_awesome_backup_tool так и не появилась, однако в релиз попал механизм walsummarizer, который обещает нативно отслеживать изменения в файлах баз данных, что позволит делать инкрементальные бекапы нативно и без лишних приседаний.

А чтобы не рассматривать новичка в вакууме, будем сравнивать его с ptrack - нашей (Postgres Professional) разработкой, которую наши любимые конкуренты уже расхватали в свои продукты и продают их как уникальнейшие решения.

В моей работе, когда приходится исследовать и нагружать СУБД нетипичной нагрузкой и синтетическими тестами, часто встречаются случаи загадочного поведения системы: ускорение/замедление времени выполнения запроса на пару порядков, отказ использовать тот или иной индекс и тд. Объяснение странного поведения оказывается в итоге почти всегда тривиальным и хорошо известным опытным DBA. Однако встретив его в реальной эксплуатации первый раз невольно теряешься и на разбор кейса уходит много времени. Вместе с тем, это достаточно интересное упражнение - навроде того, как прорешать задачник по аэродинамике после 10 лет проектирования планеров самолётов. Поэтому предлагаю здесь попробовать формат обсуждения/изучения PostgreSQL в виде задач. Вдруг зайдёт?

Привет, Хабр! Меня зовут Михаил Герасимов. Это продолжение статьи «Как в РСХБ разработали средство генерации SQL-запроса для упрощения задач по тестированию», где описывались принципы работы QueryBuilder. 

В условиях растущего тренда на импортозамещение в ИТ-компаниях, переход с коммерческих СУБД на Open Source решения стал одной из ключевых задач для многих организаций. В частности, в проекте по автоматизации тестирования специалисты РСХБ успешно адаптировали свой инструмент генерации SQL-запросов QueryBuilder к переходу на PostgreSQL.