https://docs.mongodb.com/manual/core/document/
Спс. Видимо просмотрел
Дмитрий
Petro
Вопросик, возможно ли в Studio3t посмотреть реальное время выполнение агрегатки? Или в каком GUI это реально?
yopp
Документ это сериализированные в BSON данные. Самый простой способ смотреть на документ как на хэш таблицу
yopp
Поддокумент это просто ключ значением которого является ещё один хеш
yopp
Или массив таких хэшей
yopp
Так как BSON массив это тоже документ, у которого ключ эквивалентен индексу элемента
Nick
стоп еще раз скип и лимит нужен по верхнему документу, по вложенным нужен только фильтр
возможно уже предлагали, но поддокументы фильтровать как вы хотите только через аггрегейш последовательностью unwind-match-group
yopp
yopp
Вопросик, возможно ли в Studio3t посмотреть реальное время выполнение агрегатки? Или в каком GUI это реально?
https://docs.mongodb.com/manual/reference/method/db.collection.aggregate/#return-information-on-aggregation-pipeline-operation
Petro
Ilya
Тогда полностью сформулируйте задачу
Есть документы такие:
{
_id: ObjectID
name: '1'
items: [
{
name: 'cвойство1'
type: 'тип1'
size: 10
},
{
name: 'cвойство2'
type: 'тип2'
size: 20
},
{
name: 'cвойство3'
type: 'тип2'
size: 0
},
]
},
....,
{
_id: ObjectID
name: '2'
items: [
{
name: 'cвойство1'
type: 'тип1'
size: 110
},
{
name: 'cвойство2'
type: 'тип2'
size: 120
},
{
name: 'cвойство3'
type: 'тип2'
size: 10
},
]
}
Надо сделать запрос такой чтобы вытащить документы у кторых имя может быть одно из '1', '2', '10', и в items у них есть поддокументы у которых size > 10
Причем в ответе для найденных документов не надо выводить поддокументы которые условию size > 10 не удовлетворяют.
Ilya
причему еще надо делать пагинацию
yopp
Если вам на страницу нужно вывести фиксированное количество поддокументов, то как я уже сказал — быстро не будет.
Если нужно вывести фиксированное количество документов, то skip/limit
yopp
А, да. Для фильтра по вложенным документам, да
Ilya
2 надо вывсети фиксированное кол-во документов, но если применять skip в агрегациях запрос начинает значительно
Ilya
угу
Ilya
ой
Nick
так в первом match в аггрегате указываете запрос с elementMatch и вашим услвоием по имени, а дальше как и выше unwind-match-group
Nick
и поверх skip-limit
Ilya
да все правильно, просто если без скипа делать запрос то он несколько милисекунд а со скипом уже полсекунды
Nick
если хотите быстро, от меняйте структуру данных так чтобы было просто их получать
Nick
иначе всегда будет медленно
yopp
Я не очень понимаю в чем загвоздка
yopp
Если нужно выводить например 10 документов в которых есть хоть одно совпадение с поддокументом — это простая задача
Ilya
ну я думаю что полсекунды на запрос - это проблема?
yopp
Посмотрите в explain
Nick
ну я думаю что полсекунды на запрос - это проблема?
дальше уже оффтоп фактически будет, но сейчас полсекунды, завтра секунда, через месяц 10 секунд, данных то больше становится
yopp
Вероятно вам нужно сделать индекс по полю вложенного документа
yopp
В вашем случае по items.size
Ilya
разве на скип как то повлияет создание индекса?
Nick
кстати аггрегаты в 3.6 только ан первый match индекс юзают?
Nick
чет затупил, задача же позволяет сделать skip-limit сразу после первого матч
Nick
а уже после делать анвинды
yopp
чет затупил, задача же позволяет сделать skip-limit сразу после первого матч
В этой задаче вообще AF не нужен
Nick
ну да
Nick
хотя стой
Ilya
смотрите я могу выбрать без скипа 1000 элементов за 10 мс, а допустим выбрать 10 документов со скипом в 1000 займет уже полсекунды - это нормально поведение*?
Nick
он просил чтобы те элементы массива у которых size>10 не выводились
yopp
смотрите я могу выбрать без скипа 1000 элементов за 10 мс, а допустим выбрать 10 документов со скипом в 1000 займет уже полсекунды - это нормально поведение*?
Я ещё раз повторю: смотрите в explain с executionStats: 1 например. Там будет детальная информация о том на что уходит время.
yopp
он просил чтобы те элементы массива у которых size>10 не выводились
У меня было ощущение что в 3.6 что-то по этому поводу завезли уже
Nick
поэтому и спросил, над будет освежить всетаки по докам
Ilya
Я ещё раз повторю: смотрите в explain с executionStats: 1 например. Там будет детальная информация о том на что уходит время.
explain для аггрегаций вроде же не показывает информации кроме как запроса?
yopp
explain для аггрегаций вроде же не показывает информации кроме как запроса?
В 3.6 уже что-то показывает
yopp
Но вам не нужна агрегация
Ilya
=) а как файндом обойтись?
yopp
Вам дешевле на клиенте отбросить поддокументы
Ilya
ааа ну вооот
Ilya
просто там поддокументов тысячи
Nick
просто там поддокументов тысячи
а сколько из них отфильтрются по size > 10? процентов 50 хотя бы наберется?
Ilya
да там отфильтруется 99%
Ilya
в плане откинутся
Ilya
а 1 % будет нужно вывести
Ilya
поэтому и не хотелось тащить их все
Ilya
в итоге пока остановились на хранимке которая items фильтрует после фаинда
Petro
Время исполнение в explain в аггрегатке нету, даже в 3.6 немогу найти. И как я понимаю нету способа посмотреть сколько реально исполняется агрегатка?
Nick
тогда может имеет смысл сравнит ьчто по скорости будет лучше AF или на клиенте
Ilya
в общем просто я думал что вдруг я не знаю какой то простой фишки а в монге она есть и мне похдходит - похоже что все норм, будем тестировать дальше)
yopp
arrayFilter завезли только для write операций
yopp
https://docs.mongodb.com/manual/reference/operator/update/positional-filtered/#up._S_[<identifier>]
yopp
Время исполнение в explain в аггрегатке нету, даже в 3.6 немогу найти. И как я понимаю нету способа посмотреть сколько реально исполняется агрегатка?
https://jira.mongodb.org/browse/SERVER-19758
yopp
Гены в своём репертуаре. ;) используй db.coll.explain(“executionStats”).aggregate(...) а не db.coll.aggregate([], {explain:true})
yopp
в общем просто я думал что вдруг я не знаю какой то простой фишки а в монге она есть и мне похдходит - похоже что все норм, будем тестировать дальше)
Ммм. Ася Камски в твиттере говорит что AF это новый find и предлагает $filter.
Но в этом случае критически важен порядок пайплайна в AF:
1) $match: name eq Z & items.size gte 10
2) $skip X
3) $limit Y
4) $filter items.size
Ilya
то есть именно в 3.6 должно работать?
yopp
3.2+
yopp
https://docs.mongodb.com/manual/reference/operator/aggregation/filter/
Petro
”executionStats" : {
"executionSuccess" : true,
"nReturned" : 1,
"executionTimeMillis" : 0,
"totalKeysExamined" : 0,
"totalDocsExamined" : 1,
"executionStages" : {
"stage" : "COLLSCAN",
"nReturned" : 1,
"executionTimeMillisEstimate" : 0,
"works" : 3,
"advanced" : 1,
"needTime" : 1,
"needYield" : 0,
"saveState" : 1,
"restoreState" : 1,
"isEOF" : 1,
"invalidates" : 0,
"direction" : "forward",
"docsExamined" : 1
}
}
Petro
executionTimeMills 0 ? это типо меньше милисекунды?
Ilya
yopp
имеется ввиду filter в project применить?
Да. Но критически важно это делать после skip и limit
yopp
Тогда трансформироваться будут только документы из «текущей страницы»
yopp
По ссылке твой пример в общем-то
Ilya
да вот в том то и проблема что как только я добавляю блок skip - то меня уже время выполнения не устраивает