Мне почему-то кажется, что правильнее y gt, а потом уже x in. И индекс также построить.

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

Первый in ломает возможность задействовать double buffer для выборки по gt

Ну он тогда выстраивает indexBounds по одному ID.

[1,1], потом y

Мне почему-то кажется, что правильнее y gt, а потом уже x in. И индекс также построить.

Я уже пробовал, особо ничего не поменялось. Сейчас ещё раз сделаю.

Дело в том, что это на проде.

А просто на локале попробовать сложно?

На локале все летает.

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

А у меня места на компе нет чтобы бэкап скачать.

Достаточно посмотреть explain

Достаточно посмотреть explain

Погоди, мы опять про разные вещи.

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

Возможно вместо compound до этого использовалась интерсекция.

Ну, вот надо смотреть. Можно разные планы...

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

А сейчас это как гадание на кофейной гуще, потому что зафорсить индекс нельзя на агрегацию.

Приходится исхищряться.

Мне почему-то кажется, что правильнее y gt, а потом уже x in. И индекс также построить.

Если у меня есть записи пользователей и timestamp, то лучше использовать timestamp первым?

Т.е. я хочу получить записи определённых пользователей по timestamp'у выше, чем я задаю.

Поэтому у меня два индекса -1, т.к. кроме timestamp'a чаще пишут новые пользователи. Они все в начале по сортировке.

Запрос то какой? Условие

Ну я пытаюсь получить все сообщения определённых пользователей за последние X дней.

Следовательно есть $in на пользователей и $gte на timestamp.

При этом я знаю, что чаще всего в эту выборку попадают пользователи с большим ID.

И все данные (timestamp) лежат "в хвосте" (последние).

Т.е. я не запрашиваю данные за прошлый год, мне нужные последние X дней.

Вот я сейчас сделал id, timestamp и timestamp, id. С timestamp, id результаты хуже, чем с id, timestamp.

Есть ли какое-то логическое объяснение этому кроме странностей агрегаций?

Порядок сортировки не указан

Почитай про составные индексы и сортировку. В доке кажется есть ответ на твой вопрос.

Плюс тренируйся на find, match stage в 99% работает идентично

Мне почему-то кажется, что правильнее y gt, а потом уже x in. И индекс также построить.

Если мне память не изменяет планировщик такие вещи уже давно оптимизирует сам

Нашествие?

интересно откуда :)

отсюда http://netology.ru/blog/prg-tg?utm_source=forwebdev&utm_medium=announcement&utm_campaign=bolshaya-kollektsiya-iz-133-kanalov-i-chatov&stop=1

Всем привет:)

А напишите, вновь прибывшие, кто как MongoDB использует, если не сложно.:)

привет

как только не используем, но по большей части как вспомогательный инструмент. Я пилю всякую аналитику, макеты рабочие делаю и т.д. Сертификаты кто получал их?

как только не используем, но по большей части как вспомогательный инструмент. Я пилю всякую аналитику, макеты рабочие делаю и т.д. Сертификаты кто получал их?

Аналитика на aggregation framework?

я курсы DBA и Node.js + монга на 100% закрыл, но чет как-то забил на сертификацию

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

Аналитика на aggregation framework?

ну зависит от задачи, где-то и find достаточно, а где-то и с map-reduce затыкается все

коллекцию вертеть с 7млн документов - то еще удовольствие

А еще интересно кто из каких городов:)

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

А еще интересно кто из каких городов:)

Это ко всем относится:)

мск

коллекцию вертеть с 7млн документов - то еще удовольствие

7 лямов - это же маловато.

Нет?

А еще интересно кто из каких городов:)

Я с Питера, если что:)

Нет?

Да:)

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

У вас индексы не очень, похоже:) Иначе и редисом можно пользоваться

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

Я за миллиард кручу.

На одном сервере ещё, даже без кластера.

Эх, а ведь скоро нужно будет шарды делать.

Всё никак руки не дойдут.

Я думаю, основные проблемы начинаются как раз на этом этапе.

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

А как ты это делаешь?..

Это же очень простая операция.

А напишите, вновь прибывшие, кто как MongoDB использует, если не сложно.:)

в течение месяца начну впервые знакомиться с БД и mongodb в частности, надеюсь тут не будут сильно карать меня за нуб вопросы)

Может быть ты ищешь не по индексу? Тогда полноценное сканирование коллекции может хорошо повесить процессор.

Да и диск вместе с ним иногда.

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

var col = "transactions_original"; var bulk = db.getCollection(col).initializeUnorderedBulkOp(); var i = 0; var pipe = [{$match: {}}]; db.getCollection(col) .aggregate(pipe, {allowDiskUse: true}) .forEach(function(item) { var a = item.tr_datetime .split(" ")[1] .split(":"); var seconds = (+a[0]) * 60 * 60 + (+a[1]) * 60 + (+a[2]); bulk.find({ "_id" : item._id }) .updateOne( { $push: { "train_set.input" : { $each: [ item.customer_id/1000000000, item.tr_datetime.split(" ")[0]/1000, seconds/100000, item.mcc_code/10000, item.tr_type/10000, (item.amount+145984525.17)/300000000 ] } } } ); }); bulk.execute();

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

Подозреваю, вы грузите всю коллекцию в память, а потом меняете поля. А ведь еще можно и в копию коллекции писать...

var col = "transactions_original"; var bulk = db.getCollection(col).initializeUnorderedBulkOp(); var i = 0; var pipe = [{$match: {}}]; db.getCollection(col) .aggregate(pipe, {allowDiskUse: true}) .forEach(function(item) { var a = item.tr_datetime .split(" ")[1] .split(":"); var seconds = (+a[0]) * 60 * 60 + (+a[1]) * 60 + (+a[2]); bulk.find({ "_id" : item._id }) .updateOne( { $push: { "train_set.input" : { $each: [ item.customer_id/1000000000, item.tr_datetime.split(" ")[0]/1000, seconds/100000, item.mcc_code/10000, item.tr_type/10000, (item.amount+145984525.17)/300000000 ] } } } ); }); bulk.execute();

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

Я думаю, основные проблемы начинаются как раз на этом этапе.

Вы же помните, что каждая шарда должна быть репликасетом? :)

У нас на старой работе монга была как хранилище raw transaction для rtb / ssp /dsp

Вы же помните, что каждая шарда должна быть репликасетом? :)

Да, но я планировал первый кластер без реплики делать.

Или это ошибка?

Я разворачивал без реплики на локалках, вроде всё норм.

на новой, мы храним в монге все данные DRM в максимально денормализованном виде.

монго не рекомендует... а как бэкапить, например?

монго не рекомендует... а как бэкапить, например?

Хороший point. На данном этапе, я боюсь, ресов не хватит на всё. Хотя время ещё есть, может быть к тому моменту серверов будет больше.