Я ещё раз повторю: смотрите в explain с executionStats: 1 например. Там будет детальная информация о том на что уходит время.

explain для аггрегаций вроде же не показывает информации кроме как запроса?

explain для аггрегаций вроде же не показывает информации кроме как запроса?

В 3.6 уже что-то показывает

Но вам не нужна агрегация

=) а как файндом обойтись?

Вам дешевле на клиенте отбросить поддокументы

ааа ну вооот

просто там поддокументов тысячи

просто там поддокументов тысячи

а сколько из них отфильтрются по size > 10? процентов 50 хотя бы наберется?

да там отфильтруется 99%

в плане откинутся

а 1 % будет нужно вывести

поэтому и не хотелось тащить их все

в итоге пока остановились на хранимке которая items фильтрует после фаинда

да там отфильтруется 99%

99% элементов внутреннего массива?

Время исполнение в explain в аггрегатке нету, даже в 3.6 немогу найти. И как я понимаю нету способа посмотреть сколько реально исполняется агрегатка?

99% элементов внутреннего массива?

да

тогда может имеет смысл сравнит ьчто по скорости будет лучше AF или на клиенте

в общем просто я думал что вдруг я не знаю какой то простой фишки а в монге она есть и мне похдходит - похоже что все норм, будем тестировать дальше)

arrayFilter завезли только для write операций

https://docs.mongodb.com/manual/reference/operator/update/positional-filtered/#up._S_[<identifier>]

Время исполнение в explain в аггрегатке нету, даже в 3.6 немогу найти. И как я понимаю нету способа посмотреть сколько реально исполняется агрегатка?

https://jira.mongodb.org/browse/SERVER-19758

Гены в своём репертуаре. ;) используй db.coll.explain(“executionStats”).aggregate(...) а не db.coll.aggregate([], {explain:true})

в общем просто я думал что вдруг я не знаю какой то простой фишки а в монге она есть и мне похдходит - похоже что все норм, будем тестировать дальше)

Ммм. Ася Камски в твиттере говорит что AF это новый find и предлагает $filter. Но в этом случае критически важен порядок пайплайна в AF: 1) $match: name eq Z & items.size gte 10 2) $skip X 3) $limit Y 4) $filter items.size

то есть именно в 3.6 должно работать?

3.2+

https://docs.mongodb.com/manual/reference/operator/aggregation/filter/

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

executionTimeMills 0 ? это типо меньше милисекунды?

Ммм. Ася Камски в твиттере говорит что AF это новый find и предлагает $filter. Но в этом случае критически важен порядок пайплайна в AF: 1) $match: name eq Z & items.size gte 10 2) $skip X 3) $limit Y 4) $filter items.size

имеется ввиду filter в project применить?

имеется ввиду filter в project применить?

Да. Но критически важно это делать после skip и limit

Тогда трансформироваться будут только документы из «текущей страницы»

По ссылке твой пример в общем-то

executionTimeMills 0 ? это типо меньше милисекунды?

Да. Всего 1 документ и 3 юнита работы.

да вот в том то и проблема что как только я добавляю блок skip - то меня уже время выполнения не устраивает

Да. Всего 1 документ и 3 юнита работы.

Спасибо)

=)

да вот в том то и проблема что как только я добавляю блок skip - то меня уже время выполнения не устраивает

Значит ты делаешь это неверно

Покажи пайплайн

Очень желательно в gist.github.com

возвращайся тогда сюда: db.collection.aggregate([ {$match: some_criteria }, {$skip: skip_qty }, {$limit: limit_qty } {$project: { items: {$filter: { input: "$items" as: "item", cond: { do_some_cond_with_$$item } }}, project_all_need_fileds: 1 }} ]) https://docs.mongodb.com/manual/reference/operator/aggregation/filter/

кажется я раньше уже все это написал...

Покажи пайплайн

так, похоже по size индекса небыло сейчас еще потестирую)

db.getCollection('scores').aggregate([ {$match: {"grades.score": {$gte: 10}}}, {$skip: 21000}, {$limit: 10}, { $project: { grades: { $filter: { input: "$grades", as: "item", cond: { $gte: [ "$$item.score", 10 ] } } } } } ])

"executionTimeMillis" : 39,

без индексов

это датасет с оценками ресторанов

scores.count() 25360

во первых спасибо

Это пахнет началом цикла статей где-нибудь)

во вторых очень здорово про addFields я чет не догадался

с индексами да это я накосячил

вроде сейчас все работает как надо)

Тьфу,.

Короче, я тям уже три раза ошибся

Короче, если не делать условия по borough, то в этом случае монга для skip/limit будет делать FETCH всех документов которые попали в условие

Хм. Хотя оно и так делает FETCH, даже если и сортировка есть и в условии нет вложенных документов

Пойду ещё кофеином закинусь

https://docs.mongodb.com/manual/reference/method/cursor.skip/#pagination-example

Но вообще такие оптимизации нужны если будет очень больно на очень больших объёмах

ERROR: S client not available

Там аккурат MDBLocal в мюнхене, где Ася Камски (из монги, ведёт http://www.kamsky.org/stupid-tricks-with-mongodb и http://www.askasya.com) сейчас рассказывает про AF. Жаль трансляции нет :(

В недрах mongodb.com есть раздел со старыми кейноутами. Например https://www.mongodb.com/presentations/diagnostics-and-debugging-3-0-the-return-of-sherlock-holmes. Можно даже сказать что благодоря её выступленям, меня потянуло в глубокое копание в монге. Она очень клёвая!

В недрах mongodb.com есть раздел со старыми кейноутами. Например https://www.mongodb.com/presentations/diagnostics-and-debugging-3-0-the-return-of-sherlock-holmes. Можно даже сказать что благодоря её выступленям, меня потянуло в глубокое копание в монге. Она очень клёвая!

Спасибо, очень интересно!

О. Слайды есть https://github.com/asya999/mdbw17

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

где то надо кэш почистить?

Реплика сет или standalone?

2018-04-12T15:35:59.293+0000 E QUERY [conn5] Plan executor error during find command: FAILURE, stats: { stage: "PROJECTION", nReturned: 0, executionTimeMillisEstimate: 20, works: 4828, advanced: 0, needTime: 4827, needYield: 0, saveState: 37, restoreState: 37, isEOF: 0, invalidates: 0, transformBy: { created: 1, description: 1, img: 1, image: 1, name: 1, owner: 1, updated: 1, users: 1, views: 1, likes: 1, reference: 1 }, inputStage: { stage: "SORT", nReturned: 0, executionTimeMillisEstimate: 20, works: 4828, advanced: 0, needTime: 4827, needYield: 0, saveState: 37, restoreState: 37, isEOF: 0, invalidates: 0, sortPattern: { views: -1 }, memUsage: 33568596, memLimit: 33554432, inputStage: { stage: "SORT_KEY_GENERATOR", nReturned: 0, executionTimeMillisEstimate: 10, works: 4827, advanced: 0, needTime: 2, needYield: 0, saveState: 37, restoreState: 37, isEOF: 0, invalidates: 0, inputStage: { stage: "COLLSCAN", filter: { $and: [] }, nReturned: 4825, executionTimeMillisEstimate: 0, works: 4826, advanced: 4825, needTime: 1, needYield: 0, saveState: 37, restoreState: 37, isEOF: 0, invalidates: 0, direction: "forward", docsExamined: 4825 } } } }

2018-04-12T15:35:59.293+0000 E QUERY [conn5] Plan executor error during find command: FAILURE, stats: { stage: "PROJECTION", nReturned: 0, executionTimeMillisEstimate: 20, works: 4828, advanced: 0, needTime: 4827, needYield: 0, saveState: 37, restoreState: 37, isEOF: 0, invalidates: 0, transformBy: { created: 1, description: 1, img: 1, image: 1, name: 1, owner: 1, updated: 1, users: 1, views: 1, likes: 1, reference: 1 }, inputStage: { stage: "SORT", nReturned: 0, executionTimeMillisEstimate: 20, works: 4828, advanced: 0, needTime: 4827, needYield: 0, saveState: 37, restoreState: 37, isEOF: 0, invalidates: 0, sortPattern: { views: -1 }, memUsage: 33568596, memLimit: 33554432, inputStage: { stage: "SORT_KEY_GENERATOR", nReturned: 0, executionTimeMillisEstimate: 10, works: 4827, advanced: 0, needTime: 2, needYield: 0, saveState: 37, restoreState: 37, isEOF: 0, invalidates: 0, inputStage: { stage: "COLLSCAN", filter: { $and: [] }, nReturned: 4825, executionTimeMillisEstimate: 0, works: 4826, advanced: 4825, needTime: 1, needYield: 0, saveState: 37, restoreState: 37, isEOF: 0, invalidates: 0, direction: "forward", docsExamined: 4825 } } } }

memUsage: 33568596, memLimit: 33554432 памяти для сортировки не хватило

спасибо

Если вы из РФ, рекомендую заранее озаботится вариантом обхода блокировки.

❗️Суд постановил заблокировать телеграм.

да затрахаюццо блокировать))))

Если вы из РФ, рекомендую заранее озаботится вариантом обхода блокировки.

@TgProxyBot

попадали все прокси уже

И @socks5_bot

а этот живой @TgProxyBot

И @socks5_bot

Хз. Я попробовал через него. Ничего не вышло

Насколько я понимаю сейчас боты упираются в лимиты, плюс везде наплыв из-за публикаций в сми

а этот живой @TgProxyBot

Уже нет.

Одна машина не выдерживает.

можно ссылку на мускул чатик?

можно ссылку на мускул чатик?

@mysql_db

thx

Ребят, привет. Подскажите а юзает кто монгу в big data ? Поделитесь впечатлениями

а что вы подразумеваете под бигдата? ну т.е какие объемы?

больше 1 петабайта

для хранения норм, но галвнео планирвоать доабвление новых шардов примерно за полгода