Глупый вопрос по PostgreSQL и JSON

Нужен extension и тип по-моему называется jsonb. Запросы по json делаются через специальный индекс со своим мини-языком запросов, но все это хорошо комбинируется с обычной реляционный логикой.

Вот только фишка монги не в JSON, а в шардинге и cas-like операциями над документами, чего в PostgreSQL нет. И использутеся монга для хранения денормализованных данных. Зачем жопу с пальцем сравнивать?

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

Почему-то я думал что в PostgreSQL для JSON что-то типа еще одной СУБД, со своими выборками и прочим.

cas-like операциями над документами, чего в PostgreSQL нет

А еще datetime нельзя запихать. В общем, что hstore, что jsonb на убийц mongo совсем не тянут, да.

Вот только фишка монги не в JSON, а в шардинге и cas-like операциями над документами, чего в PostgreSQL нет

Семантика CaS в реляционках достигается уровнями изоляции, в нормальной реляционке она, естветсвенно на порядки лучше. Шардинга в PG из коробки нет, но это совмем небольшая проблема, костылится на уровне приложения или промежуточных прослоек. Основная фишка монги (и любых других не ACID бд) как раз в скорости, в основном в скорости записи данных.

Основная фишка монги (и любых других не ACID бд) как раз в скорости, в основном в скорости

Как раз по скорости монга и просасывает.

Изоляция и cas-это разные вещи, и сравнивать их опять же нельзя, cas быстрее, но и примитивней. И про скорость все это хрень, сам подумай откудай ей взяться. Сделай в монге полную синхронность и упрешся в скорость диска, так же как и упрешся в скорость диска в случае постгреса. Или можешь в постгре отключить fsync и получишь «скорость монги». Фишка любой не реляционной базы именно в той модели данных, которая она предоставляет, и плясать надо от этого.

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

jsonb будет доступен только в 9.4 (пока beta3). Обещали на днях зарелизить в продакшен. https://wiki.postgresql.org/wiki/What's_new_in_PostgreSQL_9.4

Изоляция и cas-это разные вещи, и сравнивать их опять же нельзя, cas быстрее, но и примитивней

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

фишка монги ... в cas-like операциями над документами, чего в PostgreSQL нет

пишешь полнейшую чушь.

Изоляция и это разные вещи ... сравнивать их опять же нельзя, cas быстрее, но и примитивней

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

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

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

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

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

В твоём понимании мироустройства ПО у бизнеса само собой появляется, должно бьть аист в коробочках приносит? Если хочется так видеть мир, то я в нём буду таким аистом.

В неблокирующих реляционках MVCC обобщает CaS на любой набор данных

MVCC про разделение читателей и писателей. Писатели же прекрасно блочатся друг на друге, что не совсем cas, не так ли?

Чувак, в постгресе изоляция достигается в том числе и за счет блокировки различных обьектов. Ты представляешь какой импакт на производительносте это дает? Ты вообще сам хоть работал с этой изоляцией, ты знаешь что на уровне serializable постгр выкидывает ошибки сериализации?

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

Про то, откуда софт поялвляетя, про триаду reuse, buy, develop слыхал? Прикинь, если что то уже реализовано, то это лучше взять или купить, чем самому делать.

Фактический, в случаи PG вы получаете нормальную СУБД с ВОЗМОЖНОСТЬЮ хранить JSON, но работать с JSON документом вам надо через SQL запросы.

В случае к примеру если надо изменить значение по ключу, вам надо весь JSON документ выгрузить, изменить значение, и записать обратно.

PG может ускорить поиск по ключу и в этом она действительно быстрее монги.

т.е. если вы работает с PG вам надо думать в терминах SQL, таблица, колонки, связи, и ну и есть еще ТИП ДАННЫХ JSON, где можно похранить всякий мусор который не поддается нормализации.