Ceci peut ne pas complètement répondre à votre question, cependant après avoir passé d'innombrables heures à régler la performance d'une grande application de météore, j'ai pensé partager certaines des choses que j'ai apprises. Dans Meteor, lorsque vous définissez une publication, vous configurez une requête réactive qui continue de transmettre des données aux clients abonnés lorsque les modifications apportées aux données mongo sous-jacentes entraînent une modification du résultat de la requête. En d'autres termes, il configure une requête qui transmettra continuellement les données aux clients lorsque les données sont insérées, mises à jour ou supprimées. Le mécanisme par lequel il le fait est en créant un observer sur la requête. Lorsqu'un observer est initialisé (par exemple, lorsque la publication est souscrite à), il interroge mongodb pour l'envoi de l'ensemble de données initial, puis utilise l'oplog pour détecter les changements à venir. Heureusement, meteor est capable de réutiliser un observateur existant pour un nouvel abonnement si la requête concerne la même collection, les mêmes sélecteurs et les mêmes options. Cela signifie que vous pouvez créer des centaines d'abonnements pour de nombreuses publications différentes, mais si vous utilisez la même collection et utilisez les mêmes sélecteurs de requête, vous n'avez en réalité que 1 observe en cours de lecture. Pour plus de détails, je recommande fortement de lire this article de kadira.io (à partir de laquelle j'ai acquis l'information que j'ai utilisée dans cette réponse). En plus de cela, Meteor est également capable de gérer plusieurs publications en publiant le même document, et quand cela se produit, les documents seront fusionnés en un seul. Voir this pour plus de détails. Enfin, grâce au composant MergeBox de Meteor, les données envoyées sur le réseau de toutes vos abonnements seront minimisées en gardant une trace des données modifiées par rapport à celles déjà présentes sur le client. Par conséquent, dans votre exemple spécifique, il semble que vous exécuterez plusieurs abonnements différents sur la même requête (puisque vous essayez simplement de dénormaliser vos données) et l'ensemble de données. En raison de toutes les optimisations que j'ai décrites ci-dessus, je suppose que vous ne serez pas en proie à des problèmes de performance en adoptant cette approche.
J'ai fait des choses similaires dans l'une de mes applications et je n'ai jamais eu de problème.