В конце марта 2019 года американская компания Trustwave, занимающаяся кибербезопасностью и сервисами по защите от угроз, опубликовала сообщение об уязвимости в СУБД PostgreSQL, которая присутствует во всех версиях, начиная с версии PostgreSQL 9.3 по версию 11.2. Эта уязвимость была зарегистрирована в базе данных уязвимостей информационной безопасности CVE (Common Vulnerabilities and Exposures ) под номером CVE-2019-9193. Это сообщение вызвало большой переполох, так как по системе оценок уязвимостей CVSS (Common Vulnerability Scoring System) данная уязвимость получила рейтинг 9.0 по 10-балльной шкале.

Что такое снимок данных

Так получилось, что я провожу довольно много собеседований на должность веб-программиста. Один из обязательных вопросов, который я задаю — это чем отличается INNER JOIN от LEFT JOIN.

Чаще всего ответ примерно такой: "inner join — это как бы пересечение множеств, т.е. остается только то, что есть в обеих таблицах, а left join — это когда левая таблица остается без изменений, а от правой добавляется пересечение множеств. Для всех остальных строк добавляется null". Еще, бывает, рисуют пересекающиеся круги.

Я так устал от этих ответов с пересечениями множеств и кругов, что даже перестал поправлять людей.

Дело в том, что этот ответ в общем случае неверен. Ну или, как минимум, не точен.

Новости

Уязвима ли «уязвимость»

Цель статьи — на примере библиотеки schema-keeper показать инструменты для упрощения разработки баз данных в PHP-проектах, использующих СУБД PostgreSQL.

Будут рассмотрены следующие вопросы:

1. В каком виде хранить дамп структуры БД в системе контроля версий (далее по тексту — VCS)
2. Как отслеживать изменения в структуре БД после сохранения дампа
3. Как переносить изменения в структуре БД на другие окружения без конфликтов и гигантских файлов миграций
4. Как наладить процесс параллельной работы над проектом нескольких разработчиков
5. Как безопасно деплоить большее количество изменений в структуре БД на production-окружение

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

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

Заголовок

Отношения (relations)

Всем привет! Меня зовут Денис Гирько, я системный архитектор e-commerce платформы в Lamoda. В прошлом году я выступал на конференции DevConf с докладом, которым хочу поделиться с вами.

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

О чем пойдет речь? Расскажу:

• о процессе доставки и обозначу проблемы;
• как эффективно хранить территории доставки в базе;
• как повысить качество тех данных, которые мы получаем от клиента;
• как в адресной базе искать адресата, чтобы найти больше точных результатов.

1. Изоляция, как ее понимают стандарт и PostgreSQL (эта статья);
2. Слои, файлы, страницы — что творится на физическом уровне;
3. Версии строк, виртуальные и вложенные транзакции;
4. Снимки данных и видимость версий строк, горизонт событий;
5. Внутристраничная очистка и HOT-обновления;
6. Обычная очистка (vacuum);
7. Автоматическая очистка (autovacuum);
8. Переполнение счетчика транзакций и заморозка.

В прошлой статье мы оптимизировали поиск в PostgreSQL стандартными средствами. В этой статье мы продолжим оптимизацию с помощью индекса RUM и проанализируем его плюсы и минусы в сравнении с GIN.

UPD. Часть 2

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