PostgreSQL *

Чего у меня не отнять, дак это мастерства заголовка...

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

Данная статья является легким переосмыслением того, что я написал на медиуме. Ибо думать я продолжаю на русском.

TL;DR исходники к вашим услугам.

В рамках любых взаимодействий мы сталкиваемся с такими сущностями как авторизация и аутентификация. Повторять в 100500 раз что есть что я не буду (но мне не лень такую длинную ремарку напечатать, ага). В рамках PostgreSQL первое обеспечивается через Roles, а второе через Privileges.

Весна уже в разгаре, а мы вспомним горячие новости самого зимнего, январского коммитфеста. И сразу начнем с козырей.

Предыдущие статьи о 17-й версии: 2023-07, 2023-09, 2023-11.

Привет, я Паша, разработчик в Yandex Infrastructure, и я катаю гусей. С 2019 года я развиваю S3-хранилище как для внутренних пользователей Яндекса, так и для клиентов Yandex Cloud. А «гусём» называется наш бэкенд S3 API: он написан на Go, а из словосочетания Go + S3 получился goose. Возможно, вы также слышали про GeeseFS — это наш высокопроизводительный FUSE-клиент для S3. C его помощью вы можете на своём ноутбуке или виртуалке подмонтировать папку, которая будет работать с бакетом S3. 

Для чего нам «гуси» и прочая орнитология? Яндексовая инсталляция хранилища S3 хранит миллиарды файлов. Это огромные объёмы данных, а также метаданных. Для хранения метаданных мы научились использовать умное шардирование, и теперь сами управляем распределением занятого места и нагрузкой между шардами баз.

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

Материал подойдет для студентов и тех кто только начинает создавать распределенные базы данных.

Всем доброго дня, дорогие Хабровчане! Решил поделиться созданием связаннх серверов, поскольку информации в интеренете много, но не везде описываются все мелочи.

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

Однако из-за ряда ограничений SQL Server постепенно теряет своих пользователей. SQL Server имеет достаточно сковывающую лицензию и стоимость обслуживания, растущую по мере увеличения размера базы данных или числа клиентов. Ее максимальный размер составляет 10 ГБ, а буферный кэш — 1 МБ. Она работает только под Windows.

Переманить же пользователей SQL Server может PostgreSQL — полностью бесплатная база данных с открытым исходным кодом. Эта база данных может похвастаться поддержкой международного сообщества и доступна под Windows, Mac, Linux, FreeBSD и Solaris. Кроме того, для нее существуют множество опенсорсных дополнений.

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

Когда говорят «мы ускорили выполнение нашего запроса в N раз» это значит, что сначала сделали плохо а потом начали думать как улучшить.

Так я думал раньше.

Статический анализ структуры базы данных — это процесс выявления ошибок, нерекомендуемых практик и потенциальных проблем в базе данных только на основе структуры, типов данных, свойствах объектов. Статиеский анализ структуры не задействует ни пользовательские данные, ни статистику по таким данным.

Рассмотрим подробнее статический анализ структуры базы данных — что это, какие задачи решает, как интегрировать статический анализ в CI.

Завершаем серию статей о плагинах для explain.tensor.ru -  сервиса визуализации PostgreSQL-планов. На этот раз речь пойдет о плагине для Sublime Text.

Приветствую, current_user()!

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

Так-же хотелось-бы узнать твоё мнение о таком подходе и обсудить, возможно стоит что-нибудь добавить в нём.

Общеизвестно, что PostgreSQL - крайне эффективная СУБД с богатой функциональностью. При этом не секрет, что PostgreSQL масштабируется только вертикально и её производительность ограничена возможностями одного сервера.

Написано много хороших постов, в которых сравнивают архитектуру монолитных и распределенных СУБД. К сожалению, обычно авторы ограничиваются теоретическим сравнением и не приводят конкретные цифры. Данный пост же наоборот основан на эмпирическом исследовании с использованием бенчмарка TPC-C, который является промышленным стандартом для оценки производительности транзакционных СУБД (On-Line Transaction Processing, OLTP).

Мы расскажем, когда именно одного Postgres'a становится мало, и какие возможны компромиссы между производительностью и надежностью. Для тех, кто не готов к компромиссам, мы покажем, что могут предложить такие распределенные СУБД, как CockroachDB и YDB.

Анализ планов и форматирование запросов PostgreSQL удобно выполнять в VS Code, используя explain.tensor.ru и плагин, о котором пойдет речь ниже.

Новые контрибьюторы PostgreSQL:

Бертран Друво (Bertrand Drouvot),

Габриэль Бартолини (Gabriele Bartolini),

Ришар Гуо (Richard Guo).

Новые главные (major) контрибьюторы PostgreSQL, прибавилось два представителя Microsoft и один от Amazon:

Александр Лахин (Alexander Lakhin) - особенно поздравляем!

Дэниэл Густафссон (Daniel Gustafsson, Microsoft),

Дин Рашид (Dean Rasheed),

Джон Нэйлор (John Naylor),

Мелани Плейгман (Melanie Plageman, Microsoft),

Натан Боссарт (Nathan Bossart, Amazon Web Services).

Всех поздравляем! Страница контрибьюторов здесь.

Who's in Charge?

Всем привет! Меня зовут Виктор, я работаю в Компании БФТ-Холдинг руководителем группы разработки. В этой статье разберем подходы и рекомендации по выявлению и устранению проблем с производительностью в системе базы данных Greenplum. Материал будет особенно полезен начинающим разработчикам Greenplum, которые пока не имеют достаточного опыта «чтения» плана запроса.

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

В прошлой статье я показал, как условие с парой однотипных неравенств, плохо поддающееся индексации с помощью btree, можно переделать на эффективно gist-индексируемое в PostgreSQL условие относительно диапазонных типов, а наш сервис анализа планов запросов explain.tensor.ru подскажет, как именно это сделать.

Но что делать, если неравенств у нас не два, а целых четыре, да еще и с разными типами участвующих полей? Например, для целей бизнеса это может быть задачей вроде "найди мне все продажи за декабрь на сумму 10-20K", что на SQL будет выглядеть примерно так:

dt >= '2023-12-01'::date AND dt <= '2023-12-31'::date AND

sum >= 10000::numeric AND sum <= 20000::numeric

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

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

Pgpool-II также поддерживает множественные режимы репликации, включая репликацию на уровне строки и репликацию на уровне транзакций. Репликация на уровне строки позволяет синхронизировать изменения данных между серверами в реальном времени, в то время как репликация на уровне транзакций сосредотачивается на синхронизации транзакций целиком.

Некоторое время назад у нас возникла задача организовать возможность создания managed баз данных. Сложность данной задачи в том, что нам надо развертывать и управлять тысячами баз данных PostgreSQL, которые обеспечивают репликацию, бэкапы, мониторинг и другие полезные пользователям функции. При этом в ядре нашей системы лежит Kubernetes, в котором запускаются приложения пользователей. И по ряду факторов нам требовалось запускать базы данных внутри кластера.

Чтобы не изобретать велосипед, мы решили рассмотреть известные операторы, позволяющие разворачивать базы данных PostgreSQL в Kubernetes и управлять ими.

Я уже не раз писал, что условия с несколькими неравенствами (<, <=, >=, >) обычно плохо подходят для индексирования "классическим" btree, вызывают "тормоза", и необходимо придумывать различные нетривиальные подходы в PostgreSQL, чтобы добиться хорошей производительности подобного запроса.

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

Управление резервными копиями является одним из ключевых моментов в любой стратегии администрирования баз данных. Это гарантирует, что в случае сбоя или потери данных вы можете быстро восстановить всю информацию. pgBackRest — популярное решение для резервного копирования и восстановления PostgreSQL, которое предоставляет множество функций для управления резервными копиями. Тем не менее, по умолчанию стандартная конфигурация pgBackRest часто объединяет операции резервного копирования и удаления устаревших копий в одном процессе. 

В прошлый раз я описал, как можно поставить задачу (Job) в очередь Laravel из хранимой процедуры или триггера PostgreSQL.

В этой статье я расскажу, как можно преобразовать события, возникающие в PostgreSQL, в события Laravel.

Рабочий пример выложен на GitHub.

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

Если вы посмотрите на PG16 release notes, то увидите некоторые из этих улучшений. Но из-за объема изменений, вносимых в каждом выпуске PostgreSQL, невозможно предоставить достаточно подробную информацию о каждом изменении.

В этом посте вы получите глубокое представление о 10 улучшениях, внесенных в планировщик запросов PostgreSQL 16. Для каждого из улучшений будет сравнения выходных данных планировщика PG15 и PG16, а также примеры того, что изменилось, в виде автономного теста, который вы можете попробовать сами.