LINUX.ORG.RU

Новое хранилище JSON в PostgreSQL 9.4

 , ,


0

5

В разрабатываемую сейчас новую версию PostgreSQL, 9.4, было добавлено новое хранилище JSON документов — JSONB. На смену текстовому представлению JSON пришел эффективный двоичный формат, позволяющий осуществлять быстрый доступ к отдельным полям документа.

Хранилище создавалось с учетом наработок по HSTORE — key-value хранилищу, созданному почти 10 лет назад в рамках проекта PostgreSQL. Аналогично HSTORE, для JSONB была добавлена поддержка GIN-индексов. Так, производительность реализации операции «содержится в» по индексу сравнима с производительностью аналогичной операции в MongoDB.

По мнению Josh Berkus, одного из членов PostgreSQL Core Team, добавление JSONB является наиболее важным изменением в PostgreSQL, позволящее ему составить конкуренцию MongoDB и другим документным хранилищам.

>>> Подробности

★★★★★

На сколько ускоряется поиск?

Evgueni ★★★★★ ()

Лично мне все равно: монгу я использую тогда и только тогда, когда необходимо горизонтальное масштабирование на уровне БД (само приложение об этом не в курсе). Так что, то что в PostgreSQL эта штука появилась - это конечно хорошо, но, на самом деле, я как использовал монгу, так и буду использовать. А причины я уже изложил.

k0valenk0_igor ★★★ ()
Последнее исправление: k0valenk0_igor (всего исправлений: 1)

Шикардос. Весьма и весьма годное нововведение.

gwinn ★★★★ ()

Годнота. Спасибо за новость.

Deleted ()
Ответ на: комментарий от moot

Очень годно!

а кто-нибудь знает когда 9.4 релизнется?

Вроде как релиз намечен на третий квартал этого года.

northicewind ()
Ответ на: комментарий от goingUp

А в чем профит?

в доступе к полям и индексе

По этим JSON полям можно делать джоин?

Можно. Но misusage.

Есть ACID?

без него в постгресе сделать что-либо сложно

teodor ()
Ответ на: комментарий от goingUp

А в чем профит? По этим JSON полям можно делать джоин? Есть ACID?

ACID есть. JOIN сделать тоже можно (отдельный только вопрос насколько эффективно это будет работать).

maxcom ★★★★★ ()
Ответ на: комментарий от goingUp

Видимо в том, что для ряда случаев, когда раньше использовали совместно с постгресов что-то вроде монго, сейчас можно его же и использовать.

Legioner ★★★★★ ()

Вот какие же они все таки молодцы.

anonymous ()

JSONB это формат или просто название хранилища? если формат, то где-то есть описание?

quest ★★★★ ()

монга не нужна, слава постгре!

tazhate ★★★★★ ()
Ответ на: комментарий от quest

JSONB - это тип данных в постгресе. Его текстовое представление - JSON. Внутренний формат унаследован у hstore (с некоторыми изменениями: типы, вложенность, массивы etc)

teodor ()
Ответ на: комментарий от anonymous

А кто бы теперь запилил MongoDB vs PostgreSQL

А чего там сравнивать - у них же области пересечения очень маленькие? MongoDB нельзя использовать ни для чего, где важен ACID, т.е. ни для чего более-менее критичного к целостности и непротиворечивости данных.

anonymous ()
Ответ на: комментарий от anonymous

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

Binary ★★★★★ ()

А вот вопрос: для данных JSONB поддерживаются ли атомарные операции на стороне сервера? Если да.... то я начинаю видеть в этой теме изрядный профит.

k0valenk0_igor ★★★ ()
Последнее исправление: k0valenk0_igor (всего исправлений: 1)
Ответ на: комментарий от Binary

Это если поддерживается тот же (или хотя бы приблизительно тот же) набор операций (включая атомарные) что и у Монги. Потому что большого смысла брать коллекцию документов из поля JSONB на сторону клиента, что бы сделать то, что делает Монга (поиск, атомарные изменения контента и т. д.) с моей точки зрения - нет. Слишком затратно. А вот если это сделает сам Postgre на стороне сервера.... ну тогда вопрос уже другой.

k0valenk0_igor ★★★ ()
Ответ на: комментарий от k0valenk0_igor

А вот вопрос: для данных JSONB поддерживаются ли атомарные операции на стороне сервера?

В том же объеме как и для других типов данных — транзанкции, MVCC, все это будет и для записей которые содержат JSONB.

maxcom ★★★★★ ()
Ответ на: комментарий от maxcom

Это может оказаться совсем не одним и тем же. Предположим я положил коллекцию документов в поле JSONB. Но с точки зрения PostgreSQL это может оказаться вовсе не коллекция документов, а массив данных типа JSON! И разница будет очень существенна: в поддерживаемых операциях на стороне сервера.

Я, предположим, захочу во всех документах изменить определенных атрибут. Так вот, с точки зрения «поле JSONB - это набор данных типа JSON» я должен буду считать эти данные на сторону клиента, парсировать их и изменив то, что мне надо вернуть «на базу». И скажу прямо такой подход не дает никакого профита!

Куда интереснее передать серверу js-выражение, меняющее все что надо, на его стороне. Атомарно меняющее. Но для этого надо что бы:

- сервер поддерживал такие (не реляционные) выражения

- сервер считал поле JSONB не набором JSON-данных, а коллекцией документов

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

И это я еще не затрагиваю такие концепции как map-reduce. Потому что пока речь у нас шла об операциях с коллекциями документов хранящихся в единичном поле JSONB. А вот как только мне понадобится сделать распределенный запрос к набору таких полей (быть может в разных таблицах).... вот тогда начнется настоящее веселье

k0valenk0_igor ★★★ ()
Последнее исправление: k0valenk0_igor (всего исправлений: 1)
Ответ на: комментарий от k0valenk0_igor

В нормальных СУБД для такого есть хранимки. Берем pl/pgpython и вперед. Хотя может и штатного языка хранимых процедур может хватить, чтоб повертеть JSON-полями. Вроде в 9.3 достаточно гибкие функции, для части мест хватит http://www.postgresql.org/docs/9.3/static/functions-json.html

Хочется собрать хранимку на клиенте и выполнить на сервере, вот есть ручка: http://www.postgresql.org/docs/9.0/static/sql-do.html

P.S. Для извращенцев есть pl/v8js

anonymous ()
Ответ на: комментарий от anonymous

Хранимых процедур действительно скорее всего хватит что бы распаковать такое поле и что-то с ним сделать. Но вот удобство такого подхода весьма сомнительно. Хотя бы уж потому, что хранимую процедуру придется предварительно объявить. Это раз.

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

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

k0valenk0_igor ★★★ ()
Ответ на: комментарий от k0valenk0_igor

во всех документах изменить определенных атрибут

не знаю, как будет реализовано в jsonb, но вот hstore, который использовался за основу, вполне позволяет модифицировать отдельное поле:

update customers set data = data || ('email' => 'asdadad@sfsfdsf.adsa') where id = 1;

anonymous ()
Ответ на: комментарий от k0valenk0_igor

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

Хочется собрать хранимку на клиенте и выполнить на сервере, вот есть ручка: http://www.postgresql.org/docs/9.0/static/sql-do.html

А про мультимастер и шардинг в слонике - это Postgresql-XC. Оно пока в бете, но кто-то уже юзает.

anonymous ()
Ответ на: комментарий от teodor

Уважаемый, Федор.

Спасибо вам за вашу замечательную работу.

Планируется ли работа по более тесной интеграции с движком PLV8?

anonymous ()
Ответ на: комментарий от anonymous

Нет не имеется. Точнее имеется, но это совсем-совсем не то, что нужно: в монго управлением шардингом ведает сама БД и ведает, кстати, совсем не плохо. В случае же pgpool-II мало того что при добавлении нового нода придется пересчитывать все коэффициенты, так еще и приложение должно быть в курсе, о том, что оно свои данные хранит на кластере. Так что геморрой тот еще. Сравните с решением «ис каропки» в Монго - там все что нужно, это прямые руки админа.

k0valenk0_igor ★★★ ()
Ответ на: комментарий от k0valenk0_igor

А вот как только мне понадобится сделать распределенный запрос к набору таких полей (быть может в разных таблицах)....

... тогда-то станет ясно, что постгрес (как и весь ACID) не умеет в масштабирование, и seqscan работает быстрее, а эти влажные мечты останутся мечтами.

shahid ★★★★★ ()
Ответ на: комментарий от shahid

тогда-то станет ясно, что постгрес (как и весь ACID) не умеет в масштабирование

мля, как уже достали «будуюшие гуглы»! 99.99999% проектов, которым не нужен acid, никогда не дорастут до необходимости масштабирования.

anonymous ()
Ответ на: комментарий от anonymous

99.99999% проектов, которым не нужен acid, никогда не дорастут до необходимости масштабирования.

99.999999% проЭктов, которые каждый день рождаются в интернетах, никогда не станут нужны и сдохнут в ближайший год. Даже если предположить, что все они на постгресе, то посгрес от этого становится ненужным?

shahid ★★★★★ ()
Ответ на: комментарий от teodor

ясно, я думал это что-то типа BSON - четкий бинарный формат, но свой. хотелось формат посмотреть

quest ★★★★ ()
Ответ на: комментарий от KRoN73

Постгре умеет мастер-мастер репликацию?

Есть сторонние костыли, дающие ограниченный мультимастер с нелинейным горизонтальным масштабированием. Например Postgres-XC: «More than 3× scalability performance speedup with five servers».

shahid ★★★★★ ()

Однозначно годнота! Для всяких веб-магазинчиков с их товарами-атрибутами самое то.

matumba ★★★★★ ()
Ответ на: комментарий от shahid

99.999999% проЭктов, которые каждый день рождаются в интернетах, никогда не станут нужны и сдохнут в ближайший год. Даже если предположить, что все они на постгресе, то посгрес от этого становится ненужным?

у вас какая-то глубоко личная идея о том, что такое логика.

anonymous ()
Ответ на: комментарий от maxcom

отдельный только вопрос насколько эффективно это будет работать

Учитывая, что индекс можно построить по произвольному выражению - как минимум сравнимо по эффективности.

Sectoid ★★★★★ ()
Ответ на: комментарий от k0valenk0_igor

Игорь, глупо сравнивать mongodb vs PostgreSQL. Совсем недавно mongo отучилась от lock(ов) вообще не весь процесс. Но по прежнему запись это lock отдельной базы. О чем мы вообще здесь рассуждаем?

Конкретно вырезка из документации (http://docs.mongodb.org/manual/faq/concurrency/)

When a read lock exists, many read operations may use this lock. However, when a write lock exists, a single write operation holds the lock exclusively, and no other read or write operations may share the lock. … Beginning with version 2.2, MongoDB implements locks on a per-database basis for most read and write operations. Some global operations, typically short lived operations involving multiple databases, still require a global “instance” wide lock. Before 2.2, there is only one “global” lock per mongod instance.

На минуточку в PostgreSQL блокировка per-row.

anonymous ()
Ответ на: комментарий от anonymous

На минуточку в PostgreSQL блокировка per-row.

Вы не учитываете, что при наложенной блокировке «на строку», хранилище JSONB все равно будет блокировано эксклюзивно, поскольку физически оно есть поле строки в таблице. То есть мы все равно получим лок на процесс вздумавший изменить что-то в коллекции документов, которая суть поле JSONB. Ну и чем же это лучше подхода Mongo?

Альтернативой для Postgre могло бы быть введение новых типов блокировок на часть (!) поля. Но честно сказать, я с трудом представляю как это возможно чисто архитектурно без существенной потери быстродействия.

Но даже если представить, что это получилось, то все равно у Postgre будет огромная проблема при блокировании данных находящихся в разных полях JSONB (а тем более в разных таблицах, не говоря уж на разных нодах).

А у Mongo проблем с этим нет. Mongo именно из-за отказа от ACID легко и непринужденно справляется с такими задачами и выигрывает на этом.

Есть еще интересная базка - OrientDB. Она вроде как документо-ориентированная, но умеет транзакции и вообще гарантирует ACID. Гарантирует-то гарантирует, но только в пределах нода. То есть как только речь заходит о шардинге - гарантии отменяются.

k0valenk0_igor ★★★ ()
Последнее исправление: k0valenk0_igor (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.