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

если «работает довольно медленно» надо разбираться с «работает довольно медленно»

Добрый день, подскажите пожалуйста, я новичок в mongodb, хочу написать приложение на связки express + mongodb, раньше писал на ruby, python немного на go, использовал postgres либо mysql, можете сказать пожалуйста какие есть ограничения у mongodb, в плане, на сколько она лучше/хуже postgres'а либо mysql, можно ли делать какой-то большой сервис целиком на связки mongo и express ?

Совершенно побарабану на чём начинать. На чём умеешь, на том и делай. Плюс монги в относительно низком пороге вхождения. В остальном база как база. Нужно запомнить что монга НЕ реляционная база данных и научится мыслить документами. Это значит что подходы из реляционной субд в монге будут работать из рук вон плохо. Ну и да, не надо забывать что транзакций нет, есть только гарантия атомарности изменений в одном документе. Это требует тоже отдельного мышления.

Но общее правило: если без транзакций никак — лучше брать не монгу

Потому что транзакции в монге ОЧЕНЬ сложно делаются

спасибо большое, учту!)

Привет, ребят. Сделал 2 формы авторизации и регистрации. Теперь их как то надо обработать на node (желательно без express) и данные запихнуть в монгу. Подскажите мб туториал какой то по созданию и обработки форм и доку какую то

это в канал по ноде

этот парень вов сех чатах походу одним и тем же собщением метит)

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

Есть $lookup в агрегациях.

Если при работе с монгой понадобился $lookup, значит что-то пошло не так на этапе выбора СУБД

Если при работе с монгой понадобился $lookup, значит что-то пошло не так на этапе выбора СУБД

на самом деле тривиальная задача - посчитать количество записей пользователя, я просто хочу узнать как все таки верно

в доках указывается что вроде как нужно коллекционировать айди записей и добавлять их пользователю

на самом деле тривиальная задача - посчитать количество записей пользователя, я просто хочу узнать как все таки верно

А в записях пользователь не по логину привязан?

А в записях пользователь не по логину привязан?

как Object(_id)

на самом деле тривиальная задача - посчитать количество записей пользователя, я просто хочу узнать как все таки верно

Инкрементить счетчик при добавлении записи пользователя

Инкрементить счетчик при добавлении записи пользователя

просто используя key-value я бы при выборке посчитал бы все записи пользователя в отдельной таблице, в монге как я понимаю это не совсем правильное решение, верно?

Инкрементить счетчик при добавлении записи пользователя

Потом обязательно где-нибудь разъедется. Count по индексу довольно дешёвый. Только надо в сообщения логин положить, а не связь с objectid. Логин же уникальный скорее всего?

просто используя key-value я бы при выборке посчитал бы все записи пользователя в отдельной таблице, в монге как я понимаю это не совсем правильное решение, верно?

Не понятна целиком задача, мало инфы

Потом обязательно где-нибудь разъедется. Count по индексу довольно дешёвый. Только надо в сообщения логин положить, а не связь с objectid. Логин же уникальный скорее всего?

да, логин уникальный, а чем плоха связь через _id?

да, логин уникальный, а чем плоха связь через _id?

Тем, что это типичный sql-подход. А чем плохо - вот наше обсуждение тут говорит о том, чем плохо

Не понятна целиком задача, мало инфы

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

Тем, что это типичный sql-подход. А чем плохо - вот наше обсуждение тут говорит о том, чем плохо

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

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

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

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

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

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

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

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

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

И посчитать количество сообщений - простейший count по логину

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

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

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

Это если на входе id, а там обычно логин все-таки

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

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

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

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

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

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

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

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

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

если нужно моментально доставать профиль - то должно быть всё заранее расчитано если не нужно моментально - то можно считать во время запроса

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

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

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

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

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

Почему ?

Почему ?

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

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

А если щарды, то запись вообще может быть в разные primary

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

Вот именно ) Если это инфа архи важная например банковский счёт с деньгами, то следает предусмотреть механизм транзакций на сервере, для таких операций.

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

Ремастер 10сек

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

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

Пользуюсь счётчиками, брат жив, зависимости нет.

Делаю переиндексацию раз в месяц, когда мне больше делать нечего.

Рассинхрон бывает редко.

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

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

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

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

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

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

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

Это так. В моём случае счётчики не содержат важную величину (деньги или ещё что-то такое), поэтому я могу позволить себе небольшую погрешность. Правда, как я уже говорил, рассинхрон бывает очень редко.

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

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

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

Anything that can go wrong will go wrong. ©Murphy's law

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

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

И что ?

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

Соотноси ценность инфы и затраты

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

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

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

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

Сессии на стороне браузера? А как синхронизация происходит?

У меня сессионная игра. Сессия на сервере

И один бекенд?

Когда игрок заходит - загружается его сессия (профиль и вся инфа). Далее все обновления вносятся вначале в сессию а затем сессия дёргает бд и записывает в базу.

Пока один сервер, который при нагрузочном тестировании держал 60к CCU. Пока это гораздо больше чем игроков ) А потом возможно будем масштабировать

Пошаговая сессионка, мобильная игра, типа HeartStone

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

А если 2

Просто половина игроков будут направлены на другой бэкенд и всё тоже самое

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

ненада

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

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

это блокируется

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

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

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

Между двумя серверами.

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

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

При традиционном подходе все серверы равноценные, а не игроки привязываются к одному. Что будет, если один из серверов выйдет из строя идм будет остановлен на обслуживание или обновление?

Ну если akka такая крутая и все делает за разработчика, то ок. Я хз что это, первый раз слышу.

это ббилиотека для работы с акторами

есть и для скалы, и для C#

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

what'sapp все равно написан на erlang :)

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

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

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

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

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

наоборот :)

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

Ты не то нагуглил Восновном Akka + Scala , Akka + Java на JVM - популярны

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

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

наоборот :)

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

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

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

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

это не мнение, ибо ирлонг с 1987 года существует :)

2 Сергея пишут, пойду желание загадывать

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

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

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

Я больше сторонник классического подхода: haproxy + quagga)

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

нет, не в ней :)

Скала - то еще чудо

Я в проекте использую Java + Akka + MongoDB