600мб за 2 секунды это неплохой результат

@dd_bb попробовал агрегацию, в случае с тоталом по месяцам, сработало отлично, еще раз спасибо. сейчас мой другой mapReduce выдает выдает такой результат, т.е. у меня в один день собираются разные типы со всех заказов для одного дня + их тотал - в случае с агрегацией это решается несколькими stage $match + stage $group или есть вариант проще и я что-то упускаю, или это действительно нестадартный usecase и лучше в таком случае остаться с mapReduce ? Сорри за наглость, это мой последний вопрос, дальше буду рыть сам { "type_1": 1, "total": 1, "date": "2020-04-12T00:00:00.000Z" }, { "type_1": 13, "type_2": 83, "type_3": 70, "total": 166, "date": "2020-04-11T00:00:00.000Z" }, { "date": "2020-04-10T00:00:00.000Z" },

@dd_bb попробовал агрегацию, в случае с тоталом по месяцам, сработало отлично, еще раз спасибо. сейчас мой другой mapReduce выдает выдает такой результат, т.е. у меня в один день собираются разные типы со всех заказов для одного дня + их тотал - в случае с агрегацией это решается несколькими stage $match + stage $group или есть вариант проще и я что-то упускаю, или это действительно нестадартный usecase и лучше в таком случае остаться с mapReduce ? Сорри за наглость, это мой последний вопрос, дальше буду рыть сам { "type_1": 1, "total": 1, "date": "2020-04-12T00:00:00.000Z" }, { "type_1": 13, "type_2": 83, "type_3": 70, "total": 166, "date": "2020-04-11T00:00:00.000Z" }, { "date": "2020-04-10T00:00:00.000Z" },

чтоб оно делало сразу пары types: [[type, subtotal], … ]

Всем привет. У кого-нибудь есть предположения, почему ObjectId.toString() возвращает всё равно ObjectId? db.getCollection("users").aggregate([ {$project : {idstr : "$_id".toString()}} ]);

Вы вызываете метод toString на строке "$_id" на клиенте, а не в монге. Трансформируйте результаты вызова aggregate()

А, в этом случае скорее всего никак. А почему именно строка нужна?

Это будут значения для фильтра, который имеет тип String, т.к. с ObjectId там какие-то проблемы. Думал, что будет проще к строке привести и работать с ней

2x2 это какая топология? В цифрах «хорошо/плохо» как выражается? 500 в секунду это постоянная нагрузка или пиковая? В целом, это зависит от того какое условие для поиска документов для обновления, сколько в итоге надо обновить документов и как. 7 млн документов по <500кб это уже до 4тб без учёта того насколько хорошо документы сжимаются. <500кб по 500 раз в секунду это до ~~250мб/с, без учёта компрессии и обновления индексов в одну сторону. Будет зависеть от множества факторов, но в первую очередь от ширины шины, пропускной способности и задержек хранилища под тем партерном нагрузили который выйдет. Если будут обновляться примерно один и те-же документы на чтение нагрузка будет меньше. Но «максимальный размер» не очень хорошая метрика, которая позволит прикинуть не очень реалистичные цифры «верхнего предела». лучше ориентироваться на «медианный» размер. Самый надёжный способ — сделать тестовый стол и на нём проверить на реальных данных или на данных максимально приближенных к реальным

explain(executionStats:1) на index scan что показывает?

а что в документах и какая логика обновления? 500 документов одинаковых или разных?

куда-то на gist.github.com залейте

это на три порядка больше чем 500 документов :)

а что за вложенные циферки?

и её надо обновлять у какого количества документов?

500 раз в секунду?

ну то есть как есть Х документов и есть 500 действий мне нужно совершить 500 дейтсвий над каждым документом (каждое действие - один конкретный документ)

30% документов 500 раз в секунду это в худшем случае 150х всего объёма данных, что в худшем случае эквивалентно 7кк*500кб*150 = 500Тб/сек

а что за 500 действий?

например, пользователь пробежал 100 метров

т.е. обновляется 1 документ в итоге?

https://gist.github.com/bespilotnayakartoshka/7b9a936dbb8aa6ed9bc24fe53f73cbef

^ а это тогда что такое?

а что такое «предварительный селект»?

так, это уже другая задача :)

ну, например активность у меня есть активность по дням { id: 1, activnots: [ { date: 2019-01-01, metrika1: 100, metrika2: 300 }

activnots какое количество дней содержит?

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