С тех пор как PostgreSQL начал поддерживать NoSQL (посредством HStore, JSON и JSONB), вопрос о том, когда использовать PostgreSQL в реляционном режиме, а в каких в режиме NoSQL, стал подниматься достаточно часто. Получится ли у вас полностью отказаться от традиционных структур таблиц и работать с представлениями документов в будущем? Смешивать ли оба подхода? Ответ на этот вопрос не удивителен — все зависит от многих факторов. Каждая новая модель хранения данных включая Hstore, JSON и JSONB имеет свои идеальные варианты применения. Тут мы копнём глубже и узнаем об особенностях каждой из них и посмотрим когда что использовать

«Развитие ветки PHP-7», Дмитрий Стогов, Zend Technologies

• prepared statements
• scrollable cursors
• partial iteration результатов запроса
• автоматического кодирования и декодирования составных типов, массивов и их сочетания
• интуитивно понятной поддержки пользовательских типов

В процессе развития проекта периодически появляется необходимость обмена данными между серверами баз данных. Предположим, у нас есть источник данных в виде SQL Server и удалённый PostgreSQL сервер, на котором эти данные должны оказаться. После добавления удалённого сервера в качестве linked server, можно делать запросы вида:

INSERT INTO RemotePG...RemoteTable (RecordID, RecordName) VALUES (1,'Test string');

Проблема в том, что такие запросы выполняются очень долго. Если перед нами стоит задача выгрузить десятки и сотни тысяч записей, то время на выполнение стремится к бесконечности. Рассмотрим два с половиной способа вставить данные в таблицу на linked server и сравним время выполнения.

Надо “SELECT * WHERE a=b FROM c” или “SELECT WHERE a=b FROM c ON *” ?

Если вы похожи на меня, то согласитесь: SQL — это одна из тех штук, которые на первый взгляд кажутся легкими (читается как будто по-английски!), но почему-то приходится гуглить каждый простой запрос, чтобы найти правильный синтаксис.

А потом начинаются джойны, агрегирование, подзапросы, и получается совсем белиберда. Вроде такой:

SELECT members.firstname || ' ' || members.lastname
AS "Full Name"
FROM borrowings
INNER JOIN members
ON members.memberid=borrowings.memberid
INNER JOIN books
ON books.bookid=borrowings.bookid
WHERE borrowings.bookid IN (SELECT bookid
  FROM books
  WHERE stock>(SELECT avg(stock)
    FROM books))
GROUP BY members.firstname, members.lastname;

Буэ! Такое спугнет любого новичка, или даже разработчика среднего уровня, если он видит SQL впервые. Но не все так плохо.

Легко запомнить то, что интуитивно понятно, и с помощью этого руководства я надеюсь снизить порог входа в SQL для новичков, а уже опытным предложить по-новому взглянуть на SQL.

В какой-то момент разработки проекта встал вопрос поиска по большому количеству текстов. Причем, тексты имеют различную длину: от твиттов до больших статей. Сначала, основным поисковым движком был выбран встроенный в Postgres _tsvector. Для поиска по простым правилам его было вполне достаточно. Массив текстов рос с большой скоростью, а правила поиска усложнялись, поэтому встроенный движок уже не покрывал требований.

Да, существует sphinx, у него есть отличная интеграция с Postgres, но была цель найти решение для использования elasticsearch с Postgres. Почему? elasticsearch показывал хорошие результаты в некоторых case-ах проекта. Да и уже был сервер с ним для хранения логов logstash-а. Также было желание найти такой инструмент, который полностью возьмет на себя синхронизацию данных.

В результате всего на просторах сети был найден проект ZomboDb, который как раз подходил под требования.

Расширение pg_variables

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

Решение обычно выглядит вполне прямолинейным — сначала получаем список, скажем, пользователей, потом для них строим требуемый результирующий набор; потом опять получаем список пользователей и строим второй набор; и все бы хорошо, если бы построение такого списка не оказывалось бы достаточно затратной операцией — и, таким образом, если на основании этого списка надо построить несколько результатов, то получается, что этот список надо получить несколько раз со всеми сопутствующими накладными расходами. Очевидным решением этой проблемы кажутся временные таблицы, и это действительно так; к сожалению, с ними связан ряд не самых приятных особенностей — для каждой временной таблицы требуется создавать файл (а при уничтожении таблицы — удалять его). Кроме того, эти таблицы, разумеется, не видны для процессов автовакуума и, следовательно, не очищаются автоматически, и по ним не собирается статистика. Что еще хуже, при наличии длительных активных транзакций может происходить неограниченный рост системного каталога; более того, кеш операционной системы заполняется данными о созданных файлах для временных таблиц, что ведет к общей деградации производительности.

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

Голосование продлится до 31 мая, сформируем программу вместе!

• инициализация кластера
• добавление и удаление узлов
• разрешение конфликтов
• восстановление после аварии
• мониторинг состояния.