Сергей Протько

https://docs.mongodb.com/manual/reference/method/d...

в английском плоховато смыслю

google translate:

replaceOne () заменяет первую найденную документ в коллекции, которая соответствует фильтру, с помощью замены документа.

Если upsert: истинна и никаких документов соответствуют фильтру, replaceOne () создает новый документ, основанный на замене документа. См Заменить Upsert.

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

2) без разницы. Лучше по дефолту брать sql и nosql для кеширования и агрегации данных в случае необходимости.

Право существовать имеет но.... а смысл?

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

Соответственно у нас появляется разделение - все операции на запись работают исключительно с реляционкой, все операции на чтение - с nosql (ну или часть с nosql и часть с реляционкой, тут смотря что вы хотите ускорять и есть ли смысл в организации агрегации данных).

Да, это более чем нормальный сценарий. Скажем хранить все в postgresql и делать агрегации данных для ускорение выборок в какой нибудь elasticsearch или монгу.

А если вы еще и CQRS будете практиковать, то вообще ништяк. Тогда команды у нас будут работать только с postgresql и инициировать обновление агрегаций а запросы - с эластикой.

формочка


Нет, я серьезно, более-менее подходящий перевод - "форма".

Храним данные в MySQL (а лучше PostgreSQL, ибо на этом можно было бы и закончить), делаем агрегацию данных в mongodb/couchdb, для выборок юзаем монгу, для записи - mysql + опять же запускаем агрегацию данных.

Монга начинает грустить когда вы пытаетесь делать там джойны. А если вы захотите сделать монгу основным хранилищем то вам захочется сделать и джойны... такие дела. Как кеширующий слой - найс. Как основная база - надо сильно хорошо подумать а стоит ли.