LINUX.ORG.RU

Что в PostgreSQL с NoSQL?

 , , ,


1

2

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

Что будет? Будет некий документ, описывающий заготовку запроса. Довольно развесистую (там далеко не 5-6 параметров), ссылающуюся на внешние ресурсы, файлы и с возможностью посейвить и изменить её. Причём заготовок будет не одна и после запуска сервиса их ещё и добавлять будут. Сделать такое на документо-ориентированной базе легко и особой головной боли не доставит.

Знаю, что в PostgreSQL есть какая-то поддержка NoSQL и JSON, но никогда не юзал её и не курил доков на эту тему.

Чего хочется? Хочется иметь возможность работать с записью так же, как в MongoDB + классическую схему из плоских таблиц с дефолтными плюшками SQL баз.

С монгой работал и могу делать всё на ней, но хочу посмотреть на другие варианты. Причём в сильную маргинальщину залезать нельзя.

Что посоветуете посмотреть по докам PostgreSQL, чтобы оценить разницу с монгой в плане NoSQL и документов? Ссылки в гугле уже читаю, но может кто-то знает какие-либо хорошие обзорные статьи и примеры, чтобы быстро оценить, что там и как.

★★★★★

1) иди не от того плоские у тебя данные или ребристые с усиками, а от того как будешь их использовать, нужны ли транзакции, какая нагрузка и т.д.
2) если тебе реально *НУЖНО* использовать и обычные таблицы и то, что предоставляет NoSQL, - тогда лучше бери две базы

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

Нагрузка будет небольшой (максимум несколько тысяч уников в день, скорее - сотни, ни о каких 10к соединений речи не идёт). Транзакции нужны. Меня тут больше беспокоит то, сколько будет стоить поддержка и расширение сервиса (а оно будет причём не на один год).

Меня интересует наиболее удобный инструмент для разработки в данном случае, т.к. это определит кол-во геморроя в будущем.

Norgat ★★★★★ ()

Бери постгрес и не парь себе мозг.

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

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

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

наши тоже возмущались, что монга не пашет однозначно.
например аналог select count() не всегда возвращает верное количество.

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

Нет. Стрёмно. И профита в моем случае маловато.

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

просто феерично, это собираются исправлять?

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

это не баг, оно просто так работает, by design. если нужны консистентные чтения не по PK в конкурентной среде, то монга не подходит для этого.

drsm ()

Если не знаешь, что взять, бери PostgreSQL, и только так.

Я к тому, что NoSQL решения нужно использовать ТОЛЬКО в случае если ты прекрасно понимаешь, зачем оно тебе, какие констрейнты по производительности(причем не на уровне «на лоре услышал»), и ты ДОСКОНАЛЬНО знаешь все их недостатки и drawbacks.

Часть БД всегда можно будет перенести в NoSQL при желании. В обратном же случае ты будешь городить RDBMS из NoSQL решения, и зароешься в этом.

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

все их недостатки и drawbacks

все их недостатки и недостатки

Он знал довольно по-латыне,
Чтоб эпиграфы разбирать,
Потолковать об Ювенале,
В конце письма поставить vale,
Да помнил, хоть не без греха,
Из Энеиды два стиха.

не про тебя часом? :-D
в следующий раз сначала в словарь посмотри, прежде чем слово заморское в лоровский камент всовывать )))

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

Я не спрашивал совета что взять. Я спрашивал как в PostgreSQL с поддержкой работы с документами, чтобы сравнить с MongoDB с которой работал ранее и понять, а стоит ли мне вообще рыпаться в сторону PostgreSQL в плане работы с документами.

Если что, то под документами я понимаю развесистые древовидные структуры, где поддеревья могут расти (например за счёт пользовательского ввода данных), а разных структур поддеревьев может быть несколько. Собирать такое на SQL та ещё радость. Работает оно медленнее чем в Mongo (выборка данных, тестил), а поддерживать и расширять такой SQL лично мне радости не доставляет от слова совсем.

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

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

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

если нужны консистентные чтения не по PK в конкурентной среде, то монга не подходит для этого.

те чтобы это наблюдать один поток должен массово апдейтить записи, а другой читать их не по primary key, так?

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

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

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

это типичный рейс кондишен. там в статье все описано. нужно чтобы в момент index scan'а запись перелетела из еще не просканированной части индекса в уже просканированую.

For example, if your “people” collection has a compound index on “(country, city)” (and no index just on “country”) and you run:
[code]people.find({country: «France»})[/code]
Then a write which changes a document from “country France, city Paris” to “country France, city Bordeaux” while the query is currently scanning “country France, city Nice” will miss that person.

и это не лечится.

drsm ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.