Что в PostgreSQL с NoSQL?

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

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

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

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

Транзакции нужны.

из последнего

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

Как там Postgress после Mongodb и в частности в node.js?

Спасибо.

А сам на постгрес мигрировал или нет?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

это типичный рейс кондишен. там в статье все описано. нужно чтобы в момент 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.

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