La réponse courte est que seules les nouvelles données soient envoyées sur le réseau. Voici
comment cela fonctionne.
Il y a trois parties importantes de la Meteor serveur de gérer
abonnements: la fonction publier, qui définit la logique de ce que
les données de l'abonnement; le Mongo pilote, qui regarde le
base de données pour les modifications; et la zone de fusion, qui regroupe l'ensemble de
client abonnements actifs et les envoie sur le réseau de l'
client.
Publier fonctions
Chaque fois qu'un Météore client s'abonne à une collection, le serveur exécute un
fonction publier. La publication de la fonction de travail est de comprendre l'ensemble
des documents que son client devrait avoir et envoyer chaque document de la propriété
dans la zone de fusion. Il s'exécute une fois pour chaque nouvel abonnement client. Vous
pouvez mettre n'importe quel code JavaScript que vous voulez dans la fonction publier, comme
arbitrairement complexes de contrôle d'accès en utilisant this.userId. Le publier
fonction envoie les données dans la zone de fusion en appelant this.added, this.changedet
this.removed. Voir la
plein de publier de la documentationpour
plus de détails.
La plupart de publier les fonctions n'ont pas à muck autour de bas-niveau avec le
added, changed et removed API. Si un publier la fonction renvoie une Mongo
curseur, le Météore serveur se connecte automatiquement à la sortie de la Mongo
pilote (insert, update, et removed de rappels à l'entrée de l'
fusion de zone (this.added, this.changed et this.removed). Il est assez soignée
que vous pouvez faire tous les contrôles d'autorisation à l'avant dans une fonction publier et
ensuite, connectez directement le pilote de base de données pour la fusion de la boîte sans que l'utilisateur n'
code de la route. Et quand autopublish est activée, même ce peu est
caché: le serveur établit automatiquement une requête pour tous les documents dans chaque
la collecte et les pousse à la fusion de la boîte.
D'autre part, vous n'êtes pas limité à la publication de requêtes de base de données.
Par exemple, vous pouvez écrire une fonction publier qui lit une position GPS
à partir d'un périphérique à l'intérieur d'un Meteor.setInterval, ou les sondages d'un héritage de l'API REST
à partir d'un autre service web. Dans ces cas, vous auriez émettent des modifications à la
fusion de la boîte en appelant le faible niveau de l' added, changed et removed DDP de l'API.
Les Mongo du pilote
Les Mongo du conducteur de l'emploi est de regarder le base de données Mongo pour les changements de
en direct des requêtes. Ces requêtes s'exécutent en permanence et le retour des mises à jour comme la
modification des résultats en appelant added, removed, et changed rappels.
Mongo est pas une base de données temps réel. Ainsi, le conducteur sondages. Il garde un
copie en mémoire de dernier résultat de la requête pour chaque actif en direct de la requête. Sur
chaque cycle d'interrogation, il compare le résultat avec la précédente enregistré
résultat, le calcul du minimum de added, removed, et changed
les événements qui décrivent la différence. Si plusieurs appelants registre
rappels pour le même concert de la requête, le conducteur seulement les montres d'une copie de
la requête, dans un appel de rappel enregistré avec le même résultat.
Chaque fois que le serveur met à jour une collection, le pilote recalcule chaque
en direct de la requête sur la collection (les Futures versions de Meteor exposer une
mise à l'échelle de l'API pour limiter qui vivent des requêtes de les recalculer à la mise à jour.) L'
le chauffeur, les sondages chaque requête sur un 10 secondes de la minuterie pour attraper
out-of-band de la base de données mises à jour contourné le serveur Meteor.
La fusion de la boîte de
Le travail de la fusion de la boîte est de combiner les résultats (added, changed et removed
appels) de l'ensemble d'un client actif de publier des fonctions dans un seul de données
flux de données. Il y a une fusion de zone pour chaque client connecté. Il est titulaire d'un
copie complète du client minimongo cache.
Dans votre exemple, avec un seul abonnement, la fusion de la boîte est
essentiellement un pass-through. Mais une application plus complexe peut avoir plusieurs
les abonnements qui peuvent se chevaucher. Si deux abonnements à la fois pour la
même attribut sur le même document, la fusion de la boîte de décide de la valeur
priorité et n'envoie que pour le client. Nous n'avons pas exposés
l'API pour le réglage de priorité de souscription encore. Pour l'instant, la priorité est
déterminé par l'ordonnance, le client s'abonne à des ensembles de données. La première
l'abonnement d'un client rend a la priorité la plus élevée, la deuxième
l'abonnement est plus élevé suivant, et ainsi de suite.
Parce que la fusion est l'état du client, il peut envoyer le minimum
la quantité de données à conserver chaque client jusqu'à ce jour, peu importe ce que publier
fonction qui le nourrit.
Ce qui se passe sur une mise à jour
Alors maintenant, nous avons préparé le terrain pour votre scénario.
Nous avons de 1 000 clients connectés. Chaque abonné à la même vivre
Mongo requête (Somestuff.find({})). Depuis la requête est la même pour chaque client, le conducteur est
n'exécuter qu'un seul live de la requête. Il y a 1000 active de fusion de boîtes. Et
de chaque client, en fonction publier enregistré une added, changed, et
removed sur que live requête qui se nourrit dans l'une des boîtes de fusion.
Rien d'autre n'est connecté à la fusion des boîtes.
D'abord les Mongo du pilote. Lorsque l'un des clients insère un nouveau document
en Somestuff, il déclenche un recalcul. Les Mongo pilote rediffusions
la requête pour tous les documents en Somestuff, compare le résultat à la
résultat précédent dans la mémoire, trouve qu'il y a un nouveau document, et
les appels de chacune des 1 000 inscrits insert rappels.
Ensuite, le publier fonctions. Il y a très peu de ce qui se passe ici: chaque
de la de 1 000 insert rappels pousse des données dans la zone de fusion par
appelant added.
Enfin, chaque fusion de la boîte de contrôles de ces nouveaux attributs à l'encontre de ses
copie en mémoire de son client en cache. Dans chaque cas, il constate que la
les valeurs ne sont pas encore sur le client et de ne pas l'ombre d'une valeur existante. Donc
la fusion de la boîte émet un DDP DATA message sur le SockJS connexion à son
client et de ses mises à jour côté serveur copie en mémoire.
Total CPU est le coût de diff un Mongo requête, plus le coût de
De 1 000 fusionner les boîtes de vérification de leurs clients de l'état et la construction d'un nouveau
DDP charge utile du message. Les seules données qui circulent sur le fil est un seul
Objet JSON envoyé à chacune des 1 000 clients, correspondant à la nouvelle
document dans la base de données, plus un message RPC sur le serveur de l'
client qui fait l'insert d'origine.
Optimisations
Voici ce que nous avons certainement prévu.
Plus efficace Mongo pilote. Nous
optimisé le pilote
dans 0.5.1 ne s'exécute qu'un seul observateur par requête distinct.
Pas tous les DB changement devrait déclencher un recalcul d'une requête. Nous
peut rendre certains automatisé des améliorations, mais la meilleure approche est une API
qui permet au développeur de spécifier des requêtes besoin de relancer. Pour
exemple, il est évident que pour un développeur que l'insertion d'un message dans
un chat ne devrait pas invalider un live de requête pour les messages dans un
deuxième chambre.
Les Mongo du pilote, de publier, et fusionner boîte n'avez pas besoin d'exécuter
dans le même processus, ou même sur la même machine. Certaines applications
complexes vivre requêtes et ont besoin de plus de CPU pour regarder la base de données.
D'autres ont seulement un peu de requêtes distinctes (imaginez un moteur de blog), mais
probablement beaucoup de clients connectés -- ces besoin de plus de CPU pour la fusion
les boîtes. La séparation de ces éléments nous laisser échelle de chaque pièce
de façon indépendante.
De nombreuses bases de données de soutenir les déclencheurs d'incendie lorsqu'une ligne est mise à jour et
fournir les anciennes et les nouvelles lignes. Avec cette fonctionnalité, un pilote de base de données
pourrait enregistrer un déclencheur au lieu de l'interrogation des modifications.
