Nikolay
?
Viktor
если правильно помню, то
Builder<Tournament>.Filter.ElemMatch(x => x.tourgames, Builder<TourGame>.Filter.Eq(x => x.GameId, gameId)
Viktor
а с апдейтом чуть посложней,
Builder<Tournament>.Update.Push(x => x.tourgames[-1].markets[0].records, newRecord)
Viktor
единственное, что т.к. выборки по маркету нет, то запушить можно только в конкретный
Nikolay
единственное, что т.к. выборки по маркету нет, то запушить можно только в конкретный
не даёт в markets[0].records пушить
Nikolay
говорит что то на лямбду
Nikolay
x => x.tourgames[-1].markets, game.markets[0]
Nikolay
вот так работает, но пушит не туда
Viktor
а чо говорит-то?
Nikolay
x => x.tourgames[-1].markets.FirstOrDefault(f=>f.name== "mainmarket").records, game.markets[0].records[0]
Nikolay
ну я вот так сделал
Nikolay
ругается на инвалид оперейшн
Nikolay
x => x.tourgames[-1].markets[0].records
Nikolay
заработало, наверное вижал студия тупила
Nikolay
Пасибо большое
Anonymous
ребят, чем отличаются редации монги?
yopp
Лицензия и немного фичами
yopp
Ну и ценой :)
Anonymous
немного фичами - это чем?
yopp
https://www.mongodb.com/collateral/value-mongodb-subscriptions-datasheet
yopp
Ну и ценой конечно.
Anonymous
спасибо
Anonymous
тогда такой вопрос - что есть In-Memory Storage Engine в монге?
Anonymous
Это только в энтерпрайзе, я прпаильно понимаю?
yopp
тогда такой вопрос - что есть In-Memory Storage Engine в монге?
https://docs.mongodb.com/manual/core/inmemory/
Anonymous
То есть выходит, что запуск с ключём —storageEngine inMemory будет крутить базу в памяти и типа будет быстрее?
yopp
То есть выходит, что запуск с ключём —storageEngine inMemory будет крутить базу в памяти и типа будет быстрее?
By avoiding disk I/O, the in-memory storage engine allows for more predictable latency of database operations.
A
Привет всем, такой вопрос, есть запись в таблице такого рода(скрин 1). Нужно запишуть в массив ордерс на основании symbol в массив ordersInfo объект
Я смог придумать только такую реализацию(скрин 2)
A
A
yopp
Latency != производительность
A
Но проблема в том, что upsert не срабатыает и в случае, если symbol или id нет, то выдается ошибка
MongoError: The positional operator did not find the match needed from the query. Unexpanded update: orders.$.ordersInfo
И собственно ничего не работает
Может у кого-то есть какие-то идеи или замечания к тому, как лучше это реализовать
Anonymous
By avoiding disk I/O, the in-memory storage engine allows for more predictable latency of database operations.
А в чём суть использования данной опции?
Anonymous
целевое назначение, всмысле
yopp
Stable: 3.6.4 (Apr 13, 2018), Bugfix: 3.4.14 (Mar 20, 2018)
3.6.4: https://docs.mongodb.com/manual/release-notes/3.6/#apr-13-2018
3.4.14: https://docs.mongodb.com/manual/release-notes/3.4/#march-20-2018 (3.4.15 upcoming)
3.2.19: https://docs.mongodb.com/manual/release-notes/3.2/#feb-6-2018 (3.2.20 upcoming, End of life: September 2018)
3.0.x: Support ended February 2018
A
там uspert же должен по сути создать новый документ, если не нашел айдишник или symbol, нет?
yopp
У вас там positional оператор есть
yopp
Вам в сообщение об ошибке и пишут что $ не разрешался в номер элемента
yopp
Я не уверен что такая стратегия обоснована на самом деле
A
А как можно по другому сделать?
yopp
Подумать о другой схеме, которая не будет требовать positional оператора
yopp
Вероятно вынести orders в отдельную коллекцию, где в корне будет symbol и id, а в массиве сразу документы. Тогда можно без $ делать push.
yopp
Например когда надо QoS для запроса соблюдать, например укладываться в константное время.
A
символов может быть много и создавать под каждый отдельную запись не будет ли странно?
И еще такой вопрос, конструкция {'id': req.body.id, 'orders.symbol': req.body.symbol} ищет оба параметра в записи и если не находит хотя бы один, то создает новую запись?
yopp
Это эквивалент $and
yopp
символов может быть много и создавать под каждый отдельную запись не будет ли странно?
И еще такой вопрос, конструкция {'id': req.body.id, 'orders.symbol': req.body.symbol} ищет оба параметра в записи и если не находит хотя бы один, то создает новую запись?
Не под каждую запись, а под каждую пару: пользователь-тикер
A
окей, а если мне допустим как в моем примере, надо сначала найти id, а потом уже найти symbol
A
Не под каждую запись, а под каждую пару: пользователь-тикер
так а если у пользователя много тикеров
yopp
Много — сколько?
yopp
Не забывайте что документ и так ограничен 16мб
A
1-20-50
A
от пользователя зависит
yopp
Я вам рекомендую идти по пути: make it work, make it right, make it fast
yopp
В вашем случае 50 документов на пользователя это ничего совершенно.
A
значит отдельная коллекция, отдельная запись для каждого тикера-символа)
A
окей, спасибо)
yopp
А выборка всех ордеров сводится к запросу по id пользователя.
Anonymous
yopp
Да, я бы начал с отдельного документа на каждый заказ. Тогда у вас точно не будет проблем с ограничением на размер документа.
A
А выборка всех ордеров сводится к запросу по id пользователя.
да мне в целом как я представляю и не нужно дергать все тикеры сразу, а только много ордеров по одному тикеру
yopp
Вам поможет compound индекс по id: 1, symbol: 1
yopp
Если вы выбираете по пользователю. Если просто ордера по тикеру то два отдельных индекса: id и symbol
yopp
И по возможности не используйте просто id как имя ключа
yopp
Укажите что это за id
A
Если вы выбираете по пользователю. Если просто ордера по тикеру то два отдельных индекса: id и symbol
в том и дело, что мне не нужно будет доставать только по тикеру)
А всегда пользователь-тикер)
Окей, с id понял, спасибо)
Alexey
Всем привет. Заметил странность...При добавлении нового шарда и окончании баллансировки, на старых занятое место не уменьшается, а просто перестает расти. Так и должно быть?
yopp
Всем привет. Заметил странность...При добавлении нового шарда и окончании баллансировки, на старых занятое место не уменьшается, а просто перестает расти. Так и должно быть?
Да, емнип, wt не уменьшает размер файла хранилища
yopp
В смысле не отдаёт освободившееся место назад фс
Alexey
yopp
Можно в stats посмотреть сколько свободного места осталось внутри файла
Alexey
а чего делать-то? resync?
yopp
Зависит от желаемого результата
yopp
Новые данные будут использовать освободившееся место
Alexey
если желаемый результат уменьшить сесто на дисках, поможет удаление и перезалив реплики?
yopp
Да. Но зачем?