Но для update такой вариант конечно не сработает + в update я еще не могу применить sort.
похоже что задача не имеет решения средствами mongo без javascript, но шанс остается.
Тут весь вопрос не в поиске данных а в хранении кол-ва итемов в каждой категории(причем с учетом детей всех уровней ниже)
задача - вывести на какой-то страничке список категорий n уровня - напротив каждой категории - кол-во итемов, при добавлении итемов - увеличивать счетчики в категориях рекурсивно, при удалении соответственно... но если при удалении/добавлении можно сделать форк процесса и продолжить изменять кол-во в фоне, то при открытии страницы нужно за минимальное время вывести список категорий(регионов) с кол-вом итемов по каждой
>2. Если говорить про SQL можно делать выборки вида
по поводу запроса "на лету", это не есть хорошо, т.к. итемов у меня порядка 4х млн, и предполагается раз в 5-6 больше :)
>3. Так ли Вам нужна возможность бесконечной вложенности категории и региона? Неужели десятка уровней не хватит?
Сейчас вложенность Региона - 4 уровня, Категорий - 11, по Регионам вроде не должно быть больше уровней, но по Категориям может и до 13 уйти....
>я бы шардировал таблицу items по полям category_id и region_id
Что вы подразумеваете под словом "шардировать"?
>5. Для хранения счетчиков можно тупо взять redis.
Я сам очень сильно склоняюсь к redis, но не могу разобраться как сделать несколько ключей, либо как организовать структуру данных в redis чтобы не было миллиардов строк и не деградировала скорость выборки...
>память с тех пор подешевела.
память и процы не проблема в наше время можно выделить до 100ГБ оперативки без проблем...
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Но для update такой вариант конечно не сработает + в update я еще не могу применить sort.
похоже что задача не имеет решения средствами mongo без javascript, но шанс остается.