Как надёжно стереть секретную информацию из базы данных

Зачем вообще "надёжно" стирать данные? Главное же, чтобы пользователь через интерфейс СУБД не мог их достать. Мало ли, что там за остатки данных в файлах болтаются, это же не проблема. Или нет?

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

Зачем вообще "надёжно" стирать данные? Главное же, чтобы пользователь через интерфейс СУБД не мог их достать. Мало ли, что там за остатки данных в файлах болтаются, это же не проблема. Или нет?

Меня зовут Сергей Гребенюк, я лидер разработки Sidec (Росреестр). Расскажу, как решили задачу объединения двух топиков с соотношением один ко многим и почему не устроило решение на Kafka-streams (kafka docs) и RocksDB (github). А также о том, как, опираясь на гарантии доставки exactly-once (EOS) (confluent docs), смогли снизить требования к ресурсам в несколько раз.
На иллюстрации показаны два подхода к объединению топиков: с persistent cache и in-memory cache. Мы перейдём от первой схемы ко второй.

Поддержка полей JSONB в СУБД PostgreSQL стала результатом большой работы команды PostgresPro и приблизила использование форматов и инструментов для работы с JSON в этой базе данных к статусу полноценной. В отличии от текстового в своей основе типа JSON, JSONB позволяет строить индексы по содержимому поля, что должно значительно ускорить поиск по таким данным. Также он реализует некоторые оптимизации, например не поддерживает дубликаты ключей в рамках одного уровня JSON-структуры, а если они все-таки встречаются, использует последнее значение.
В этой статье мы попробуем подключить и использовать функционал JSONB-полей в нашем java-приложении на фреймворке Jmix. Если вы используете Spring, решения по настройке и, может быть, даже использованию могут слегка отличаться, т. к. там используется ORM Hibernate.

Эта история начиналась с процесса валидации FK на очень больших таблицах (1TB+).
Далее я расскажу, какие нетривиальные проблемы встретились по пути, как я их решал, и каким образом можно исследовать довольно сложные проблемы производительности базы данных Postgres.

Работа над ошибками
PostgreSQL: Out-of-cycle release scheduled for November 21, 2024
Дело прошлое - уже вышла 17.2 со свитой из более почтенных версий, где всё поправили. Но история поучительная.
Итак: вышла новость, с восклицательным знаком, как обычно: PostgreSQL: PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 Released!
Ура! Прикрыли дыру CVE-2024-10976: в таблицах с безопасностью на уровне строк можно было подсмотреть или изменить те строки, в которые лезть не положено. После CVE-2023-2455 и CVE-2016-2193 многое поправили, но пропустили случаи подзапросов, запросов с WITH и другие. И всё это в версиях с 12 по 17. Ещё и закрыли уязвимость CVE-2024-10979. Но:
A change to ResultRelInfo - A Near Miss with with Postgres 17.1

Резервное копирование является важнейшей частью управления базами данных, гарантируя, что данные будут восстанавливаемы и защищены от неожиданных сбоев. Избитую фразу про две категории людей, которые не делают бэкапы и которые уже делают бэкапы, можно назвать грустной самоиронией, за которой стоят террабайты потерянных данных и сотни миллионов рублей списанных убытков.
В этой статье рассмотрим задачу управления резервным копированием для PostgeSQL с помощью популярного Open Source решения PG Back Web.

Всем привет. Меня зовут Сергей, я — эксперт компании Bercut. За плечами — более 20 лет работы с различными СУБД (PostgreSQL, Oracle, MS Access, MS FoxPro, Borland InterBase) и высоконагруженными системами на их основе.
В Bercut мы занимаемся разработкой и развитием IT‑продуктов, решений для операторов цифровых услуг и мобильных сервисов. Наши системы работают на различном железе, разных СУБД и обслуживают 24×7x365 в режиме онлайн сотни миллионов абонентов.
Сегодня поговорим о том, как оптимизировать хранение данных в PostgreSQL, снизив объем дискового пространства, потребляемого таблицами и ускорить выборку данных. Это может быть особенно актуально после перевода информационной системы с другой СУБД на PostgreSQL.
Это не лонгрид (как кажется с первого взгляда), а краткое практическое руководство.Есть навигация, можно сразу перейти на нужные пункты.

Сегодня поговорим о мощной штуке в PostgreSQL, которая одновременно помогает и открывает портал в ад: динамические SQL‑запросы. Динамика — это когда SQL собирается на лету, а не пишется заранее статичным текстом. Звучит неплохо, но при неправильном подходе легко превращается в катастрофу.

При работе со Spring Data JDBC и колонкой базы данных с типом `jsonb` вы можете столкнуться с трудностями при выборе правильного типа для свойства `jsonb` в entity, реализации конвертеров для преобразования объектов из/в базу данных и определении запросов Spring Data JDBC для вложенных свойств `jsonb`.

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

Продолжаем исследовать и настраивать память в PostgreSQL. Начало см. здесь.
Будет ешё итретья — заключительная часть, где я постараюсь максимально доступным языком рассказать уже методику выбора настроек. А пока предлагаю набраться терпения и ознакомиться со следующей порцией исследования по выбору настроек оперативной памяти PostgreSQL. Предупреждаю, будет не просто и, наверняка, не каждый доберется до конца.
В первой части были рассмотрены параметры shared_buffers, maintenance_work_mem, autovacuum_work_mem. А сегодня на повестке параметры temp_buffers и work_mem.

Транзакция — это набор операций с базой данных. В этот набор может входить как одна операция, так и несколько. Операции внутри транзакции либо выполняются все и полностью, либо ни одна операция не выполняется. Это свойство еще называют атомарностью. Транзакция переводит базу данных из одного согласованного состояния в другое. Согласованность означает что данные в базе данных подчиняются определенным правилам, которые были заложены при ее создании. К примеру, у нас есть две таблицы — Покупатели (Customer) и Покупки (Purchase).

Привет, Хабр! Меня зовут Игорь, и я один из разработчиков НОТА ЮНИОН. При подборе сотрудников (рекрутменте) есть много рутинных задач, отнимающих немало времени. Чтобы рекрутеры могли больше времени уделять, скажем так, творческой части своей работы, есть решение «Нота Юнион». Это набор инструментов для автоматизации подбора сотрудников. И в этом году мы перевели его базу данных с MariaDB на PostgreSQL. Задача оказалась масштабной, пришлось изрядно потрудиться. Хочу рассказать о том, почему мы решили поменять базу и как это реализовали. Возможно, вам это поможет сразу выбрать более подходящий под ваш продукт вариант.

Администраторам баз данных всегда хочется, чтобы их СУБД работали быстрее. Всегда кажется, что можно прооптимизировать определенные настройки, и запросы начнут отрабатывать быстрее.
Есть множество различных параметров и настроек, которые позволяют оптимизировать работу БД PostgreSQL. В этой статье мы не будем пытаться охватить их все и поговорим об оптимизации параметров операционной и файловой систем, а также памяти на самом сервере СУБД.
Я использую PostgreSQL 12-й версии! На остальных не проверял! Соответственно, он у вас должен быть скачан и настроен для использования.

Пользователи PostgreSQL нередко оперируют аналитическими запросами, при выполнении которых данные сортируются и группируются по разным правилам. За счёт оптимизации вычисления агрегатов и сортировок можно значительно сократить время и стоимость выполнения запросов. Об одной из таких оптимизаций — выборе порядка колонок в выражении GROUP BY — расскажем в этой статье.
Postgres уже умеет перестраивать список группируемых выражений в соответствии с порядком колонок из условия ORDER BY, чтобы исключить дополнительную сортировку и сэкономить вычислительные ресурсы. Мы пошли дальше, реализовали свою идею в дистрибутивах Postgres Pro Standard и Enterprise и вынесли патчи на обсуждение сообщества Postgres (первое и второе) в надежде, что они войдут в ближайшую версию ванильного PostgreSQL.


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

Если вы стоите перед выбором между PostgreSQL и Oracle DB, то эта статья для вас. Разберем где PostgreSQL побеждает Oracle. Будет код и примеры — всё, что нужно для практического сравнения.
P.S: эта статья не про то, какой PSQL хороший в отличии от Oracle, а про то, в чем PSQL по мнению автора лучше.

Pandas — это основная библиотека для работы с данными. Вот несколько приёмов, которые я использую, чтобы быстрее и проще выполнять повторяющиеся задачи по работе с данными.