Как стать автором
Поиск
Написать публикацию
Обновить
171.9

PostgreSQL *

Свободная объектно-реляционная СУБД

Сначала показывать
Порог рейтинга
Уровень сложности

Секционирование в PostgreSQL. Архитектура корзинного хранения данных. (Basket partitioning)

Уровень сложностиСредний
Время на прочтение9 мин
Количество просмотров5.2K

Привет, ХАБР! Я Хаймин Владимир, эксперт по системам управления базами данных PostgreSQL в ВТБ. Когда размеры таблиц становятся большими — обслуживание и доступ к данным становятся непростой задачей. Я хочу поделиться методикой организации секционирования в PostgreSQL, которая существенно упростила нам жизнь с таблицами большого размера, хранящие, например, исторические данные по датам. Назовем ее условно «Корзинным секционированием» (Basket partitioning). Данная технология реализована архитектурно, без необходимости расширения функционала сторонними инструментами или расширениями только штатными средствами ванильных версий PostgreSQL. Такая система хранения реализована, например, в проекте мониторинга pg_awr для упрощения удаления старых данных.

Секционирование в PostgreSQL

Секционирование — это техника разбиения одной большой таблицы базы данных (БД) на несколько меньших, логически связанных частей, называемых секциями. При этом, такая таблица с точки зрения ППО выглядит как одна большая таблица. 

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

PostgreSQL начиная с 10 версии, помимо наследования, поддерживается декларативное секционирование: диапазонное, списочное, хэш-секционирование.

Какие бывают базы данных по методу их наполнения и использования?

Читать далее

Аномалии конкурентного доступа

Уровень сложностиСложный
Время на прочтение9 мин
Количество просмотров2.7K

В распределённых базах данных YDB, CockroachDB по умолчанию используется уровень изоляции SERIALIZABLE. В PostgreSQL, Oracle Database, MySQL по умолчанию используется READ COMMITED. В стандарте SQL указаны только три аномалии. В статье приводится пример аномалии потерянного обновления в задаче "списания средств" и рассматривается, почему уровень READ COMMITED и ограничения целостности достаточны для решения задачи.

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

Читать далее

Улучшаем компиляторы. Не сами, но без нас никак

Уровень сложностиПростой
Время на прочтение3 мин
Количество просмотров2K

Ведущий инженер-разработчик Postgres Professional Николай Шаплов столкнулся с неожиданной проблемой при тестировании: коллизии хэшей в clang ломали метрики покрытия. Расскажем, как удалось решить эту задачу и что это меняет для всего сообщества.

Читать далее

SQL HowTo: оконные функции (Advent of Code 2024, Day 22: Monkey Market)

Уровень сложностиПростой
Время на прочтение10 мин
Количество просмотров2.8K

В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.

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

Используем оконные функции, чтобы вычислить "третью производную".

Читать далее

О скрытии сообщений в эмодзи и взломе казначейства США

Уровень сложностиСредний
Время на прочтение7 мин
Количество просмотров15K

30 декабря 2024 года, пока большинство из нас суетились в преддверии празднования Нового года, Казначейство США готовило для Финансового комитета Сената США важное уведомление. В нём сообщалось, что его системы, которые, очевидно, содержат особо чувствительные конфиденциальные данные, были взломаны группой правительственных хакеров Китая.

Даже не знаю, как пропустил эту новость. Обычно я всё активно отслеживаю, особенно уязвимости опенсорсного ПО, которые касаются казначейства моей страны 🤷‍♂‍

И это ещё не самое безумное. Сейчас я расскажу вам, как именно они это сделали!
Читать дальше →

Быстрый путь блокирования в PostgreSQL

Уровень сложностиСложный
Время на прочтение9 мин
Количество просмотров4.2K

В представлении pg_locks есть столбец fastpath, который означает, что блокировка получена по быстрому пути. В документации быстрый путь блокирования описан коротко. В статье рассматривается быстрый путь блокирования и чем он лучше обычного пути.

Читать далее

Книга «PostgreSQL 17 изнутри»: заглянем под капот слона

Уровень сложностиПростой
Время на прочтение3 мин
Количество просмотров6.2K

Компания Postgres Professional выпустила обновленную книгу Егора Рогова «PostgreSQL 17 изнутри», которая станет настольной для тех, кто хочет понимать, как устроена СУБД. От многоверсионности до типов индексов – все, что нужно для эффективной работы и оптимизации, теперь под рукой.

Читать обзор книги

Укрощаем мажорные обновления: сценарий обновления системных данных каталога без лишней боли

Уровень сложностиСредний
Время на прочтение15 мин
Количество просмотров1.2K

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

Меня зовут Кристина Демидович, я DevOps‑инженер в СберТехе, занимаюсь автоматизацией в команде СУБД Pangolin — это целевая СУБД в Сбере и не только. Я расскажу о нашем подходе к обновлению СУБД Pangolin, который позволил нам превратить часть мажорных обновлений в обновление данных системного каталога — что проще, удобнее и занимает вдвое меньше времени.

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

Читать далее

Делаем жизнь легче: быстрый поиск в django и postgresql с помощью search_vector

Уровень сложностиСредний
Время на прочтение28 мин
Количество просмотров5.5K

Привет, меня зовут Таня и я backend-разработчик в ИдаПроджект

Сегодня хочу рассказать о полнотекстовом поиске — как это все работает в django, а как в postgres, и откуда вообще взялось. 

Современные компании ежедневно сталкиваются с разной текстовой информацией. Эффективный поиск не только ускоряет доступ к нужным данным, но и повышает продуктивность, снижает затраты и открывает новые возможности для анализа и принятия решений. 

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

Ну что, погнали! Разберем, как эта технология развивалась, и какие ее ключевые элементы (триграммы и tsvector) делают возможным быстрый и точный доступ к информации.

Читать далее

Процедура обнаружения взаимоблокировок в PostgreSQL

Уровень сложностиСредний
Время на прочтение8 мин
Количество просмотров4.1K

РostgreSQL автоматически обнаруживает взаимоблокировки. В статье рассматривается процедура обнаружения взаимоблокировок, трудоёмкость процедуры обнаружения, причины, по которым параметр конфигурации log_lock_waits зависит от параметра deadlock_timeout и что влияет на выбор его значения. Приводится пример, как использование select for update может приводить к взаимоблокировкам и как взаимоблокировки влияют на метрики pgbench.

Читать далее

Postgresso #2

Время на прочтение24 мин
Количество просмотров1.9K

TDE и философия open source

Началось всё с того, что Брюс Момджан написал в своём блоге:

Wish I Was Wrong About Tde

Брюс говорит, что по переписке в декабре 2024 стало понятно, что для дальнейшей разработки требуются изменения в буферах чтения/записи, в WAL, к тому же нужно придумать способ хранения секретных ключей. Я считал, - говорит он, - что такие изменения оправданы важностью TDE для вопросов безопасности. Баланс мнений склонялся к тому, что слишком много кода надо менять, и что в ближайшее время ждать TDE в версии сообщества не приходится. Брюс далее цитирует свой прошлогодний пост.

Читать далее

SQL HowTo: моделирование против подсчета (Advent of Code 2024, Day 21: Keypad Conundrum)

Уровень сложностиСредний
Время на прочтение17 мин
Количество просмотров740

В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.

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

Пробуем смоделировать преобразования строк "в лоб", а потом - организовать подсчет и решить более сложную задачу в разы быстрее простой!

Читать далее

Пишем свой FDW для PostgreSQL

Уровень сложностиПростой
Время на прочтение10 мин
Количество просмотров4K

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

В этой статье быстро разберём, как устроен PostgreSQL – от хранения данных в Heap и работы с FSM/VM до создания своего FDW с компрессией на базе zlib.

Читать далее

Ближайшие события

Путь к масштабированию PostgreSQL: от теории к практике

Уровень сложностиСредний
Время на прочтение4 мин
Количество просмотров6.1K

"Postgres масштабируется" - нет других двух слов, которые вызывали бы больше споров. По крайней мере, в кругах, где я общаюсь, в подвале компании, где инфраструктурные эльфы заставляют Rails-приложение работать. Многие верят, вопреки всему и маркетинговым кампаниям Big NoSQL, что знакомая технология лучше, чем новый неизвестный инструмент, о котором только что рассказали на совещании руководства.

Честно говоря, я понимаю их позицию. Заставить Postgres писать больше данных может быть сложно. Вам нужно больше оборудования. В большинстве случаев его можно получить, просто нажав кнопку "Обновить". Но когда вы дошли до экземпляра r5.24xlarge с 5 репликами такого же размера, и ваши процессы vacuum всё ещё отстают от графика, ситуация становится довольно пугающей.

Именно здесь начинается испытание для настоящего инженера. На пределе возможностей. Я говорю не о WebAssembly. Я говорю об инженерном духе, который смотрит на проблему под давлением руководства и вместо того, чтобы бежать к ближайшей команде продаж с большими обещаниями (но малым количеством фактов о вашем конкретном случае), решает её, используя базовые принципы.

А базовый принцип говорит нам, что нам нужно. У Postgres закончилась пропускная способность для записи. Либо из-за блокировок при работе с WAL, либо что-то застопорило vacuum. Вероятно, это та неактивная транзакция, которая открыта уже 45 секунд, пока приложение делает запрос к Stripe, но это не наша забота. Мы - инфраструктурная команда, и наша задача - заставить базу данных работать.

Читать далее

Маскировка объектов схем в подпрограммах SECURITY DEFINER в PostgreSQL

Уровень сложностиСредний
Время на прочтение4 мин
Количество просмотров1.2K

Подпрограммы (функции и процедуры) со свойством SECURITY DEFINER выполняются с правами владельца. Это даёт возможность непривилегированному пользователю выполнить маскировку объектов, к которым относятся не только таблицы, но и подпрограммы и выполнить команду с правами владельца подпрограммы. Если владелец является суперпользователем, то можно выполнить любую команду с правами суперпользователя. В статье рассматривается, как выполнить маскировку функции и как создавать безопасные подпрограммы.

Читать далее

Хранение пустых (NULL) значений в таблицах PostgreSQL

Уровень сложностиСложный
Время на прочтение6 мин
Количество просмотров6.8K

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

Читать далее

Использование JSONB-полей вместо EAV в PostgreSQL

Уровень сложностиПростой
Время на прочтение7 мин
Количество просмотров5.6K

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

Читать далее

A/B-тесты в PostgreSQL

Уровень сложностиПростой
Время на прочтение7 мин
Количество просмотров2.7K

Привет, Хабр! Сегодня разберём, как реализовать A/B-тестирование на чистом PostgreSQL, без выгрузки данных в сторонние системы. Рассмотрим полный цикл: от структуры таблиц и оптимизации запросов до статистического анализа (T-тест, Манна-Уитни, байесовские методы) и визуализации результатов.

Читать далее

Синхронизация файлов при запуске экземпляра PostgreSQL

Уровень сложностиСредний
Время на прочтение8 мин
Количество просмотров2K

Если экземпляр PostgreSQL был некорректно остановлен, то перед восстановлением файлов выполняется синхронизаций всех файлов кластера. Способ синхронизации определяется параметром конфигурации recovery_init_sync_method. В статье рассматривается, как ускорить запуск экземпляра и резервирование, если в директории PGDATA много файлов.

Читать далее

Жизненный цикл данных под контролем: знакомство с ILM на примере расширения для Postgres Pro Enterprise 17

Уровень сложностиПростой
Время на прочтение10 мин
Количество просмотров1K

Если данные в БД растут как на дрожжах, а вместе с ними и расходы на хранение, то пора познакомиться с концепцией управления жизненным циклом информации (ILM). Мы уже внедрили в Postgres Pro Enterprise 17 возможность для внедрения автоматического переноса редко используемых данных в более дешёвые хранилища. Подробности в статье.

Читать далее

Вклад авторов