Любите ли вы разрабатывать базы данных? Нет, не новомодные NoSQL, а старые добрые реляционные, где вы можете описывать отношения и хранимые процедуры для доступа к данным и логики. Может быть, вы разрабатываете базы данных для PostgreSQL? Если да, то отлично — этот пост определенно для вас.

Друзья, на прошедшей в прошлом году конференции PG Day'15 Russia один из наших докладчиков, Joseph Conway, представил интересный материал об использовании созданного и поддерживаемого им уже больше десяти лет расширения PL/R, которое позволяет использовать язык для статистического анализа R внутри всеми любимой базы данных. Хочу предложить вашему вниманию follow-up статью, созданную на основе материалов, представленных в докладе Joe. Задача данной публикации — обзорно познакомить вас с возможностями языка PL/R. Надеюсь, что вы найдете представленную здесь информацию полезной для себя.



Последние тенденции в области Big Data поощряют сближение аналитики и данных, в то время как PL/R ненавязчиво предоставляет такой сервис вот уже 12 лет! Если вдруг вы не в курсе, PL/R – это расширение для PostgreSQL, позволяющее использовать R, язык для математических расчетов, прямо из PostgreSQL для того, чтобы легко и просто получать развернутую аналитику. Расширение доступно и активно совершенствуется с 2003 года. Оно работает со всеми поддерживаемыми версиями PostgreSQL и со всеми свежими версиями R. Тысячи людей во всем мире уже оценили его удобство и эффективность. Давайте же разберемся, что такое PL/R, обсудим достоинства и недостатки такого подхода к анализу данных и рассмотрим несколько примеров для наглядности.

Обработка запросов SQL и  в Оракле, и в Постгресе имеет много общего. Так или иначе, надо выполнить синтаксический разбор, проверить семантику (для чего потребуется метаинформация, и не важно, называется ли это «словарь данных» или «системный каталог»), выполнить какие-то преобразования, построить оптимальный план выполнения (в обеих системах основанный на стоимости, а следовательно требующий заранее собранной статистики).

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

В статье мы попытаемся проследить, как из-за разницы в одном архитектурном решении логически следует совершенно разная идеология работы в запросами в двух СУБД.

Приведенные примеры (которые выполнялись на версиях Oracle 11.2 XE и PostgreSQL 9.4) содержат время выполнения запросов. Нас интересуют только относительные величины: во сколько раз изменилось время выполнения после внесения в запрос тех или иных изменений. При этом абсолютные цифры могут отличаться на порядки в зависимости от аппаратуры, нагрузки и настроек. Чтобы не давать повод для бессмысленных выводов на их основании, все абсолютные значения в статье отмасштабированы так, чтобы один из запросов составлял в обеих системах 10 секунд.

В предыдущих статьях я писал о получении параллельного sequential scan закоммиченного в PostgreSQL 9.5. Но этого не случилось. Однако, я с удовольствием расскажу вам о первом коммите parallel sequential scan в PostgreSQL в master ветку с целью предстоящего релиза PostgreSQL 9.6.

Параллельные запросы для PostgreSQL были долгое время моей мечтой, над которыми я работал несколько лет. Их разработка их началась c PostgreSQL 9.4 релизном цикле, где я добавил динамические воркеры, работающие в фоне и динамическую shared memory, разработка которой продолжилась в PostgreSQL 9.5, где имела место идея в добавлении фундаментальной инфраструктуры для параллелизма которая сегодня была закоммиченна. Я хотел бы рассказать вам немного о сегодняшних коммитах и о работе, которая будет проделана дальше.

Сегодня PostgreSQL Global Development Group объявила о выходе PostgreSQL 9.5. Среди прочих нововведений можно отметить функцию UPSERT, безопасность на уровне строк (Row Level Security, RLS) и несколько функций работы с Big Data. По мнению разработчиков, новые функции делают PostgreSQL лучшим вариантом среди всех возможных для стартапов, больших корпораций, правительственных организаций.

Более подробно о новых функциях — под катом.

As such, there’s really no “standard” benchmark that will inform you about the best technology to use for your application. Only your requirements, your data, and your infrastructure can tell you what you need to know.

Для начала немного философии. NoSql окружает и от этого никуда не убежать (хотя не очень то и хотелось). Оставим вопросы о глубинных причинах за рамками данного текста, отметим лишь, что этот тренд отражается не только в появлении новых NoSql решений и развитии старых. Еще одна грань — смешение противоположностей, а именно поддержка хранения schema-less данных в традиционных реляционных базах. В этой серой области на стыке реляционной модели хранения данных и всего остального кроется головокружительное количество возможностей. Но, как и всегда, нужно уметь найти баланс, который подходит именно для ваших данных. Это бывает трудно, в первую очередь из-за того, что приходится сравнивать мало сравнимые вещи, например, производительность NoSql решения с традиционной базой данных. В этой небольшой заметке будет предложена такая попытка и приведено сравнение производительности работы с jsonb в PostgreSQL с json в Mysql и с bson в Mongodb.

На работе в рамках проектирования новой системы интеграции устройств для мониторинга аудио/видео потоков возникла задача отслеживания, накопления и последующего анализа изменений их состояния. Состояние выдаётся через зоопарк динамических XML-документов, используемых, в основном, для наполнения legacy web-UI.

Для упрощения интеграции мною была предложена идея создания обобщённой библиотеки для сохранения структурированных diff-ов для (почти) произвольного XML. Поскольку эти diff-ы будут сохраняться с учётом структуры документа, это дало бы возможность очень экономно аккумулировать изменения состояния устройств, а также в будущем генерировать отчёты с аналитикой, диаграммами, и т.п. После недели запойного программирования я набросал работающий proof-of-concept, которым и хочу поделиться в данной статье.

Функцией партиционирования таблиц в PostgreSQL, к сожалению, активно пользуются пока не многие. На мой взгляд, очень достойно о ней рассказывает в своей работе Hubert Lubaczewski (depesz.com). Предлагаю вам еще один перевод его статьи!

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

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

Привет всем!

Сегодня я рада анонсировать курс “Hacking PostgreSQL” из 16 занятий, на которых мы вместе будем исследовать особенности архитектуры открытой СУБД и вносить изменения на уровне исходного кода. Курс будет проходить в Москве, на площадке компании Postgres Professional. Начало курса запланировано на февраль 2016 года. Лекции начнутся сразу после февральской конференции pgconf.ru и будут проходить один раз в неделю вечером. Видеозаписи и материалы лекций мы будем выкладывать по мере обработки.

Курс собран из личного опыта разработчиков нашей компании, материалов с конференций, статей и вдумчивого чтения документации и исходников. В первую очередь он адресован начинающим разработчикам ядра PostgreSQL. Но он будет интересен и DBA, которым иногда приходится влезать в код, и просто всем неравнодушным к архитектуре большой системы, желающим узнать “А как это работает на самом деле?”

Привет! Мы выпустили IDE для работы с базами данных.

Полтора года мы делали 0xDBE по программе раннего доступа (EAP). Пора подвести черту под нашей работой. Мы благодарим всех, кто пробовал 0xDBE на своих проектах и писал нам — вы очень помогли. По этому названию мы тоже будем скучать.

Теперь IDE называется DataGrip.



Поддерживаемые СУБД

DataGrip это универсальная IDE для работы с MySQL, PostgreSQL, Oracle, SQL Server, Sybase, DB2, SQLite, HyperSQL, Apache Derby и H2.

Работа с объектами БД и генерация кода

DataGrip предоставляет инструменты для работы с объектами базы данных. Если вы создаёте или изменяете таблицу, добавляете или изменяете колонку, индекс, ключ в уже существующей, используйте графический интерфейс. Подобные изменения сопровождаются генерацией соответствующего скрипта — вы можете сразу выполнить сделанные изменения в базе или скопировать сгенерированный DDL-запрос в редактор и работать уже непосредственно с кодом.

Машинное обучение занимается поиском скрытых закономерностей в данных. Растущий рост интереса к этой теме в ИТ-сообществе связан с исключительными результатами, получаемыми благодаря ему. Распознавание речи и отсканированных документов, поисковые машины — всё это создано с использованием машинного обучения. В этой статье я расскажу о текущем проекте нашей компании: как применить методы машинного обучения для увеличения производительности СУБД.
В первой части этой статьи разбирается существующий механизм планировщика PostgreSQL, во второй части рассказывается о возможностях его улучшения с применением машинного обучения.

Тема работы с временными метками в PostgreSQL плохо раскрыта в русскоязычных профильных публикациях в Интернете и служит частым источником проблем в работе программистов. Предлагаю вашему вниманию перевод материала от Hubert Lubaczewski, автора популярного зарубежного блога depesz.com. Надеюсь, статья будет для вас полезна!



Время от времени в IRC или в почтовых рассылках кто-нибудь задает вопросы, которые показывают глубокое непонимание (или недостаток понимания) меток времени, особенно тех, которые учитывают часовые пояса. Так как я уже сталкивался с этим ранее, позвольте мне рассказать, что такое timestamps, как с ними работать и с какими наиболее распространенными загвоздками вы можете столкнуться.

В PostgreSQL 9.5 появится декларативная безопасность строк. Вы можете задать правила для таблиц и сделать их выполнение автоматическим, к примеру, позволяя пользователю joe видеть только строки, у которых в поле owner стоит значение joe.

Это отличный инструмент и он уже давно должен был появиться. Этого не было сделано в PostgreSQL 9.4, зато было сделано с помощью автоматически обновляемых представлений security_barrier. Они и функции LEAKPROOF формируют фундамент, на котором и построена безопасность строк. Вы можете использовать эти составляющие части без поддержки декларативной политики для достижения безопасности строк в 9.4.

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

Вы могли заметить, что в PostgreSQL 9.2 была добавлена поддержка для security_barrier представлений. Я смотрел в этот код с прицелом на добавление поддержки автоматического обновления для них, как части развивающейся работы по защите на уровне строк для проекта AXLE, и я подумал что попробую объяснить как они работают.

Роберт уже объяснил в чем польза таких представлений и от чего они защищают (кроме того, это еще обсуждалось в "Что нового в PostgreSQL 9.2"). Сейчас же я хотел бы перейти к тому, как они работают и обсудить как security_barrier представления взаимодействуют с автоматически обновляемыми представлениями.

В целом, системы управления реляционными базами данных были задуманы как «один-размер-подходит-всем решение для хранения и получения данных» на протяжении десятилетий. Но растущая необходимость в масштабируемости и новые требования приложений создали новые проблемы для традиционных систем управления РСУБД, включая некоторую неудовлетворенность подходом «один-размер-подходит-всем» в ряде масштабируемых приложений.

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

Хранение документов в Postgres немного проще, теперь у нас есть серьезные процедуры сохранения, возможность запускать полнотекстовый поиск, и некоторые простые процедуры поиска и фильтрации.

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

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

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

Давайте сделаем это.

Всем привет!

В этот раз я расскажу не про использование Python или очередной трюк с CSS/HTML и, увы, не про то, как я 5 лет портировал Вангеры, а про один важный аспект написания расширений для замечательной СУБД PostgresSQL.

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

К таблицам из Си можно получить доступ через хорошо описанный но медленный SPI (Server Programming Interface), также есть очень сложный способ, через буферы, а я расскажу про компромиссный вариант. Под катом я постарался дать примеры кода с подробными пояснениями.

Данная статья является переводом, оригинальная статья находится вот здесь, автор Rob Conery.

Postgres, как многие знают, поддерживает JSON как тип хранения данных, а с выходом 9.4, Postgres теперь поддерживает хранение JSON в виде jsonb — бинарного формата.

Это прекрасные новости для тех, кто хочет шагнуть дальше простого «хранения JSON как текста». jsonb теперь поддерживает индексирование с использованием GIN индекса, а также имеет специальный оператор запросов, который позволяет получить преимущества GIN индекса.