17 июня в Москве, Измайлово пройдет конференция Devconf::Storage

Базы данных становятся все чудесатее и чудесатее. Традиционные RDBMS становятся NoSQL, а новые движки становятся кластерными, распределенными и колоночными.

Олег Бартунов, известный разработчик Postgres, хочет рассказать чем их база лучше MongoDB при работе с JSON, а его коллега Иван Панченко — о том, как писать для постгреса на perl, python и javascript.
Антон Околелов расскажет как перейти с MySQL, чтобы ощутить мощь Postgres, а другой докладчик, Алексей Копытов расскажет почему Uber сделал точно наоборот, и ушел с Postgres на MySQL.

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

На одном из прошлых PG Day Валентин Гогичашвили, возглавляющий департамент Data Engineering в Zalando, рассказал, как PostgreSQL используется в компании с большим штатом разработчиков, высокой динамичностью процессов, и как они пришли к такому выбору.

Не секрет, что Zalando является постоянным гостем PG Day. На PG Day'17 Russia мы представим вам три замечательных доклада от немецких коллег. Мурат Кабилов и Алексей Клюкин расскажут про внутреннюю разработку Zalando для развертывания высокодоступных кластеров PostgreSQL. Александр Кукушкин поведает о практике эксплуатации PostgreSQL в AWS. Дмитрий Долгов поможет разобраться c внутренностями и производительности типа данных JSONB в контексте эксплуатации PostgreSQL как документо-ориентированного хранилища.

Всем жаждущим знаний предлагаем ознакомиться с новыми лекциями Технопарка, посвящённым базам данных. Курс ведёт Артём Навроцкий, ведущий программист в Allods Team.

Список лекций:

1. Введение
2. Модификация и выборка данных
3. Выборка данных (продолжение)
4. Транзакции. Триггеры и хранимые процедуры
5. Индексы и производительность
6. Оптимизация запросов. Оптимизация структуры данных
7. Репликация, полнотекстовый поиск, JSON
8. Сохранность данных

Только что натолкнулся на возможность Postgresql, показавшуюся мне забавной. Для кого "баян" — респект вам, я несколько лет работаю с Postgres и до сих пор не натыкался на такую штуку.

select; без указания полей, таблицы и условий возвращает одну строку. Но у этой строки нет полей:

=> select;
--
(1 row)

Для сравнения:

=> select null;
 ?column? 
----------

(1 row)
=> select null where 0=1;
 ?column? 
----------
(0 rows)

А сможем ли мы создать таблицу из такого "пустого" запроса? Таблицу без полей.

Друзья, мы продолжаем публиковать транскрипции наиболее интересных технических докладов прошлых конференций PG Day Russia. Сегодня вашему вниманию предлагается доклад Алексея Ермакова, специалиста компании Data Egret, посвященный устройству и функционированию планировщика.



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

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

В докладе будет показано, каким образом статистическая информация собирается, для чего она важна, и как ее правильно читать и использовать; какие параметры можно «подкрутить» в тех или иных случаях, как подобрать оптимальный индекс и как переписать запрос, чтобы исправить ошибки планировщика.

В первой статье мы рассмотрели механизм индексирования PostgreSQL, во второй — интерфейс методов доступа, и теперь готовы к разговору о конкретных типах индексов. Начнем с хеш-индекса.

Hash

Устройство

Общая теория

Многие современные языки программирования включают хеш-таблицы в качестве базового типа данных. Внешне это выглядит, как обычный массив, но в качестве индекса используется не целое число, а любой тип данных (например, строка). Хеш-индекс в PostgreSQL устроен похожим образом. Как это работает?

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

Идея хеширования состоит в том, чтобы значению любого типа данных сопоставить некоторое небольшое число (от 0 до N−1, всего N значений). Такое сопоставление называют хеш-функцией. Полученное число можно использовать как индекс обычного массива, куда и складывать ссылки на строки таблицы (TID). Элементы такого массива называют корзинами хеш-таблицы — в одной корзине могут лежать несколько TID-ов, если одно и то же проиндексированное значение встречается в разных строках.

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

Илья Космодемьянский ( hydrobiont )

Есть типичные ошибки работы с хранилищем, и эти ошибки, не то чтобы я их выдумываю специально, но поскольку мы много работаем с удаленной поддержкой баз данных, мы их просто коллекционируем. Зачастую одни и те же от клиентов. И составляем своеобразный рейтинг того, что наколлекционировали. Об этих вещах я и буду сегодня рассказывать.

Добрый день, уважаемые читатели.

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

Друзья, вновь пришло время авторской колонки корпоративного блога PG Day’17. Предлагаем вашему вниманию сравнительный анализ работы с PostgreSQL из популярных ORM от varanio.

ORM (Object-Relational Mapping), по идее, должен избавить нас от написания SQL запросов и, в идеале, вообще абстрагировать от базы данных (от способа хранения данных), чтобы мы могли работать с классами, в той или иной степени выражающими объекты бизнес-логики, не задаваясь вопросом, в каких таблицах всё это по факту лежит.

Посмотрим, насколько это удается современным библиотекам на PHP. Давайте рассмотрим несколько типичных кейсов и сравним ORM с голым SQL, написанным вручную.

Дорогие коллеги, рады предложить вашему вниманию второй выпуск нашей новой рубрики «интервью с разработчиками баз данных». Мы поговорили с Иваном Фролковым, разработчиком компании Postgres Professional. Иван занимается прикладной разработкой для баз данных уже свыше 20 лет. Сегодня, Иван приокроет завесу тайны и поведает про новые интересные возможности «отечественного Посгреса», Postgres Pro: EE.



PG Day: Расскажи немного, пожалуйста, как давно ты занимаешься базами данных и вообще в профессии состоишь, в каких амплуа и так далее.

Интерфейс

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

Свойства

Все свойства методов доступа представлены в таблице pg_am (am — access method). Из этой таблицы можно получить и сам список доступных методов:

postgres=# select amname from pg_am;
 amname
--------
 btree
 hash
 gist
 gin
 spgist
 brin
(6 rows)

Хотя к методам доступа можно с полным правом отнести и последовательное сканирование, исторически сложилось так, что оно отсутствует в этом списке.

В версиях PostgreSQL 9.5 и более старых каждое свойство было представлено отдельным полем таблицы pg_am. Начиная с версии 9.6 свойства опрашиваются специальными функциями и разделены на несколько уровней:

• свойства метода доступа — pg_indexam_has_property,
• свойства конкретного индекса — pg_index_has_property,
• свойства отдельных столбцов индекса — pg_index_column_has_property.

Разделение на уровни метода доступа и индекса сделано с прицелом на будущее: в настоящее время все индексы, созданные на основе одного метода доступа, всегда будут иметь одинаковые свойства.

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

Немного вводной. Чтобы Bucardo заработал, мы должы:

1) Сказать ему какие базы-участники на каких серверах вообще существуют.

2) Сказать ему какие таблицы участвуют в репликации.

Внимание: если разработчики добавят в приложение новую таблицу, мы должны об этом сообщить bucardo. То же самое касается изменения схемы существующих таблиц.

3) Сказать ему какие группы таблиц существуют и какие таблицы попадают в какие группы. Группы нужны на тот случай, если между разными серверами надо реплицировать разные таблицы. Удобнее работать с группой, чем каждую отдельно указывать (очень похоже на группы в Nagios).

4) Сказать ему какие группы баз данных существуют. Цель — та же, что и для таблиц.

В контексте статьи картинка обретает двойной смысл.

Дисклеймер

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

И так получилось, что при выборе инструмента планирования такого питания взор пал на PostgreSQL, который стоит на домашнем сервере. Аналогично можно легко сделать и в Excel или Гугл-таблицах, но в нашем случае SQL оказался более быстрым + есть открытые базы с готовыми данными. Данная статья может рассматриваться вами как "заготовка" для аналогичного SQL сервиса или просто как идея, которую вы можете взять и применить для себя.
Также обратите внимание — чтобы пользоваться этим в полной мере, вы должны хотя бы чуточку уметь в табличные процессоры (Excel).

Буквально месяц назад в Яндекс.Деньгах завершился переезд сервиса профилей пользователей с Oracle на PostgreSQL. Так что теперь у нас есть опробованное решение по миграции больших объемов данных без потерь и остановки использующего их сервиса.

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

В работе с любым инструментом важно легко находить то, что нужно. В DataGrip ищут:

— Объекты базы данных: таблицы, представления, функции, колонки и т. д.
— Сами данные.
— Код, например кусок кода в скрипте или исходнике объекта.
— Другое: настройки, действия, файлы.

Разберемся, как не потеряться в IDE и своих базах данных.

PG Day’17 продолжает радовать вас авторскими статьями. Сегодня, наш старый друг и бессменный автор провокационных статей о Web-разработке varanio расскажет о логической репликации.

Сначала я хотел назвать статью "Гарри Поттер и философский камень", потому что много лет при сравнении PostgreSQL с MySQL кто-нибудь всегда появлялся и замечал, что в Посгресе нет логической репликации (можно реплицировать только всю базу целиком, причем реплика read only), а в MySQL их целых два вида: statement based и row based.

И если statement based — это бомба замедленного действия с лазерным прицелом в ногу, то row based действительно очень не хватало в PG. Т.е. вопрос репликации — как философский камень у любителей баз.

Точнее, в посгресе всегда можно было использовать slony для того, чтобы, например, реплицировать только одну-две нужных таблицы. Но slony — это хитрое поделие на триггерах, которое работает по принципу: работает — не трогай. Т.е. например, нельзя просто взять и сделать ALTER TABLE ADD COLUMN, это надо делать через специальные механизмы. Если же всё-таки кто-то случайно это сделал, а потом, что еще хуже, через какое-то время в панике вернул как было, то быстро разрулить эту ситуацию может только чёрный маг 80lvl. Помимо slony, начиная с 9.4 стало возможно писать свои расширения для логической репликации через wal, вроде бы, пример такого расширения — pglogical.

Но это всё не то!

Когда я узнал, что в dev-ветку PostgreSQL 10 упал коммит, который позволяет из коробки, без экстеншенов и плагинов, логически реплицировать отдельные таблицы, я решил посмотреть, а как оно там работает.

Предисловие

В этой серии статей речь пойдет об индексах в PostgreSQL.

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

За скобками обсуждения останутся вопросы разработки новых типов индексов. Это требует знания языка Си и относится скорее к компетенции системного программиста, а не прикладного разработчика. По этой же причине мы практически не будем рассматривать программные интерфейсы, а остановимся только на том, что имеет значение для использования уже готовых к употреблению индексов.

В этой части мы поговорим про разделение сфер ответственности между общим механизмом индексирования, относящимся к ядру СУБД, и отдельными методами индексного доступа, которые в PostgreSQL можно добавлять как расширения. В следующей части мы рассмотрим интерфейс метода доступа и такие важные понятия, как классы и семейства операторов. После такого длинного, но необходимого введения мы подробно рассмотрим устройство и применение различных типов индексов: Hash, B-tree, GiST, SP-GiST, GIN и RUM, BRIN и Bloom.

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

Было когда-то время, когда ORM Django считалась очень милой, но абсолютно глупой. Хотя, возможность производить Annotate и Aggregate были в ней с незапамятных времён. А в версии 1.8 добавилась возможность применять функции базы данных внутри Query Expressions. И, разумеется, если начинающий джангист не испугался и дочитал вступление до этих строк, он может смело читать дальше: статья ориентирована именно на начинающих.

Некоторое время назад передо мной встала задача: выбрать из таблицы значения по пользователям. Причём, эти значения должны соответствовать определённому регулярному выражению. Но и это не конец условия: из выбранных выражений нужно вытащить substring. Опять же, по регулярке. Сделал я это довольно быстро, и захотелось поделиться опытом с тем, кто ещё не может применять Annotate и Query Expressions на практике