Есть несколько коллекций с более менее похожими данными ну так получилось. Можно ли как-то сделать запрос сразу к двум коллекциям? Например отсортировать по количеству чего-нибудь. Опыт работы с монго небольшой все что нашел это только запрос к одной коллекции.

По моим данным годичной давности запрос к 2-м коллекциям был невозможен.
Если за это время ничего не изменилось, то…

Почему бы не объединить коллекции в одну?

С другой стороны, можно попробовать map/reduce для каждой коллекции с указанием одинакового имени коллекции в out секции.
После сбора информации использовать это имя временной коллекции в конечном запросе.

Lexander
Почему бы не объединить коллекции в одну?

Хороший совет.
Даже если объекты неможно разные, можно их объединять в одну коллекцию и делать запросы по общим полям (это очень классное преимущество schemaless-design).
Например, если у вас объекты типа “Книга” и “Журнал”, можно смело объединять.

Интересно, для чего в монго предусмотрена возможность создания множества коллекций, если запросы так ограничены?
Напрашивается оправдание, что это пока ещё молодая разработка и всё несколько сыро…

Кстати, map/reduce обвиняют в некоторой тормознутости, по сравнению с обычным поиском - насколько это соответствует современному положению дел и где их можно оптимизировать?

Ну в данном случае есть например коллекции “приходная накладная”, “расходный кассовый ордер” и тд. Общего у них тока дата. Объединять их в одну коллекцию совсем не хочется. Но есть отчеты разные где фигурируют документы из этих двух коллекций вместе и их нужно отсортировать по дате допустим. Например акт сверки. Вот и встал вопрос или как то с помощью монго это сделать все таки или все это получать в питон им этот большой массив как то сортировать и выдавать в нужном виде что не удобно.

blessmaster
Кстати, map/reduce обвиняют в некоторой тормознутости, по сравнению с обычным поиском - насколько это соответствует современному положению дел и где их можно оптимизировать?

map/reduce тормознутый, потому что являет собой выполнение JavaScript кода. Оптимизация либо JS-кода либо как то реформировать запросы, тут, наверное, нельзя что-то общее посоветовать, все зависит от конкретного случая.

У меня в одном из проектов все данные (разные документы, пользователи, настройки пользователей) были в одной колекции - очень удобно. Отдельные колекции использовались для кеширования, хранения истории, и пр. вспомогательных вещей.

blessmaster
Интересно, для чего в монго предусмотрена возможность создания множества коллекций, если запросы так ограничены?
Напрашивается оправдание, что это пока ещё молодая разработка и всё несколько сыро…

Возможность != необходимость.
Вы просто пытались применить подход реляционных БД к объектным.
Размещение в одной коллекции нескольких объектов способствует, в конечном итоге, уменьшению дополнительных обращений к дисковой подсистеме - самой медленной среди прочих.

blessmaster
Кстати, map/reduce обвиняют в некоторой тормознутости, по сравнению с обычным поиском - насколько это соответствует современному положению дел и где их можно оптимизировать?

Обвиняющих для начала стоит спросить зачем они используют этот инструмент и с чем сравнивают.

map/reduce реализует сложную, изменяющуюся (иногда - часто) бизнес-логику и соответствует хранимым процедурам с несколькими сложными запросами в реляционных СУБД.
Аналогичные возможности в реляционных СУБД реализованы с помощью C# (MS SQL Server) или Java (Oracle).
По сравнению с TSQL и PL/SQL, соответственно,- это те еще тормоза.

Но, раз их используют, значит есть у них преимущество по сравнению с встроенными языками.
В первую очередь, это скорость разработки и поддержки.

Поэтому, в дополнение к возможности реализовать сложную бизнес-логику, скорости map/reduce вполне достаточно для ее задач.

ЗЫ
Если большинство запросов реализовано с помощью map/reduce, значит плохо продумана структура БД.
В вашем случае, если было заранее известно связанности данных 2-х коллекций и необходимости выбирать данные одновременно из обеих, нельзя было разделять данные на 2 коллекции.

Пасибо общее направление примерно понятно). Придется действительно все собирать в одну коллекцию по возможности.

Lexander
Возможность != необходимость

Какбэ необходимость требует по зависимости возможность.

Lexander
Вы просто пытались применить подход реляционных БД к объектным.

Какое отношение это имеет к реляционности как качеству БД?

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

Каким образом? Что технически ускоряет? Я пока вижу только один фактор - данные одного типа более разрежены, что при чтении требует обращение к большему числу дисковых страниц (вероятность найти соседние записи на одной дисковой странице - ниже).

Lexander
Обвиняющих для начала стоит спросить зачем они используют этот инструмент и с чем сравнивают

1. Тестирование производительности - вполне удовлетворительная цель. О рекомендуемых случаях применения, я бы не против узнать. В данном топике рассматривается один из случаев, когда рекомендуется попробовать. Также стоит учитывать, что map/reduce несколько специфичный инструмент.
2. С чем сравнивают - я вроде бы описал. Сравнение имеет смысл в равных условиях/функциональности. Для описанной топикстартером задачи это определение справедливо.

Lexander
соответствует хранимым процедурам с несколькими сложными запросами

Использование map/reduce автоматически подразумевает выполнение дополнительных запросов?
Описанная в топике задача этого не предполагает, хотя согласен, что в предыдущем сообщении я задал более обобщённое условие в своём вопросе.

Lexander
скорости map/reduce вполне достаточно для ее задач

Собственно, весь вопрос был о том, насколько медленнее и критичнее в реальных “боевых условиях”, поскольку JavaScript, если я верно понял то, что прочитал о Монго, - блокирующая часть для всей базы, в отличие от хранимых процедур и вероятно, от реализаций map/reduce в других базах, поправьте, если ошибаюсь.

Lexander
если было заранее известно

Как, говорится, “знал бы где упадёшь, - соломки б подстелил”.