Комментарии 3
После прочтения сразу в голове возник вопрос: а зачем, собственно, был весь этот алгоритм, если вы и сами признаёте, что кастомный id решил бы эту задачу лучше? Почему не было использовано это решение?
Почему вообще MongoDB в таком необычном сценарии оказалась? Если работа с большими коллекциями, то не рассматривались ли альтернативы?
Ну, во первых, не хотелось отказываться от встроенного по умолчанию в систему идентификатора. Во-вторых - понимание приходит с опытом, изначально не было задачи осуществлять подобные выборки и накопилось большое количество баз. Переиндексировать их - можно, конечно, но мне показалось, что поиск алгоритма - хорошее решение, которое потребует меньше затрат ресурсов.
По поводу альтернатив - у меня было желание, чтобы СУБД была совместима с системой аналитики Knime. А в Knime, кроме Mongo - мало альтернатив... PostgreSQL - ну, она, как бы реляционная, не совсем подходит для слабоструктурированных данных.
Оптимизация выборок в больших коллекциях MongoDB