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

Также часто слышал много историй про людей, которые приходили на собеседования с красными дипломами МГУ, но при этом абсолютно не разбирались в своей специальности, а потом на корпоративах признавались, что диплом у них купленный.

Но времена сейчас другие, сейчас 21 век, век больших возможностей, любой работодатель, который умеет пользоваться мышкой и знает, как выглядит браузер на рабочем столе, может проверить данные диплома. Каждый диплом, который выдаётся учебным заведением, теперь регистрируется в едином реестре, доступ к которому есть у каждого через сайт Федеральной службы по надзору в сфере образования и науки.

Внимание: не пытайтесь повторять действия, описанные в публикации и им подобные. Помните о ст. 272 УК РФ «Неправомерный доступ к компьютерной информации».

Всем привет! Прошедший год для пользователей и разработчиков Postgres был очень насыщенным. И 2018-й обещает быть не менее интересным и ярким. Под катом я расскажу об одном из первых громких событий для сообщества — PGConf.Russia 2018, и о том, чем запомнился прошедший год для DBA-команды Avito.

Мы разработали свою систему логирования на PostgreSQL… Да я знаю, что есть надстройки над ElasticSearch (GrayLog2, Logstash), и что есть другие похожие инструменты, и есть те, про которые не знаю. Тем не менее, наш инструмент на текущий момент построен на PostgreSQL, и он работает.

Во время рабочей недели со всех сервисов СБИС в облаке к нам поступает в сутки более 11 млрд записей, хранятся они 3 дня, общий объем занимаемого при этом места не превышает 32 Тб. Все это обрабатывает 8 серверов с PostgreSQL 9.6. Каждый сервер имеет 24 ядра, RAM 16Гб и 4 SSD диска по 1Тб.

В прошлых статьях мы рассмотрели механизм индексирования PostgreSQL, интерфейс методов доступа и следующие методы: хеш-индексы, B-деревья, GiST, SP-GiST, GIN и RUM. Тема этой статьи — BRIN-индексы.

BRIN

Общая идея

В отличие от индексов, с которыми мы уже познакомились, идея BRIN не в том, чтобы быстро найти нужные строки, а в том, чтобы избежать просмотра заведомо ненужных. Это всегда неточный индекс: он вообще не содержит TID-ов табличных строк.

Упрощенно говоря, BRIN хорошо работает для тех столбцов, значения в которых коррелируют с их физическим расположением в таблице. Иными словами, если запрос без предложения ORDER BY выдает значения столбца практически в порядке возрастания или убывания (и при этом по столбцу нет индексов).

Метод доступа создавался в рамках европейского проекта по сверхбольшим аналитическим базам данных Axle с прицелом на таблицы размером в единицы и десятки терабайт. Важное свойство BRIN, позволяющее создавать индексы на таких таблицах — небольшой размер и минимальные накладные расходы на поддержание.

Работает это следующим образом. Таблица разбивается на зоны (range) размером в несколько страниц (или блоков, что то же самое) — отсюда и название: Block Range Index, BRIN. Для каждой зоны в индексе сохраняется сводная информация о данных в этой зоне. Как правило, это минимальное и максимальное значения, но бывает и иначе, как мы увидим дальше. Если при выполнении запроса, содержащего условие на столбец, искомые значения не попадают в диапазон, то всю зону можно смело пропускать; если же попадают — все строки во всех блоках зоны придется просмотреть и выбрать среди них подходящие.

Не будет ошибкой рассматривать BRIN не как индекс в обычном понимании, а как ускоритель последовательного сканирования таблицы. Можно посмотреть на него и как на альтернативу секционированию, если каждую зону считать отдельной «виртуальной» секцией.
Теперь рассмотрим устройство индекса более подробно.

Очень скоро, а именно 5-7 февраля 2018 г. в Москве будет проводиться одна из основных мировых конференций по СУБД PostgreSQL — PGConf.Russia. В этой статье мы анонсируем основные доклады конференции, и расскажем об особенностях её проведения в этом году.

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

Релизы

• Вышел Postgres Pro Standard 10.1.1. В эту версию перенесены все ключевые доработки и новые возможности СУБД Postgres Pro Standard 9.6, исправлены некоторые найденные ошибки. Также вышла сборка PostgreSQL 10.1 под Windows
• Вышла версия PgBouncer 1.8.1. Исправлена ошибка в 1.8: добавлен недостающий файл, теперь PgBouncer без проблем собирается из тарбола.
• Появилась версия драйвера psqlODBC 10.01.0000. Некоторые поправки и усовершенствования по сравнению с версией 10.00.0000. Например, ликвидированы утечки памяти.

Статьи

• В статье Jsonb: few more stories about the performance
  Дмитрий Долгов (Zalando) обнародовал производительность PostgreSQL, MySQL и MongoDB на тестах YCSB. Сравнивалась производительность обработки бинарных JSON-ов (JSONB и BSON). Методика тестирования (в облаке) расписана подробно, есть выводы и рекомендации.
  До этого тема обсуждалась на PGConf.EU 2017 в Варшаве и на других конференциях. Например, в презентации Олега Бартунова по результатам YCSB-тестирования в Postgres Professional (слайд 81 и далее). В этих тестах на выделенных мощных серверах сравнивались только MongoDB и PostgreSQL, а акцент был сделан на высокую нагрузку (тысячи клиентов одновременно).

Предыстория

Для сбора и удобного просмотра данных о том, как работает PostgreSQL (общая производительность сервера, самые медленные запросы, самые частые запросы) мы долгое время использовали отличную утилиту POWA. Однако, это решение было далеко не идеальным и нам удалось найти более удачный вариант, к тому же полностью интегрированный с нашей основной системой мониторинга.

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

Вот уже два года как одна из лучших распределённых аналитических СУБД enterprise-уровня вышла в open source. Что изменилось за это время? Что дало открытие исходников проекту? Как дальше будет развиваться Greenplum?

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

Привет! DataGrip замыкает цепочку релизов наших IDE, хотя вы уже могли попробовать то, о чём я расскажу, в других продуктах: поддержка баз данных есть во всех наших IDE, кроме WebStorm (потому что он дешевле), CLion и AppCode (потому что не просят).

13 ноября на площадке Райффайзенбанка, прошел очередной PostgreSQL MeetUp. О том, как это было, что обсуждали и какие вопросы были самыми интересными, читайте под катом.

Мы уже рассмотрели механизм индексирования PostgreSQL, интерфейс методов доступа и все основные методы доступа, как то: хеш-индексы, B-деревья, GiST, SP-GiST и GIN. А в этой части посмотрим на превращение джина в ром.

RUM

Хоть авторы и утверждают, что джин — могущественный дух, но тема напитков все-таки победила: GIN следующего поколения назвали RUM.

Этот метод доступа развивает идею, заложенную в GIN, и позволяет выполнять полнотекстовый поиск еще быстрее. Это единственный метод в этой серии статей, который не входит в стандартную поставку PostgreSQL и является сторонним расширением. Есть несколько вариантов его установки:

• Взять пакет yum или apt из репозитория PGDG. Например, если вы ставили PostgreSQL из пакета postgresql-10, то поставьте еще postgresql-10-rum.
• Самостоятельно собрать и установить из исходных кодов на github (инструкция там же).
• Пользоваться в составе Postgres Pro Enterprise (или хотя бы читать оттуда документацию).

Ограничения GIN

Какие ограничения индекса GIN позволяет преодолеть RUM?

Во-первых, тип данных tsvector, помимо самих лексем, содержит информацию об их позициях внутри документа. В GIN-индексе, как мы видели в прошлый раз, эта информация не сохраняются. Из-за этого операции фразового поиска, появившиеся в версии 9.6, обслуживается GIN-индексом неэффективно и вынуждены обращаться к исходным данным для перепроверки.

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

Метод доступа RUM в первом приближении можно рассматривать как GIN, в который добавлена позиционная информация, и который поддерживает выдачу результата в нужном порядке (аналогично тому, как GiST умеет выдавать ближайших соседей). Пойдем по порядку.

Введение

На очередном собеседовании меня спросили о недостатках модели данных EAV (Entity Attribute Value), я не нашёл что сказать, на мой взгляд это идеальный способ хранения произвольных данных. После короткого раздумья, я сказал что единственная проблема это невозможность построить индексы для выборок.

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

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

Сегодняшняя статья несколько необычна. Как минимум по той причине, что вместо анализа одного проекта, будем искать ошибки сразу в трёх, а также посмотрим, где найдутся наиболее интересные баги. А самое интересное — мы выясним, кто молодец и пишет самый качественный код. Итак, на повестке дня — разбор ошибок в коде проектов Firebird, MySQL и PostgreSQL.

На Higload++ 2017 года в Сколково наша компания Postgres Professional снова провела викторину с традиционной раздачей ништяков, в качестве которых выступили билеты на февральский PgConf.Russia 2018.

В этой статье разбираются вопросы викторины.

Сотни баз данных и тысячи хранимых процедур. Как это всё писать, тестировать и деплоить на множество серверов с возможностью быстрого отката в условиях хайлоад 24х7 и не умереть? Интересно? Добро пожаловать под кат!

В DataGrip, как и в других наших IDE с поддержкой баз данных, есть механизм экспорта данных. Пользователь выбирает формат экспорта из предложенных или создает его сам.

В понедельник, 13 ноября приглашаем вас в офис Райффайзенбанка, где пройдет очередной PostgreSQL MeetUp. Мероприятие организовано совместно с компанией Postgres Professional.

Мы долго думали, как назвать наше событие, и решили дать ему романтичное название «Осенний Postgres», хотя, скорее всего, осени будет мало и, может, выпадет снег.

Мы уже познакомились с механизмом индексирования PostgreSQL и с интерфейсом методов доступа, и рассмотрели хеш-индексы, B-деревья, индексы GiST и SP-GiST. А в этой части займемся индексом GIN.

GIN

— Джин?.. Джин — это, кажется, такой американский спиртной напиток?..
— Не напиток я, о пытливый отрок! — снова вспылил старичок, снова спохватился и снова взял себя в руки. — Не напиток я, а могущественный и неустрашимый дух, и нет в мире такого волшебства, которое было бы мне не по силам.

Лазарь Лагин, «Старик Хоттабыч».

Gin stands for Generalized Inverted Index and should be considered as a genie, not a drink.

README

Общая идея

GIN расшифровывается как Generalized Inverted Index — это так называемый обратный индекс. Он работает с типами данных, значения которых не являются атомарными, а состоят из элементов. При этом индексируются не сами значения, а отдельные элементы; каждый элемент ссылается на те значения, в которых он встречается.

Хорошая аналогия для этого метода — алфавитный указатель в конце книги, где для каждого термина приведен список страниц, где этот термин упоминается. Как и указатель в книге, индексный метод должен обеспечивать быстрый поиск проиндексированных элементов. Для этого они хранятся в виде уже знакомого нам B-дерева (для него используется другая, более простая, реализация, но в данном случае это несущественно). К каждому элементу привязан упорядоченный набор ссылок на строки таблицы, содержащие значения с этим элементом. Упорядоченность не принципиальна для выборки данных (порядок сортировки TID-ов не несет в себе особого смысла), но важна с точки зрения внутреннего устройства индекса.

Администраторы баз данных и разработчики часто сталкиваются с ситуациями, когда необходимо данные из разных баз сравнивать и синхронизировать, либо просто перенести их в другую рабочую базу. В этом случае очень важно выбрать правильный инструмент, который поможет справиться с этой задачей быстро и эффективно. Для PostgreSQL на рынке существует несколько готовых инструментов, которые позволяют находить различия и выполнять синхронизацию данных. В этой статье проведем небольшой обзор особенностей этих инструментов, а именно продукты таких компаний как Devart, SQL Maestro Group, Navicat и Altova.