thenno: У angru нормальный вариант, но я его не стал дублировать в своем ответе, просто привел ещё 2 примера как можно, тем более что 2-й считался чуть ли не официальным, а про 1-й вас могут спросить на собеседовании.
Вот сделал пример: https://play.golang.org/p/Xh009uAy-M
4 режима:
1 - те что есть только в левом массиве
2 - те что только в правом
3 - пересечение, то что вам нужно
4 - это те что в пересечение не попали
формируется за 1 проход, будет работать быстрее чем ваш квадратный перебор.
Можно при "отрисовке" формировать пусть и прикреплять к комменту (т.к. все числа на руках)
Так же вместо массивов можно хранить все словарями, где ключ - это ид комментария (либо сделать ручную нумерацию n0, n1, n2... в пределах коммента):
db.post.update({}, {$set: {'comment.c0.c2.c4': {text: '...'}}})
Это позволит удалять комменты. Вариантов много, у всех плюсы, минусы.
Дмитрий Лабутин: Если найдете, бросте ссылку, я сходу не нашел. Это теория, монгос перепраляет запрос 2 путями: целенаправленный (один или несколько нод), либо на все ноды. Про модификацию запроса ничего не сказано, т.е. в худшем случае запрос полетит на все ноды, в лучшем - монгос переберет каждый элемент массива, составит список нод, и отправит всем копию этого запроса - т.е. каждая нода* будет работать с полным списком товара.
Быстрее будет провести эксперимент, сделать запрос и посмотреть что explain выдаст.
Ещё точечно будет если вы будете делать запрос $lte + $gte, т.е. перед запросом определять диапазон товаров (или несколько диапазонов), а при получении списка выкидывать лишние, но это геморно.
> хотелось бы количество затрагиваемых шардов уменьшить
по идее mongos не должен ваш запрос ($in) разрывать на части и отправлять точечно по шардам, поэтому при любом индексе запрос полетит на все шарды. Точечно будет если вы вручную сделаете findOne на каждый товар, но так (скорее всего) будет медленее.
> хотелось бы количество затрагиваемых шардов уменьшить
для этого можно попробовать, как вы написали, compound index (бренд, артикул), тогда одно-брендовые чанки будут ближе к друг другу.
А если нужно уж совсем точно, то можете просто для каждого прайса сделать свою коллекцию.
Данных навскикду 15-30Гб, и шардинг не нужен. Если будет чтения не хватать, то можно обычную реплику для балансинга чтения, либо самодельный шардинг (как это сделали в Яндекс диске) - разные прайсы на разные сервера.
Я бы на вашем месте уже что-нибудь попробовал и замерил скорость, какая у вас нагрузка планируется, может вам шардинг и не нужен?
