Почему эта агрегация для вас является проблемой?

ее скорость проблема

Почему?

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

я имею ввиду запросы по агрегации

и не совсем понятна работы монги с памятью

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

Мне у сожалению все ещё не понятно почему время выполнения этой агрегации является проблемой

формируется дашборд, параметры могут быть любые запросов дашборд посылает 4

нужны данные в реальном времени

ждать 15-20 секунд это много

У вас есть несколько вариантов: 1) изменить схему и сделать её более подходящей к вашим выборкам 2) преагрегировать данные в отдельной коллекции при вставке 3) шардировать коллекцию, например по времени, чтоб за счёт горизонтального масштабирования увеличить доступную вычислительную мощность

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

Не очень понимаю почему

я привык к работе с реляционками и они отдают результат в 5 раз быстрее

применительно к агрегациям

при плоских данных

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

я привык к работе с реляционками и они отдают результат в 5 раз быстрее

Это некорректное сравнение

Это некорректное сравнение

согласен

Тогда зачем сравнивать?

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

железо одинаковое, я думаю больше тут работа с памятью

А почему монга?

наследие)

железо одинаковое, я думаю больше тут работа с памятью

Нет никакого волшебства. Фундаментально разница только в структурах данных

у вас данные хранятся в неподходящем для ваших выборок виде

Скорее всего у вас коллекция из множества маленьких событий

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

И очевидно что слабоструктурированный bson при прочих равных будет более затратным чем zero copy структуры

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

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

^ это направление на мой взгляд наиболее подходящее

Час это очень много, особенно если событий много

https://www.mongodb.com/blog/post/building-with-patterns-the-bucket-pattern

https://www.mongodb.com/blog/post/paging-with-the-bucket-pattern--part-1

https://www.mongodb.com/blog/post/paging-with-the-bucket-pattern--part-2

👍

привет. кто сталкивался с "развалившимися" индексами в монге? столкнулся что в какой-то момент времени индекс заточенный под специфический запрос перестал быть winning, и вместо него начал использоваться базовый индекс.

привет. кто сталкивался с "развалившимися" индексами в монге? столкнулся что в какой-то момент времени индекс заточенный под специфический запрос перестал быть winning, и вместо него начал использоваться базовый индекс.

Почему развалившийся? планировщик по какой-то причине решил что на тестовой выборке этот индекс эффективнее. Если вы хотите чтоб он выбрал другой индекс, укажите ему хинт

да. указал. и результат реально хуже.

Покажите explain

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

https://docs.mongodb.com/manual/core/query-plans/

Покажите explain

3к строк. как показать?

3к строк. как показать?

gist.github.com

gist.github.com

https://gist.github.com/Dr-klo/e21c124cf52185fd745c6fe28f325d62

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

https://gist.github.com/Dr-klo/e21c124cf52185fd745c6fe28f325d62

А какой индекс для этого запроса?

_id.T это уже очень плохо

Уверен что у вас в итоге есть ещё один индекс по _id.T

Ожидал что будет использоваться TimeTypeEventSigntype. Но если его хинтом бахнуть то запрос 2м выполняется вместо 30сек, эксплейн которого я скинул

Да. По _id.T там много индексов. Поскольку данные - банальные лог данные. И _id.T (время) много где используется

Это очень большая ошибка

Там исторически сложилось что айди составной (время. Айди устройства. Айди приложения. Айди айди компонента) Хотел бы переделать. Но аргументов убедить начальство не хватает

Ожидал что будет использоваться TimeTypeEventSigntype. Но если его хинтом бахнуть то запрос 2м выполняется вместо 30сек, эксплейн которого я скинул

А с hint на этот индекс explain(executionStats:1) что показывает?

Если с хинтом запрос выполняется 2 минуты вместо 30с, вероятно по этому планировщик этот индекс и не выбирает

Пару мин

Там исторически сложилось что айди составной (время. Айди устройства. Айди приложения. Айди айди компонента) Хотел бы переделать. Но аргументов убедить начальство не хватает

Ну если для вас размер индексов играет роль, то это вполне аргумент.

Но в целом, если это логи, то как и выше я вам рекомендуюрассмотреть bucket pattern

😊 они просто веник на 1тб воткнули в стойку

Веник?

Расширили дисковое пространство на шардах

Но в целом, если это логи, то как и выше я вам рекомендуюрассмотреть bucket pattern

👍 погуглю

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

@dd_bb https://gist.github.com/Dr-klo/a58065acf2de9dec2e392a82dc34a3f8

@dd_bb https://gist.github.com/Dr-klo/a58065acf2de9dec2e392a82dc34a3f8

"executionTimeMillis" : 15308.0, "totalKeysExamined" : 4579542.0, "totalDocsExamined" : 26778.0,

15с

На единственном шарде

На остальных шардах меньше 100мс

я буквально перед этим индекс перестроил

поэтому профит выше

{ "_id.T" : -1, "E" : 1, "Y" : 1 } и partial по _t

это хотфикс. проблему нужно концептуально решать

Подскажите пжл, не могу почему-то обновить расширение mongodb для PHP, стояло 1.5.2 версия, я обновил, обновилось до 1.6.1, обновляю так sudo apt update mongodb

собственно, пытаюсь поставить драйвер версии 1.6.0, но он требуется расширение версии 1.7, при этом до 1.7 не обновляется

Здравствуйте! Нужен совет). Использую MongoBD.Driver 2.10.2 для c#. Есть класс Card. Вопрос: можно ли создать индекс для поля Show в CardRepository, так чтобы индекс создавался в конструкторе CardRepository, при условии, что его нет? Например, если коллекция CARDS переименовалась или удалилась. Корректно ли так создавать индексы?

собственно, пытаюсь поставить драйвер версии 1.6.0, но он требуется расширение версии 1.7, при этом до 1.7 не обновляется

собствено, определил проблему, в оф. репозитории убунту еще нет 1.7.2 версии монги, потому не удалось обновиться, может кто знает какой-то более актуальный репозиторий?

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

Допустим, у меня есть счётчик посещений сайта, у меня есть документ с одним значением {'CountOfViews': x} . Могу ли я с помощью лишь одного запроса увеличить значение х на 1 пункт?

Допустим, у меня есть счётчик посещений сайта, у меня есть документ с одним значением {'CountOfViews': x} . Могу ли я с помощью лишь одного запроса увеличить значение х на 1 пункт?

Можешь конечно, оператор $inc в помощь, запрос типа update

В описании операторов пишут что будет, если поля не существует или если в нём не число