Можно ли использовать композитный материал Meteor для десятков подписчиков?

Question

В настоящее время наша система не полностью нормализована, и мы используем meteor-publish-composite для получения нормализованных данных в mongodb. Некоторые модели имеют очень мало зависимостей, но у других есть массивы объектов (т. Е. Поддокументы) с несколькими внешними ключами, на которые мы подписываемся при выборе каждой модели.

Примером может служить Post, содержащий список поддокументов Comment, где каждый комментарий имеет поле userId.

Вопрос в том, что, хотя я знаю, что было бы быстрее использовать сборщики и обновить коллекцию с денормализацией данных, как Meteor обрабатывает несколько подписчиков в одной коллекции?

Сот подписей в одной коллекции влияет на скорость приложения (значительно)? Что насчет тысячи? и т. д.

Answer 1

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

В Meteor, когда вы определяете публикацию, вы настраиваете реактивный запрос, который продолжает выдавать данные подписчикам, когда изменения в базовых данных mongo приводят к изменению результата запроса. Другими словами, он устанавливает запрос, который будет постоянно передавать данные клиентам, когда данные будут вставлены, обновлены или удалены. Механизм, с помощью которого это делается, заключается в создании observer по запросу.

Когда инициализируется observer (например, когда публикация подписана), он будет запрашивать mongodb для первоначального набора данных для отправки вниз, а затем использовать oplog для обнаружения изменений в будущем. К счастью, метеорит способен повторно использовать существующего наблюдателя для новой подписки, если запрос предназначен для одной коллекции, тех же селекторов и тех же опций.

Это означает, что вы можете создавать сотни подписчиков для разных публикаций, но если они попадают в одну и ту же коллекцию и используют одни и те же селектора запросов, то у вас фактически есть только 1 observe. Для получения дополнительной информации я настоятельно рекомендую прочитать this article от kadira.io (из которого я приобрел информацию, которую я использовал в этом ответе).

В дополнение к этому, Meteor также имеет дело с несколькими публикациями, публикующими один и тот же документ, и когда это произойдет, документы будут объединены в один. См. this для более подробной информации.

Наконец, из-за компонента Meteor MergeBox он минимизирует данные, отправляемые по кабелю через все ваши подписки, отслеживая, какие данные были изменены в сравнении с тем, что уже находится на клиенте.

Поэтому, в вашем конкретном примере, похоже, что вы будете запускать несколько разных подписей на эффективный один и тот же запрос (поскольку вы просто пытаетесь де-нормализовать свои данные) и набор данных. Из-за всех оптимизаций, которые я описал выше, я бы предположил, что вы не будете страдать от проблем с производительностью, применяя этот подход.

Я сделал аналогичные вещи в одном из моих приложений и никогда не имел проблемы.