Может я не правильно понял документацию - The following operation returns documents in the bios collection where the array field contribs contains the element "UNIX": db.bios.find( { contribs: "UNIX" } )

Да я читал про $unwind и $group но как я понимаю их нужно зделать уже после выборки, иначе они будут работать со всей колекцией, а это как то не очень :)

Вот и возникает вопрос - как засунуть в агрегацию кучу find по циклу )))

Перед $unwind и $group

прочитайте про $match - это как правило первая стадия агрегации и она выполняет ваш поиск по все объемы данных

да выполняет я уже и индекс завел по массиву, но у меня в начальном запросе тоже массив и мне нужнен $match для всех элементов массива - и я не знаю как и возможно ли вообще циклом передать элементы в $match перед $unwind и $group

я правильно понимаю что у вас есть список идшников, по нему вы ищете все документы у который в поле array встречается хотя бы один идшник?

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

вот и получается что мой список может совпадать с первымна 200 айдишников со вторым на 2 ... и т.д

чет сходу не могу придумать

$match и там $elemMatch

можно делать $elemMatch: {'field': {'$in': [....]}}

если запрос делается редко можно $out записывать в временную коллекцию промежуточный результат потом аггрегацию делать уже.

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

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

да но не есть документы та где нет совпадений вообще

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

ну и как часто оно должно выполняться

Я недавно взялся за Монго и может не знаю до конца что делаю но find({ array: 3764 } выдает по индексу два документа из 100 где есть элемент массива 3764 или это совпадение и надо использовать $elemMatch

доков 40 000, средний размер массива 20 000 количество в запросе тоже тисяч 15

запросов примерно 20-30 в день

можно сделать в лоб отправить 15к запросов и уже на стороне приложения обработать 15к массивов - но как то это не очень (((

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

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

вы строите систему рекомендаций?

вроде того - они еще сами не знают что строят но есть монга ))) и такая вот задачка )))

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

Попробую перевести это на товары - есть склады со списками товаров (мои документы с масивом id товаров) мне на вход приходит список товаров и я должен сказать какие склады имеют самый похожый набор товаров в порядке убывания )))

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

а монга для этого ну очень неочень

Большое спасибо буду настаивать на переходе к РСУБД

Большое спасибо буду настаивать на переходе к РСУБД

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

Читал но тоже подумал что бестолку Монго все же не Хадуп)))

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

Да но думаю мне будет проще забрать их к себе и при необходимость распараллелить обработку чем делать это в Монге - если я все правильно прочитал то mr у неё однопоточный...?

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

Но зачем

У вас есть решение для Монго?

А то я уже морально настраиваюсь на посгрес))))

Разверните отношение в обратную сторону: храните в документе товара идентификатор склада

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

Так как размер документа ограничен 16мб

Во-вторых, ваша задача будет решатся простой группировкой выбранных товаров по складам. вместо перебора огромного массива товаров

Может я не понял идею? Если я буду хранить так, то за один запрос к товару я получу список складов на которых он находится... но я и сейчас его могу получить по одному товару но у меня список товаров - грубо говоря контейнер и мне нужно узнать 100 других контейнеров в которых наиболее похожие товары на мой контейнер...?

начинают нюансы вылезать :)

Похожесть у вас в чем измеряется?

Кроме контейнеров, есть ли ещё какие-то особенности?

В количестве совпадающих товаров внутри контейнера :)

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

Да похож:)))

Массивы примерно по 20 000 товаров

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

Точно)

Чего больше, товаров или контейнеров?

Пока что почти поровну но контейнеры будут расти а товары нет

Т.е в среднем на один товар приходится один контейнер?

Какое медианное число контейнеров на товар?

Нет в контейнере 25к товаров, есть 40к контейнеров и они будут добавляться, мне приходит контейнер на 25к товаров - нужно найти 100 самых похожих по товарам контейнера с моим.

Т.е. сейчас 40 тысяч наименований товаров, 40 тысяч контейнеров и примерно 1 млн связей «товар-контейнер»?

Нет сейчас 40 тысяч контейнеров в них по 25 тысяч товаров в каждом

Я ещё раз задам вопрос: на один товар, в среднем, сколько контейнеров приходится?

Т.е. в скольких контейнерах находится в среднем товар

Может быть как угодно - может только в 100 а может и 10 000

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

В целом, вам нужно найти такое направление отношений между товарами и контейнерами, в которых выборка будет максимально сокращатся.

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

На первый взгляд отношение «контейнер -> товары» получается неэффективным: даже если в контейнере совпал один товар, нам придётся сделать пересечение всего множества из 25к элементов. Моя гипотеза состоит в том, что отношние «товар -> контейнеры» будет более эффективным, так как товар может быть в меньшем числе контейнеров, чем товаров в одном контейнере. Но это зависит от реального распредления

У вас уже данные есть, составьте гистограмму

Но в целом, ваша задача решается через $setIntersection + $size

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

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

insertOne vs db.collection.insertMany при каких количествах заметна разница?

Есть данные: {'a': 1, 'date': DateTime('.. 11:10')} {'a': 0, 'date': DateTime('.. 11:11')} {'a': 0, 'date': DateTime('.. 11:13')} {'a': 1, 'date': DateTime('.. 11:14')} {'a': 0, 'date': DateTime('.. 11:14')} {'a': 0, 'date': DateTime('.. 11:14')} {'a': 0, 'date': DateTime('.. 11:15')} Результат после обработки: {'a': 1, 'date': DateTime('.. 11:10')} {'a': 0, 'date': DateTime('.. 11:11')} {'a': 1, 'date': DateTime('.. 11:14')} {'a': 0, 'date': DateTime('.. 11:14')} Это результат агрегаций? Как такое реализовывают?

Это можно реализовать на аккумуляторе и групировке с $max по date. Делаете счётчик ac, куда аккумулируете значения a. дальше делаете группировку по ac, указывая date: { $max: «$date»}

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

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

Хотел бы сравнить разницу date между a: 0 и a: 1 не выгружая все данные

я про {'a': 0, 'date': DateTime('.. 11:11')} {'a': 0, 'date': DateTime('.. 11:13')}

Это упрощённые данные, на самом деле ещё есть и другие поля

А какой физический смысл этих данных?

Выглядит как временной ряд описывающие изменение параметра

поле a это тип данных

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