@mongodb_ru - страница 297 - Telegram web archive

Bro

значит

Bro

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

Bro

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

Bro

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

Rrr

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

Bro

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

Bro

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

Rrr

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

Bro

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

Bro

поменяй дату

Bro

может

Rrr

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

Rrr

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

Евгений

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

Rustam

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

Rustam

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

Евгений

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

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

Евгений

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

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

Rustam

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

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

Rustam

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

Евгений

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

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

AstraSerg

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

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

Bro

> 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 }

Bro

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

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

Евгений

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

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

Bro

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

Евгений

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

Bro

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

Bro

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

AstraSerg

> 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 }

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

Bro

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

Bro

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

yopp

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

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

yopp

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

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

yopp

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

Bro

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

Bro

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

Bro

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

Bro

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

Bro

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

Bro

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

yopp

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

yopp

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

Bro

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

Bro

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

yopp

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

Bro

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

yopp

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

yopp

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

yopp

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

yopp

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

yopp

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

yopp

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

yopp

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

Евгений

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

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

yopp

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

yopp

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

Евгений

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

yopp

Тоже вариант

yopp

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

yopp

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

Евгений

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

yopp

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

Bro

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

yopp

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

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

Евгений

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

yopp

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

yopp

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

yopp

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

yopp

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

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

yopp

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

Bro

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

Bro

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

Bro