Всем доброго дня! Пишу здесь впервые. На написание меня этой статьи побудило желание рассказать людям об эффективном способе миграции от внутренней базы данных Sqlite3 к внешней БД PostgreSQL. Подобной статьи на Хабре я не нашел, поэтому надеюсь будет полезно.
В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.
Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.
Рекурсивно вычисляем логические выражения и разбираем устройство двоичного сумматора.
Postgres Professional продолжает публиковать книги о возможностях СУБД PostgreSQL. В этот раз представляем учебное пособие для тех, кто хочет стать маэстро в управлении базами данных.
Всем привет! Меня зовут Василий Куликов, я работаю ведущим разработчиком в Техплатформе Екома и Райдтеха Яндекса и последние пять лет разрабатываю фреймворк userver.
Это веб‑фреймворк, который позволяет создавать высоконагруженные отказоустойчивые сервисы на С++. Сегодня я расскажу, как написать на нём игрушечный, но рабочий сервис, который реализует функциональность pastebin.
Закончилось основное событие года в мире PostgreSQL - PgConf 2025. В статье рассматривается патч, который ускоряет закрытие месяца в 1С-ERP в 10 раз, что довольно значительно. Патч был анонсировано в докладе "Быстрое закрытие месяца в 1С:ERP на PostgreSQL" или "Закрывай месяц в 1С ERP на PostgreSQL быстро и незаметно".
С 1С:ERP я не знаком, но знаю, что для 1С выпускаются специальные сборки PostgreSQL. Наполнившись решимостью узнать, что в этом 1С происходит я пожертвовал докладом про карту видимости, который шёл параллельно и не пожалел.
Я узнал, что в 1С никто ничего не делает, кроме как месяца закрывают и больше никого ничего не интересует, а также то, что по статистике пользователи приложения 1С:ERP делают что-либо, в среднем, раз в 20 минут. "Закрытие месяца" - набор расчетов и действий, которые могут выполняться часами. При этом с первого раза месяц обычно не закрывается, так как обнаруживаются ошибки учёта, которые должны быть исправлены и закрытие месяца повторяется заново. И так несколько раз. В докладе осветили нюансы установки границы итогов, удобство использования клонов кластера баз данных, описали причины проблем.
Основная интрига доклада была в том, что "секретный патч Фёдора Сигаева" ускоряет закрытие месяца в 10 раз (на порядок!). Не каждый день встретишь ускорение на порядок.
В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.
Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.
Применяем простые операции над массивами, чтобы определить связность графов.
Всем привет, сегодня я хочу рассказать вам о своем опыте постановки PostgreSQL на сервере и какие при этом возникли сложности, а также о том как все это решилось.
Привет читатель, на связи Владимир, техлид команды бэкенд-разработки в fashion бренде Befree. За время жизни и развития нашего интернет-магазина накопилось некоторое количество любопытных, на наш взгляд, решений, и появилось желание начать делиться этими решениями с сообществом. Начнем с рассказа о каталоге товаров и о том как этот каталог со временем преображался.
Предыдущий каталог товаров делался во времена, когда и трафика, и товаров было в десятки раз меньше по сравнению нынешним временем. Тот каталог толком не имел механизмов для фильтрации и кастомизации. У менеджеров интернет-магазина не было инструментов управления логикой вывода товаров, чтобы покупатель видел то, что надо бизнесу. Много товаров терялось на задворках каталога, поэтому верно сказать, что для покупателя доля товаров оставалась не представлена, т.к. мало кто листает десятки страниц, чтобы найти там модель из новой коллекции, которая почему то не на первой странице. Это осложнялось еще и тем, что в каталоге имелся скудный набор характеристик товаров, что не давало вывести покупателям нормальные фильтры. Имелись и другие проблемы: при значительных скачках трафика, например во время рассылки пушей, каталог банально переставал справляться с нагрузкой.
Требования, которые команда сформулировала к новому каталогу:
Порядок столбцов в таблицах влияет на компактность и производительность. При небольшом числе строк на это не обращают внимание. Если в таблицах хранится много строк, то даже небольшое уменьшение объема хранения может быть полезно. У столбцов есть оптимальный порядок и менее оптимальные, которые отличаются размером, который используют строки при физическом хранении. Причина того, что переставив столбцы строки в таблице с теми же самыми данными, меняют размер в выравнивании (aligning) и заполнении нулями (padding). В блоке данных выравниваются все структуры: заголовки, поля строк и целиком сами строки.
На 64-разраядных операционных системах, длина любой строки и заголовка строки выравниваются по 8 байт. То есть если строка занимает 28 байт, то физически она займёт 32 байта. В конец строки будут добавлены пустые байты. Поля выравниваются сложнее - по 4,8, 16 байт. В статье рассматривается перестановка столбцов на примере демонстрационной базы.
Выбор подходящей системы управления базами данных (СУБД) — важнейшая задача при проектировании программных систем. Разработчики и архитекторы учитывают множество факторов: модель данных (реляционная или NoSQL), поддержку транзакций, масштабируемость, требования к согласованности и многого другое. Одним из ключевых архитектурных аспектов, влияющих на эффективность и надежность системы, является модель репликации данных. Репликация означает поддержание копий одних и тех же данных на нескольких узлах (серверах), соединённых по сети.
Зачем это нужно? Репликация позволяет: во-первых, держать данные ближе к пользователям (уменьшая задержку при запросах); во-вторых, продолжать работу системы даже при сбое отдельных узлов (повышая доступность); в-третьих, масштабировать систему, увеличивая число узлов для обслуживания запросов на чтение (повышая пропускную способность).
Однако реализация репликации сопряжена с серьёзными архитектурными компромиссами. Согласно теореме CAP, в распределённой системе невозможно одновременно гарантировать все три свойства: консистентность данных, доступность сервиса и устойчивость к разделению сети. При возникновении сетевых сбоев (разбиении на изолированные сегменты) системе приходится жертвовать либо мгновенной согласованностью данных, либо доступностью части узлов. Поэтому разные СУБД делают разные выборы в этих компромиссах. Архитектурная модель репликации, лежащая в основе СУБД, определяет, как база данных достигает (или не достигает) консистентности, доступности и отказоустойчивости. Понимание этих различий крайне важно для архитекторов и разработчиков: зная поведение репликации, вы сможете выбрать такую СУБД, которая лучше соответствует требованиям вашего проекта по масштабу, геораспределенности, допустимой задержке и устойчивости к сбоям.
По прогнозу Gartner, запросы на естественном языке вытеснят SQL уже в 2026 году. Возможно, прогноз Gartner чересчур оптимистичный, но если они и ошибаются, то только в сроках — сам переход на естественный язык в работе с БД неизбежен.
Go. PgxWrappy как решение всех проблем PgX. Если вы сталкивались с неудобным сканом в структуры посредством PgX на Go, то гляньте эту либу. Она решает все проблемы сканинга.
Привет, ХАБР! Я Хаймин Владимир, эксперт по системам управления базами данных PostgreSQL в ВТБ. Когда размеры таблиц становятся большими — обслуживание и доступ к данным становятся непростой задачей. Я хочу поделиться методикой организации секционирования в PostgreSQL, которая существенно упростила нам жизнь с таблицами большого размера, хранящие, например, исторические данные по датам. Назовем ее условно «Корзинным секционированием» (Basket partitioning). Данная технология реализована архитектурно, без необходимости расширения функционала сторонними инструментами или расширениями только штатными средствами ванильных версий PostgreSQL. Такая система хранения реализована, например, в проекте мониторинга pg_awr для упрощения удаления старых данных.
Секционирование в PostgreSQL
Секционирование — это техника разбиения одной большой таблицы базы данных (БД) на несколько меньших, логически связанных частей, называемых секциями. При этом, такая таблица с точки зрения ППО выглядит как одна большая таблица.
Современные версии PostgreSQL имеют достаточно развитые средства для работы с секционированными таблицами. При этом, несмотря на то что страдает автоматизация, например, создания и удаления секций, при правильной организации хранения данных работать с такой БД достаточно удобно. И эти удобства минимизируют вероятные ошибки.
PostgreSQL начиная с 10 версии, помимо наследования, поддерживается декларативное секционирование: диапазонное, списочное, хэш-секционирование.
Какие бывают базы данных по методу их наполнения и использования?
В распределённых базах данных YDB, CockroachDB по умолчанию используется уровень изоляции SERIALIZABLE. В PostgreSQL, Oracle Database, MySQL по умолчанию используется READ COMMITED. В стандарте SQL указаны только три аномалии. В статье приводится пример аномалии потерянного обновления в задаче "списания средств" и рассматривается, почему уровень READ COMMITED и ограничения целостности достаточны для решения задачи.
Если с данными (строками таблиц) работает одна сессия в базе данных, то разницы между уровнями изоляции транзакций нет, так как нет транзакций, от которых нужно изолироваться. Если есть несколько транзакций, которые пересекаются во времени, то нужно обращать внимание на то, что параллельно с теми же данными работают другие транзакции. Другими словами, учитывать особенности (феномены, аномалии) "конкурентного доступа".
Ведущий инженер-разработчик Postgres Professional Николай Шаплов столкнулся с неожиданной проблемой при тестировании: коллизии хэшей в clang ломали метрики покрытия. Расскажем, как удалось решить эту задачу и что это меняет для всего сообщества.
В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.
Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.
Используем оконные функции, чтобы вычислить "третью производную".
Даже не знаю, как пропустил эту новость. Обычно я всё активно отслеживаю, особенно уязвимости опенсорсного ПО, которые касаются казначейства моей страны 🤷♂
В представлении pg_locks есть столбец fastpath, который означает, что блокировка получена по быстрому пути. В документации быстрый путь блокирования описан коротко. В статье рассматривается быстрый путь блокирования и чем он лучше обычного пути.
Компания Postgres Professional выпустила обновленную книгу Егора Рогова «PostgreSQL 17 изнутри», которая станет настольной для тех, кто хочет понимать, как устроена СУБД. От многоверсионности до типов индексов – все, что нужно для эффективной работы и оптимизации, теперь под рукой.
В мире разработки и эксплуатации ПО мажорные обновления — это всегда стресс. Независимо от того, насколько хорошо вы тестируете изменения, всегда есть риск, что что-то пойдёт не так. Особенно это касается обновлений, которые затрагивают пользовательские данные. В какой-то момент мы задумались о том, как нам минимизировать риски и сделать обновления более предсказуемыми.
Меня зовут Кристина Демидович, я DevOps‑инженер в СберТехе, занимаюсь автоматизацией в команде СУБД Pangolin — это целевая СУБД в Сбере и не только. Я расскажу о нашем подходе к обновлению СУБД Pangolin, который позволил нам превратить часть мажорных обновлений в обновление данных системного каталога — что проще, удобнее и занимает вдвое меньше времени.
Надеюсь, наш опыт будет полезен тем, кто занимается автоматизацией и имеет дело с обновлением сложных систем.
