Приводить к числу? Вы строки суммируете?

да, там строки и числа

но в строках числа

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

это не понятно, поясните

у меня в бд есть значение value, где может быть строка или число (-1, 0, "1235) я сохраняю как есть код на рубях, но понятно должно быть .aggregate([{'$match': {id: 2234}}, {'$group': {_id: '$id', value: { '$sum': '$value'}}}]) (вообще надо последнюю запись выбрать, но пока хочу хотя бы со всеми сделать) хочу на выходе получить сумму всех value как число, не зависимо от типа value

Если монга 4 версии то можно использовать https://docs.mongodb.com/manual/reference/operator/aggregation/toInt/

Если монга 4 версии то можно использовать https://docs.mongodb.com/manual/reference/operator/aggregation/toInt/

Это вторая ссылка в гугле :))

а чего, как гуглил?

а чего, как гуглил?

https://www.google.com/search?newwindow=1&client=ubuntu&hs=Frg&channel=fs&q=mongodb+string+to+int&spell=1&sa=X&ved=0ahUKEwjy6_2jrdjcAhUEQpoKHdQODKIQBQgmKAA&biw=1080&bih=1817

хм, я думал в aggregation как-то по особенному

тэкс, оказалось что то что мне нужно это $last

слушайте, а какой порядок у полей по дефолту? .aggregate([{ '$match': { key: 2234 } }, { '$sort': { _id: -1 } }, { '$group': { _id: '$key', value: { '$first': '$value' } } }]) делаю так, всё ок, но очень медленно возвращается результат делаю так вот .aggregate([{'$match': {key: 2234}}, {'$group': {_id: '$key', value: { '$last': '$value'}}}]) очень быстро, но чёт смущает что может быть порядок не верный и как можно всю last строку вернуть, а не только одно поле?

тэкс, оказалось что то что мне нужно это $last

обратите внимание, что он имеет смысл только если отсортировано

отсортировано - значит sort в aggregation применен?

отсортировано - значит sort в aggregation применен?

да, конечно. Иначе порядок не гарантирован

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

чем с сортом

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

> и как можно всю last строку вернуть, а не только одно поле? Для этого нужно в $group добавить все нужные поля

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

Индекс есть, только прямой, попробуйте отсортировать '$sort': { _id: 1 } и взять не $last а $first

> и как можно всю last строку вернуть, а не только одно поле? Для этого нужно в $group добавить все нужные поля

грустно

грустно

Это ж логично. Чё грустить?

ну у меня есть отчеты по сессиям в монге для пользователей

мне бы хотелось взять для всех пользователей по последнему отчету

в принципе такое { '$sort': { created_at: -1 } } быстрее чем по _id

вот смотрите: у вас пользователь Вася, скажем. Записи о нём: Вася - 2018-06-06, Вася - 2018-06-07, 2018-06-08. Вы группируете по пользователю, значит первое поле будет Вася. А какую дату взять во второе поле? Максимальную? минимальную? Среднюю? Это за вас никто не решит

в принципе такое { '$sort': { created_at: -1 } } быстрее чем по _id

У вас какие индексы на коллекции? db.<имя коллекции>.getIndexes()

для сорта нужен индекс на поле

если большая база

сорт кстати по _id можно делать насколько я помню

для сорта нужен индекс на поле

Ага, можно конечно и без индекса, если ресурсов не жалко :) и порядок важен. Вот здесь можно почитать: https://docs.mongodb.com/manual/indexes/

монговский ид же тоже со временем

и можно его сортировать

сорт кстати по _id можно делать насколько я помню

так оно медленно в данном случае

10 сек против сотых

на created_at индекса нет

а сколько документов в коллекции?

261244

фигня

у меня вот щаз на одной коллекции не влезает результат

261244

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

мне больше интересно почему сорт по _id так медленно работает

и не будет ли тормозов когда добавлю индекс на created_at

мне больше интересно почему сорт по _id так медленно работает

Это нужно разобраться

и не будет ли тормозов когда добавлю индекс на created_at

Тормозов на чтение увеличиться не может. На запись - увеличится, но принебрежительно мало

а что реально сортировка по _id медленнее индекса по времени работает?

на поле времени нет индекса

на поле времени нет индекса

Сделайте

ну вот c { '$sort': { created_at: -1 } } - SUCCEEDED | 0.02214646s c { '$sort': { _id: -1 } } - SUCCEEDED | 10.304851694s

ну вот c { '$sort': { created_at: -1 } } - SUCCEEDED | 0.02214646s c { '$sort': { _id: -1 } } - SUCCEEDED | 10.304851694s

если -1, то индекс использоваться не будет. Проверьте с { '$sort': { _id: 1 } }

3 секунды

в среднем

но created_at даже без индекса быстрее _id

но created_at даже без индекса быстрее _id

Это странно... Можно попробовать поковырять explain https://docs.mongodb.com/manual/reference/operator/meta/explain/

может что-то проясниться...

ну кстати

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

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

Проверяйте explain

explain говорит что sort если на нем нет индекса вообще не участвует

explain говорит что sort если на нем нет индекса вообще не участвует

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

ну я его делаю db.collection_name.createIndex({'created_at': 1}) добавляю потом в агрегацию { '$sort': { created_at: 1 } } и работает дольше на 3 сек чем без индекса

ну я его делаю db.collection_name.createIndex({'created_at': 1}) добавляю потом в агрегацию { '$sort': { created_at: 1 } } и работает дольше на 3 сек чем без индекса

Делаете всё правильно. Но результат не правильный :) А до сорта у вас какие стейджи?

стейджи?

аа

стейджи?

ну $match, $group и т.п.

понял, сейчас

Чутка вклинюсь, а коллекция большая вообще?

Чутка вклинюсь, а коллекция большая вообще?

около 200 тыс, не большая

261244

уот

Т.е. это все лежит так и так в оперативке

и индекс делу не должен помочь

но вот чтобы ухудшило...

рубишный код [ { '$match': { key: { '$in': [2234, 2255] } } }, { '$sort': { created_at: 1 } }, { '$group': { _id: '$key', last: { '$last': '$value' } } } ] на key индекс есть

Т.е. это все лежит так и так в оперативке

Не факт, мало ли что там на сервер за ситуация...

Монга для 200тыс записей оперативку всегда сожрет :))) Ну не факт конечно

рубишный код [ { '$match': { key: { '$in': [2234, 2255] } } }, { '$sort': { created_at: 1 } }, { '$group': { _id: '$key', last: { '$last': '$value' } } } ] на key индекс есть

Давайте по другому проверим. Сделайте такой замер: db.coll_name.find().sort({ created_at: 1 }) с и без индекса

рубишный код [ { '$match': { key: { '$in': [2234, 2255] } } }, { '$sort': { created_at: 1 } }, { '$group': { _id: '$key', last: { '$last': '$value' } } } ] на key индекс есть

пробовал менять местами матч и сорт, но разницы не особо заметил

Давайте по другому проверим. Сделайте такой замер: db.coll_name.find().sort({ created_at: 1 }) с и без индекса

ок

пробовал менять местами матч и сорт, но разницы не особо заметил

match должен быть на первом месте, он сокращает датасет для следующего стейджа

ну я так и подумал

Давайте по другому проверим. Сделайте такой замер: db.coll_name.find().sort({ created_at: 1 }) с и без индекса

так, а как увидеть время запроса?)

а, ну вот

без индекса "errmsg" : "Executor error during find command :: caused by :: errmsg: \"Sort operation used more than the maximum 33554432 bytes of RAM. Add an index, or specify a smaller limit.\""

а чего оно тогда в агрегации работает)

а чего оно тогда в агрегации работает)

в агрегации до 100мегабайт лимит https://docs.mongodb.com/manual/core/aggregation-pipeline-limits/#memory-restrictions

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

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

не факт, что лезет. Проверьте по explain

в експлейне, если без индекса смотреть, обращение к created_at только в fields, если индекс присутствует то появляется sort и там так же есть created_at

в експлейне, если без индекса смотреть, обращение к created_at только в fields, если индекс присутствует то появляется sort и там так же есть created_at

Можете показать? :)

С индексом и без?

без индекса не нужно, там нечего сомтреть

Хорошо, скину

{"$cursor"=> {"query"=>{"key"=>{"$in"=>[2234, 2255]}}, "sort"=>{"created_at"=>1}, "fields"=>{"value"=>1, "key"=>1, "_id"=>0}, "queryPlanner"=> {"plannerVersion"=>1, "namespace"=>"db.collection", "indexFilterSet"=>false, "parsedQuery"=>{"key"=>{"$in"=>[2234, 2255]}}, "winningPlan"=> {"stage"=>"FETCH", "filter"=>{"key"=>{"$in"=>[2234, 2255]}}, "inputStage"=> {"stage"=>"IXSCAN", "keyPattern"=>{"created_at"=>1.0}, "indexName"=>"created_at_1", "isMultiKey"=>false, "multiKeyPaths"=>{"created_at"=>[]}, "isUnique"=>false, "isSparse"=>false, "isPartial"=>false, "indexVersion"=>2, "direction"=>"forward", "indexBounds"=>{"created_at"=>["[MinKey, MaxKey]"]}}}, "rejectedPlans"=>[]}}}

{"$cursor"=> {"query"=>{"key"=>{"$in"=>[2234, 2255]}}, "sort"=>{"created_at"=>1}, "fields"=>{"value"=>1, "key"=>1, "_id"=>0}, "queryPlanner"=> {"plannerVersion"=>1, "namespace"=>"db.collection", "indexFilterSet"=>false, "parsedQuery"=>{"key"=>{"$in"=>[2234, 2255]}}, "winningPlan"=> {"stage"=>"FETCH", "filter"=>{"key"=>{"$in"=>[2234, 2255]}}, "inputStage"=> {"stage"=>"IXSCAN", "keyPattern"=>{"created_at"=>1.0}, "indexName"=>"created_at_1", "isMultiKey"=>false, "multiKeyPaths"=>{"created_at"=>[]}, "isUnique"=>false, "isSparse"=>false, "isPartial"=>false, "indexVersion"=>2, "direction"=>"forward", "indexBounds"=>{"created_at"=>["[MinKey, MaxKey]"]}}}, "rejectedPlans"=>[]}}}

Хм... Индекс используется. А вот этот запрос что вернёт: db.coll_name.count({"key": {$in: [2234, 2255]}})

1767

получается фуллскан по 1767 документам быстрее чем по индексу из 200тыс строк, что не исключено. А ещё покажите db.coll_name.getIndexes() Интересно какой размер индекса

тут ещё интересно что по времени у меня гроуп по всей коллекции примерно одинаково что после матча

если используется дефолтное время, то там точность до миллисекунд. Если не брать экстремальные условия (более 1000 инсертов в секунду) от такого индекса мало толку.

db.collection.getIndexes() [ { "v" : 2, "key" : { "_id" : 1 }, "name" : "_id_", "ns" : "db.collection" }, { "v" : 2, "key" : { "key" : 1 }, "name" : "key_1", "ns" : "db.collection" }, { "v" : 2, "key" : { "created_at" : 1 }, "name" : "created_at_1", "ns" : "db.collection" } ]

db.collection.getIndexes() [ { "v" : 2, "key" : { "_id" : 1 }, "name" : "_id_", "ns" : "db.collection" }, { "v" : 2, "key" : { "key" : 1 }, "name" : "key_1", "ns" : "db.collection" }, { "v" : 2, "key" : { "created_at" : 1 }, "name" : "created_at_1", "ns" : "db.collection" } ]

тут размера нет. покажите var r = db.coll_name.stats() r["indexSizes"]