вместо $inc

{ _id: 'nenravitsa', count: 1 }, такой список

во

значит

{$match:{'battles.date': { $gte: sundayBattle}}},

где-то тут косяк

возможно дата не в том формате

в других запросах с датами работает все

Warrior.aggregate([ {$match:{battles: {$elemMatch: {date: {$gte: sundayBattle}}}}}, ])

ну проверь юзая $elemMatch будет ли выводить что-то

пустой массив -_-

значит у тебя нет элементов удовлетворяющих условию

поменяй дату

может

ну через обычный поиск находило)

просто что только по одному, а не все

Приветы. Народ, совет нужен. Есть документы с вложенными элементами. И их обновляют конкурентные потоки. В итоге получается так, что иногда изменения не фиксируются (переписываются другим потоком). Как лучше обойти проблему?

1. Пересмотреть архитектуру. 2. Дождаться acid транзакций в четвертой монге 3. Реализовать двухфазный коммит

А. Четвертая версия, похоже, уже stable, судя по пину. Отстал от жизни.

1. Пересмотреть архитектуру. 2. Дождаться acid транзакций в четвертой монге 3. Реализовать двухфазный коммит

А чем ацид транзакции помогут?

1. Пересмотреть архитектуру. 2. Дождаться acid транзакций в четвертой монге 3. Реализовать двухфазный коммит

Двухфазным коммитом сейчас и спасаюсь.

А чем ацид транзакции помогут?

Concurrency control это фундамент acid. Две транзакции не изменят данные одновременно. Вы бы проблему детальнее описали, тогда бы стало понятнее. Еще в монге есть атомарные операции (например, inc)

Почитайте про optimistic и pessimistic concurrency control

Почитайте про optimistic и pessimistic concurrency control

Посмотрю. Спасибо.

ну он разворачивает т.е. у тебя было {_id: 1, lst: [1, 2, 3]} а если сделать $unwind: "$lst" будет {_id: 1, lst: 1}, {_id: 1, lst: 2}, {_id: 1, lst: 3}

Поправочка, _id всегда уникален :)

> db.check_unwind.insert({_id: 1, a: [1, 2, 3]}) WriteResult({ "nInserted" : 1 }) > db.check_unwind.findOne() { "_id" : 1, "a" : [ 1, 2, 3 ] } > db.check_unwind.aggregate([{$unwind: '$a'}]) { "_id" : 1, "a" : 1 } { "_id" : 1, "a" : 2 } { "_id" : 1, "a" : 3 }

Приветы. Народ, совет нужен. Есть документы с вложенными элементами. И их обновляют конкурентные потоки. В итоге получается так, что иногда изменения не фиксируются (переписываются другим потоком). Как лучше обойти проблему?

если такое нужно, использовать специализированную БД которая не имеет с этим проблем

если такое нужно, использовать специализированную БД которая не имеет с этим проблем

Да игрушку делаем. Простой старт с монгоДБ, но вот вылазит всякое такое.

ничто же не мешает несколько БД юзать

Несколько бд, несколько языков...:-)

ну таковы реалии

я редис использовал для таких дел

> db.check_unwind.insert({_id: 1, a: [1, 2, 3]}) WriteResult({ "nInserted" : 1 }) > db.check_unwind.findOne() { "_id" : 1, "a" : [ 1, 2, 3 ] } > db.check_unwind.aggregate([{$unwind: '$a'}]) { "_id" : 1, "a" : 1 } { "_id" : 1, "a" : 2 } { "_id" : 1, "a" : 3 }

Во как! Значит нельзя только сохранять. Спасибо!

может и $out можно сделать

нужно проверять

Приветы. Народ, совет нужен. Есть документы с вложенными элементами. И их обновляют конкурентные потоки. В итоге получается так, что иногда изменения не фиксируются (переписываются другим потоком). Как лучше обойти проблему?

Привет. Определиться как вы будете разрешать конфликты.

если такое нужно, использовать специализированную БД которая не имеет с этим проблем

Это не проблема БД, это проблема постановки задачи.

Идеальное решение: изменить архитектуру таким образом, чтоб конфликты не возникали.

ну вот сейчас как раз так сделал

просто не всегда получается

уйти от необходимости конкурентно менять записи. даже при смене архитектуры.

ну и как не проблема ДБ. технологии это всегда путь компромисов. монго просто не предназначена (пока) для того чтобы делать транзакции как в посгресе

кстати там есть атомарные операции

я монгу всегда почти юзаю но без фанатизма, во многих случаях реляционки лучше справляются

Проблема конфликтов по-умолчанию не имеет решения.

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

https://docs.mongodb.com/manual/tutorial/model-data-for-atomic-operations/

я хз правда какие у него конфликты. у меня как правило когда несколько процесов получают данные и лезут апдейтить документs

Два пользователя одновременно полностью изменили значение одного поля. Например флаг с правом доступа. Как решить эту проблему с помощью атомарных операций?

там есть всякие стратегии типа optimistic updates

Ну вот, ответ на вопрос — никак.

Потому что это конфликтующие изменения

И это проблема разработчика, а точнее архитектора решения, а не БД, какую из стратегий разрешения конфликта выбрать.

Блокировка один из способов разрешения. Монга по-умолчанию просто последовательно применяет операции и конфликт разрешается недетерминированно

В ряде случаев это допустимо, в ряде нет. Но выбор допустимости это не забота БД. И реляционные субд точно так же решают эту проблему

Разница в том, что реляционные бд почти всегда поддерживают транзакционность и имеют встроенные механизмы. В монге до 4.0 таких механизмов не предлагалось

Можно было реализовать свой, но 2 phase commit это безумно сложно

Идеальное решение: изменить архитектуру таким образом, чтоб конфликты не возникали.

Это онлайн игра. Есть склад, в нем содержимое. Содержимое может меняться не только по действию игрока, но и по другим причинам (типа производство).

Самый простой способ: журнал

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

Сейчас все кто хотят записать создают событие. И эти события обрабатываются последовательно.

Тоже вариант

Второй вариант, на каждый «потребляемый» элемент склада завести отдельный документ. Тогда можно будет обойтись findAndUpdate с оптимистичной блокировкой

Хотя на мой взгляд для игр журналы являются самым простым способом. Каждое изменение состояния игры — документ

Вынести содержимое склада за документ склада? Такое у нас с другим типом содержимого. Модули штучные, они снаружи. А вот сыпучка - внутри.

Например, да.

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

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

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

Спасибо всем откликнувшимся. В общем то, что сделал - не самый плохой вариант.

Транзакции не панацея. Транзакционность это ОЧЕНЬ ресурсоёмко. Её в монгу добавили исключительно для удобства, в тех случаях когда транзакционность жизненно необходима

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

Вангую разгромные статьи что монга говно

Спасибо всем откликнувшимся. В общем то, что сделал - не самый плохой вариант.

Главное убедиться что нет других клиентов, которые могут мимо очереди писать

Лучше всего настроив права и дав доступ на запись только конкретной учетной записи, с которой будет аутентифицироваться обработчик очередей

Ооо стабильная 4ка вышла

Когда обновляться советуете?

Подождать 4.2 какую нибудь

Когда обновляться советуете?

радует меня Ваш подход =) сосчитайте тут людей которым не пофиг когда Вам обновляться...

радует меня Ваш подход =) сосчитайте тут людей которым не пофиг когда Вам обновляться...

ну и че ты тут сидишь тогда раз тебе на все пофигу?

Когда обновляться советуете?

вчера еще надо было

вчера еще надо было

+1 =)

June 27, 2018

разумно наверное будет подождать до следующей минорной версии.

Когда обновляться советуете?

Нолик всегда смущает. Лучше подождать, имхо.

Главное убедиться что нет других клиентов, которые могут мимо очереди писать

Ну это подконтрольная штука. Может очередь сообщений сюда прикрутить. Хм....

4.0.1 уже на подходе https://docs.mongodb.com/manual/release-notes/4.0-changelog

4.0.1 уже на подходе https://docs.mongodb.com/manual/release-notes/4.0-changelog

Это уже что-то...

норм. фичи были $lookup и $facet

Привет, кто работал с mgo? подскажите есть ли возможность получить objectid созданного документа при Insert?

Привет, кто работал с mgo? подскажите есть ли возможность получить objectid созданного документа при Insert?

По идее, должно возвращать.