Имеется 2 коллекции: Users и Comments. Users имеет N документов, а Comments вложена в Users (то есть Users = {..., [Comments], ...} - массив комментариев) и имеет в среднем M документов для каждого документа Users. У Comments есть индексированное поле Views.
Требуется найти все комментарии, имеющие, скажем, 200 просмотров.
Сложность для каждого из 2-х подходов:
1.Comments встроен в Users, как и описано выше, тогда сложность будет N * LogM. То есть нужно просмотреть каждого пользователя - N итераций, а затем пробежаться по дереву Views - LogM
2.Comments существует автономно и его док-ы имеют ссылку - ObjectID на док. Users (классический one-to-many). Тогда Comments будет иметь N * M док-ов, а сложность будет Log( N * M ). Вывод: если требуется фильтровать по полям вложенных док-ов, то стоит реализовать коллекции не как вложенные, а в виде отдельной коллекции, как в РБД.
Правильно ли я оценил сложность ? Если да, то какие юзкейсы у массивов вложенных документов перед РБД подходом, описанным в пункте 2?
Вывод: если требуется фильтровать по полям вложенных док-ов, то стоит реализовать коллекции не как вложенные, а в виде отдельной коллекции, как в РБД.
Чаще да. Так же бывают такие варианты как пометить определенных пользователей чтобы всех не перебирать, либо дублировать "отличительные" комментарии в отдельную коллекцию или наоборот дублировать в "документ пользователя", в nosql оно гибче.
N * LogM. То есть нужно просмотреть каждого пользователя - N итераций
Чтобы не делать N итераций используют индекс, чтобы получить нужные документы без переборов (а переборы задействуют "диск").
Так же тут нужно смотреть на то как вы будете изменять поле "количество просмотров", если комментарии находятся в отдельной коллекции - то это будет проще и быстрее.
Comments будет иметь N * M док-ов, а сложность будет Log( N * M ).
Откуда у вас тут Log? Чтобы получить "все комментарии имеющие 200 просмотров.", коллекцию пользователей трогать вообще не обязательно.
Чтобы не делать N итераций используют индекс, чтобы получить нужные документы без переборов (а переборы задействуют "диск").
Ну так, если в коллекции Users массив коллекций Comments, всё равно равно придётся для каждого док-та Users, а это N, искать в кол-во просмотров, а это M для каждого док-та Users, которое в Comments индексировано и займёт не M, а LogM. Не совсем понимаю при чём здесь индекс у Users, там же своё дерево(по ObjectID или любому другому полю) у Comments для каждого документа пользователя или нет ?
Откуда у вас тут Log? Чтобы получить "все комментарии имеющие 200 просмотров.", коллекцию пользователей трогать вообще не обязательно.
Users и не трогается :). N * M потому что комментарии не по массивам в Users распределены, а в одном месте, в Comments. То есть было N док-ов в Users и в каждом по M комментариев, а теперь всё в одном месте.
