PostgreSQL *

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

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

Перед вами заключительная, третья часть обзора изменений в Greenplum 7. Если вы по каким-то причинам пропустили прошлые публикации, то их можно найти в нашем блоге здесь и здесь. А сегодня мы поговорим об изменениях в партиционировании таблиц и ресурсных группах, JIT-компиляции выражений и многом другом. Давайте начнём!

Доброго времени суток! Сегодня я продемонстрирую вам, как быстро и эффективно настроить PostgreSQL с помощью Docker Compose. Этот процесс займет всего несколько минут, но в результате вы получите полноценную базу данных PostgreSQL, работающую в изолированном Docker контейнере. Важные компоненты, такие как базы данных, таблицы и индексы, будут сохранены на вашей локальной машине благодаря использованию томов (volumes), что обеспечит надежность и доступность данных.

Приветствую, друзья! Сегодня мы разберемся, как деплоить бота с использованием Docker. Многие новички считают Docker сложным, но, прочитав эту статью, вы поймете, что это не так, и полюбите эту технологию.

Дисклеймер

Цель данного руководства — не обучение Docker, а пример использования этой технологии в контекте телеграмм ботов на aiogram 3. Я не буду сильно акцентировать внимание на таких вещах, как слои, volume, docker-compos, bridge и прочей технической информации более глубокого уровня, чем необходимо для деплоя ботов на VPS сервере.

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

Подготовка

Для начала вам нужно обзавестись базой данных PostgreSQL. О том, как развернуть ее на VPS сервере, я писал ТУТ. Также потребуется установить Docker. Новичкам будет удобнее поставить Docker Desktop, если с технологией уже знакомы, используйте консольный вариант.

Доброго дня! Хочу поделиться лайфхаком по реализации универсального способа пагинации в произвольных запроса к БД для получания списков.

Имеем изначально задачу по реализации HTTP REST CRUD сервера на Go. База данных - PostgreSQL. Используемый драйвер - pgx - PostgreSQL Driver and Toolkit.

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

Общее количество страниц в таблице БД получить несложно:

Добрый день, меня зовут Андрей, я специалист по администрированию баз данных в компании «Сервионика». За 2,5 года под моим контролем побывало около 700 кластеров баз данных, из которых 80 % — High Avaiability, треть из них — это трёхнодовые полноценные кластеры, где есть мастер, синхронная и асинхронная реплики. Также были успешно проведены проекты по миграции с Oracle и MSSQL на PostgreSQL.

Резервное копирование — один из важнейших процессов администрирования баз данных. К сожалению, никто не застрахован от сбоев оборудования или логических ошибок. Однажды мы столкнулись с ошибкой резервного копирования PostgreSQL, которая возникает у многих пользователей Pgbackrest. В сети нет единого описания её исправления. Расскажу о том, к какому решению мы пришли, и как в компании реализовано резервное копирование PostgreSQL.

Привет, друзья! Эта статья станет настоящей находкой для всех, кто уже знаком с библиотекой asyncpg-lite, хочет с ней познакомиться или просто стремится легко и эффективно использовать асинхронные возможности SQLAlchemy вместе с asyncpg.

Что такое asynpg-lite?

Представьте себе библиотеку, которая сочетает в себе мощь асинхронного программирования через asyncpg и безграничные возможности SQLAlchemy. Это asynpg-lite — простая и надёжная библиотека, созданная для того, чтобы каждый, даже новичок, мог воспользоваться её потенциалом.

Почему это важно?

В мире, где асинхронное программирование становится всё более востребованным, asynpg-lite предлагает идеальное решение для работы с PostgreSQL. Вам не нужны глубокие знания программирования или сложные концепции. Достаточно базового понимания Python (списки, словари, строки и т.д.) и основ SQL и PostgreSQL (таблицы, CRUD-операции, типы колонок и т.д.).

Что вас ждёт?

Мы начнем с самых основ и шаг за шагом разберём базовые методы этой библиотеки. Это позволит вам сразу же начать использовать её в своих проектах и ощутить все преимущества асинхронной работы с базой данных.

Готовы погрузиться в мир асинхронных операций на PostgreSQL с помощью asynpg-lite и SQLAlchemy? Тогда давайте начнем!

Привет! В этой статье я расскажу, как создать телеграм-бота на aiogram 3.7 с личным профилем, админ-панелью и реферальной системой. Мы пройдем через регистрацию пользователей, работу с базой данных PostgreSQL и многое другое. Жмите на "читать далее"!

У задачи перехода с Oracle на PostgreSQL есть два решения: правильное и бесплатное. Специалистов, которые хорошо разбираются в обоих серверных языках, в стране объективно мало, поэтому лучший вариант — доверить миграцию СУБД опытным подрядчикам. Однако некоторые компании перекладывают эту задачу на собственных сотрудников, причем «под раздачу» может попасть кто угодно: системный аналитик, бэкенд-разработчик или, скажем, бизнес-архитектор. Если вы — тот, на кого свалилась такая участь, то эта статья — для вас.

Привет, Хабр! Меня зовут Александр Брейман, я доцент департамента программной инженерии факультета компьютерных наук НИУ ВШЭ и по совместительству эксперт Учебного центра IBS. В этой статье расскажу, чем PL/SQL похож и чем отличается от PL/pgSQL, на что обратить внимание при переходе и какие инструменты могут вам с этим помочь.

Привет, друзья! Вот и добралась до вас обещанная публикация про интеграцию PostgreSQL в Telegram ботов.

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

Сегодня мы закроем этот вопрос.

В этой статье мы напишем:

Привет! Меня зовут Дима Татаринов, я занимаюсь бэкенд-разработкой в К2Тех. Мы живем в эпоху «великого переселения» СУБД с SQL Server, IBM DB2 и Oracle на отечественную СУБД Postgres Professional или аналоги. Подобные проекты «паровозиком» цепляют за собой потребность в модернизации бизнес-приложений, которые на них работали. Ранее зарубежные производители накладывали сильный вендор-лок с помощью экосистемы своих инструментов: от специализированного языка написания бизнес-логики (PL/SQL для Oracle) до сервера приложений. Именно поэтому особенно злободневной становится старая шутка про Oracle - «Oracle doesn't have clients. It has hostages» (У Oracle нет клиентов. Есть только заложники). 

Цена освобождения уже стала известна российским вендорам прикладного ПО, которые реализовали в своих продуктах миграцию на отечественные СУБД. Но что делать с тысячами так называемых «учетных систем», которые используют компании на момент принятия решения о миграции. Понятно, что затрат не избежать, но как сделать их предсказуемыми и не получить новый «вендор-лок» взамен старого?  

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

Компания Postgres Professional занимается разработкой и поддержкой СУБД с 2015 года. Это серьёзный срок для компании в ИТ-сфере, и за это время мы видели много случаев, когда клиенты сталкивались с неоптимальным выполнением запросов. Обычно оптимизатор PostgreSQL неплохо справляется и строит хорошие планы, если количества джойнов в запросе не больше 10 и данные в таблицах распределены равномерно. Однако в даже на изначально тщательно продуманной базе данных, оптимизатор может сгенерировать настолько неоптимальный план, что его время выполнения может увеличиться в разы. В некоторых особо экстремальных случаях даже практически невозможно дождаться окончания выполнения запроса и понять при помощи EXPLAIN ANALYZE, что пошло не так. Усугубляющим фактором является то, что оптимизатор PostgreSQL никак не запоминает допущенные ошибки выполнения. Построив неоптимальный план один раз, он с большей долей вероятности будет делать это снова и снова до тех пор, пока что-то не изменится: статистика, настройки оптимизатора или какое-то внутреннее состояние СУБД.

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

На протяжении своего существования наша компания пытается отвечать на эти вызовы, для чего, например, были разработаны расширения AQO и sr_plan. Сообщество PostgreSQL также не стоит на месте: в ванильной версии появилась расширенная статистика и был введён ряд оптимизаций вроде инкрементальной сортировки и материализации промежуточных результатов выполнения запроса.

Однако все эти методы или имеют мало предсказуемый результат (AQO), или требуют глубокого понимания причин возникшей проблемы с ручной донастройкой СУБД. В своей новой разработке мы решили взглянуть на проблему исправления ошибок оптимизации с другой стороны. Основная идея в том, чтобы добавить возможность перепланирования на основе полезных сведений, которые можно получить из уже частично выполненного запроса. Помимо этого нужно сформулировать критерии для плохо спланированных запросов, для которых необходимо провести перепланирование.

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

Сегодня мы поговорим об ещё одном новом для Greenplum типе индексов и не только.

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

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

Сейчас мы строим и проектируем 820 тыс. кв. м жилой и коммерческой недвижимости в высших ценовых сегментах. Это 13 девелоперских проектов в престижных районах Москвы. Это колоссальный объём данных, поступающих из разных подразделений: от продуктологов до менеджеров по продажам. Чтобы систематизировать эту информацию и управлять бизнес-процессами, мы реализуем BI-систему для сбора, хранения, анализа и наглядного отображения данных. В этой серии статей рассказываем о том, как мы выстраиваем её в девелоперской компании.

Друзья, в прошлых своих публикациях я рассказывал о том, что почти в каждом своем проекте использую свой класс для работы с базой данных PostgreSQL. На днях этот класс перерос в полноценную библиотеку asynpg-lite на базе asyncpg, которую каждый из вас может прямо сейчас установить и начать использовать.

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

Смысл этой библиотеки в том, чтобы каждый, даже если абсолютно не знаком с SQL-запросами, получил возможность взаимодействовать с базами данных PostgreSQL, используя стандартные питоновские списки, словари и строки.

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

С необходимостью переноса данных из Oracle столкнулись многие российские компании: в июле 2022 года корпорация, создавшая этот продукт, ушла с российского рынка из-за санкций, как и множество других зарубежных IT-компаний. У пользователей из нашей страны больше нет поддержки вендора, а значит со временем система может перестать корректно работать.

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

PostgreSQL: PostgreSQL 17 Beta 1 Released!

Вышла бета с 188 новшествами. Напомним, что Брюс Момджан недавно подчёркивал важность этого релиза из-за его некоторого уклона в оптимизацию, мол, большое число улучшений в оптимизации, это приятный сюрприз для меня.

В пояснительной записке к релизу тоже начинают с оптимизации. Первым делом рассказывают об изменениях в Vacuum. Там новая внутренняя структура, благодаря которой удалось сэкономить 20% памяти, а также сократить время самой очистки. Последний пункт касается редкой темы: в PostgreSQL 17 улучшена поддержка SIMD-инструкций.

Интересный, важный пункт - управление переключением при логической репликации (failover control for logical replication), важное для отказоустойчивых конфигураций.

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

Привет, меня зовут Катя Моисеева, я руководитель направления качества данных в Data Office Tele2. Мы уже рассказывали о том, как с нуля строили процессы качества данных на различных площадках (выступления можно посмотреть по ссылке).

Сейчас для нас остро встал вопрос о ресурсах нашей команды, а точнее их «резиновости» — поток входящих инцидентов растет по мере подключения новых систем к проверкам качества, а команда остается в составе 3 сотрудников. Возникает вопрос — а какая она, идеальная команда качества данных, которая сможет создать процессы с нуля, внедрить и привить культуру внутренним заказчикам, свести к минимуму риски возникновения инцидентов, а еще минимизировать затраты компании?

Под катом поделились своим опытом борьбы с хаосом из потока входящих задач и запросов от бизнеса и о маленьком роботе‑спасителе, который экономит нам ежедневно 5 часов сотрудника DQ и внедрить которого по силам каждому.

Или, точнее, задача, поскольку в этом году мы попробовали другой формат: задача была всего одна, но большая. Требовалось написать SQL-запрос, играющий в крестики-нолики «пять в ряд».