извини, перечитал переписку но не догнал чем плохо, можешь объяснить, пожалуйста? Хочу понять.

Чтобы достать сообщения одного пользователя в случае с id надо делать или два запроса или lookup. При этом, более сложные запросы уже будут достаточно неэффективными.

понимаю, а почему в случае с username нет? ведь придется выбирать так же 2 запросом или через лукап, но связывать через другое поле?!

Потому что username уже лежит в каждом сообщении

задача довольно простая - вывожу список пользователей и у каждого указываю количество записей, пользователь и запись связаны через _id

так ведь и _id тоже, в мое случае будет Post.find({ _author: req.user.id }, а в случае с uname Post.find({ _author: req.user.name } ?!

эффективная структура данных зависит не от того что есть а от того как это обновляется и как достаётся Например у меня есть большой объект пользователь в нём есть блок Stat в котором gameCount - счётчик игр когда пользователь сыграл игру, этот счётчик инкрементится когда нужно отобразить статы, я просто считываю этот блок Stat со всеми статами и показываю в профиле всё просто и никаких долгих агрегатных запросов ничего не рзъезжается

эффективная структура данных зависит не от того что есть а от того как это обновляется и как достаётся Например у меня есть большой объект пользователь в нём есть блок Stat в котором gameCount - счётчик игр когда пользователь сыграл игру, этот счётчик инкрементится когда нужно отобразить статы, я просто считываю этот блок Stat со всеми статами и показываю в профиле всё просто и никаких долгих агрегатных запросов ничего не рзъезжается

Без транзакций всегда нужно ожидать, что что-то разъедется. База может встать в RO между двумя запросами или что-то ещё

у меня все операции атомарные, нет никаких двух запросов

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

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

Тогда да, верно - два запроса, а что может случиться ?

Сообщение может добавиться, а инкремент - не пройти

Почему ?

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

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

Пр любой причине: лаг сети, база упала или что-то ещё

а что лаг, как он не даст заинкрементить счётчик ?

Ну зависит от того как бек настроен, наверное не лучший вариант при вставке висеть 10+ секунд без ответа пользователю, пытаясь повторить вставку в общем-то не критичного счётчика

Так вставку счётчика надо отложить в очередь, если счётчик не является важной величиной.

С очередью ещё одна проблема появляется)

Ну зависит от того как бек настроен, наверное не лучший вариант при вставке висеть 10+ секунд без ответа пользователю, пытаясь повторить вставку в общем-то не критичного счётчика

Причём тут висеть, мы же о целостности разговаривали и транзакциях У меня реактивная архитектура (Akka actors) там ничего не блокируется, вставка выполнится через 10 сек обоих записей. При этом запросы продолжат обрабатываться. Учитывай вероятности возникновения событий. Те вещи про которые ты пишешь случаются раз в год или реже (у меня к примеру ниразу так до сих пор база не падала в продакшене за два года)

Ну база может и не упадёт, но дц, где находится мастер, вполне может отвалится

Причём тут висеть, мы же о целостности разговаривали и транзакциях У меня реактивная архитектура (Akka actors) там ничего не блокируется, вставка выполнится через 10 сек обоих записей. При этом запросы продолжат обрабатываться. Учитывай вероятности возникновения событий. Те вещи про которые ты пишешь случаются раз в год или реже (у меня к примеру ниразу так до сих пор база не падала в продакшене за два года)

В случае с отложенной вставкой ещё надо реализовывать 2PC иначе больше проблем, чем пользы. Пользователь на свое действие получил ок, а данные до базы не доехали.

игрок же не может одновременно дважды из-под одного акка зайти?

Если два, то эти сессии уже надо как-то синхронизировать

А с чем их синхронизировать ?

ну это не синхронизация а роутинг т.е. есть load balancer который один на кластер, и который распределяет по серверам игроков, и знает кто где сидит (по Id) и переправляет запросы Это имеется ввиду ? При традиционном подходе как то так делается. Но с Akka проще. Во первых акторы поддерживают location transparency. (т.е. акторы можно разнести по машинам и они также будут работать как и на одной, при этом код их не поменяется. А также в Akka Cluster есть готовые примитивы, для построения распределённых систем. Типа Cluster Singleton, различные балансеры, которые раскидывают работу в зависимости от нагрузки на ноду, или по каким либо другим правилам ...

Да, её использует Ebay , Blizzard, CISCO, BBC и другие никому неизвестные компании

да это Erlang тоже акторы, похож на Akka

Вот уж не думал, что ebay на дотнете работает

а вот вопрос: подписка на что в кластере требуется? что отлавливаем?

наоборот :)

Отлавливать вход выход нод из кластера, загрузку нод и прочее

Есть и такое мнение )

хм... это в нормальной платформе давно есть :)

Отлавливать вход выход нод из кластера, загрузку нод и прочее

Получается Акка нормальная платформа ? )

Всем привет, есть ли тут кто-нибудь из страдальцев php/mongodb?

Всем привет, есть ли тут кто-нибудь из страдальцев php/mongodb?