Какие вы знаете проблемы и риски, и способы их решения в nosql?
В частности речь идёт о MongoDB. Я знаю 3 самые известные проблемы:
1. отсутствие транзакций
2. отсутствие join
3. не блокируемый доступ
Дальше я вкратце расскажу о том, что успел накопать.
Связность данных опустим, потому что её обычно удобнее задавать программно, к тому же есть фреймворки ORM. Вместо транзакций можно было бы записывать все изменения документа разом, но это не позволяет проявиться ORM фреймворкам... хотя, может я не знаю о реализации транзакций в mongoose? Join при связи "один ко многим" вообще не нужны, но если возникают "многие ко многим", можно работать через id и опять же создавать связность программно.
Больше всего меня пугает, что база не блокирует доступ на чтение, когда идёт перезапись (и наоборот). Возможно, вы подскажете грамотные решения перечисленных проблем и добавите новые, которые я упустил.
1. Есть там транзакции. Не такие развитые как в РСУБД, но атомарные операции вполне есть. Можно сделать и "выборку-обновление" за один шаг - чем не транзакция.
2. Join не нужны. Если вы походите к Mongo с подходами реляционных СУБД - все будет плохо. В Mongo проще хранить лишнюю копию данных в самом объекте/таблице (чтобы обходиться без Join) для более скоростной выборки
3. С каких пор это недостаток? Oracle - самая богатая корпорация была долгие годы. Их одноименная РСУБД - не блокирующая.
ORM фреймворки?
Зачем они с Mongo?
Вы знаете что означает буква R в названии ORM?
Они не нужны.
По поводу того, что вас испугало - изучайте "язык" Mongo. Там можно в одной атомарной операции сделать и чтение и обработку и запись.
По поводу пункта 2: зачем делать лишнюю копию, когда она занимает лишнее место и при изменении оригинала остаётся неизменной (или вызывает расходы на поиск и обработку копий)
ORM - вы правы, не тот термин подобрал. Я имел ввиду mongoose для node.js и т.п. решения, упрощающие работу с объектами.
По поводу пункта 2: зачем делать лишнюю копию, когда она занимает лишнее место и при изменении оригинала остаётся неизменной (или вызывает расходы на поиск и обработку копий)
В терминах РСУБД это будет "денормализация". Ради скорости.
Дисковое пространство сегодня дешево.
Из минусов - да, будет необходимость поддерживать целостность данных (единообразие копий данных в разных типах таблиц/объектов) программным путем.
Виталий:
Решение работать с нормализованной или денормализованной формой данных - чрезвычайно ИНДИВИДУАЛЬНО.
Зависит от:
Как часто данные изменяются (например, в последнее время частенько данные вообще не удаляются - никогда),
Каковы требования по скорости выборки/поиска,
Может ли изменяться структура данных в будущем,
и пр. и пр.
bnytiki:
Часто допустимым является несогласованность данных - ради производительности.
А поиск/синхронизация/обновления частей - проводятся в отложенном режиме (спустя час, сутки)...
Простой
