sql >> Database teknologi >  >> NoSQL >> MongoDB

Gennemsnitlige aggregeringsforespørgsler i Meteor

Fra Meteor 0.6.5 understøtter samlings-API'en ikke aggregeringsforespørgsler endnu, fordi der ikke er nogen (ligetil) måde at lave live-opdateringer på dem. Du kan dog stadig skrive dem selv og gøre dem tilgængelige i en Meteor.publish , selvom resultatet vil være statisk. Efter min mening er det stadig at foretrække at gøre det på denne måde, fordi du kan flette flere sammenlægninger og bruge indsamlings-API'en på klientsiden.

Meteor.publish("someAggregation", function (args) {
    var sub = this;
    // This works for Meteor 0.6.5
    var db = MongoInternals.defaultRemoteCollectionDriver().mongo.db;

    // Your arguments to Mongo's aggregation. Make these however you want.
    var pipeline = [
        { $match: doSomethingWith(args) },
        { $group: {
            _id: whatWeAreGroupingWith(args),
            count: { $sum: 1 }
        }}
    ];

    db.collection("server_collection_name").aggregate(        
        pipeline,
        // Need to wrap the callback so it gets called in a Fiber.
        Meteor.bindEnvironment(
            function(err, result) {
                // Add each of the results to the subscription.
                _.each(result, function(e) {
                    // Generate a random disposable id for aggregated documents
                    sub.added("client_collection_name", Random.id(), {
                        key: e._id.somethingOfInterest,                        
                        count: e.count
                    });
                });
                sub.ready();
            },
            function(error) {
                Meteor._debug( "Error doing aggregation: " + error);
            }
        )
    );
});

Ovenstående er et eksempel på gruppering/optælling. Nogle ting at bemærke:

  • Når du gør dette, vil du naturligvis lave en aggregering på server_collection_name og skubbe resultaterne til en anden samling kaldet client_collection_name .
  • Dette abonnement vil ikke være live og vil sandsynligvis blive opdateret, når argumenterne ændrer sig, så vi bruger en virkelig simpel løkke, der bare skubber alle resultaterne ud.
  • Resultaterne af aggregeringen har ikke Mongo ObjectID'er, så vi genererer nogle vilkårlige af vores egne.
  • Tilbagekaldet til aggregeringen skal pakkes ind i en Fiber. Jeg bruger Meteor.bindEnvironment her, men man kan også bruge en Future for mere kontrol på lavt niveau.

Hvis du begynder at kombinere resultaterne af publikationer som disse, skal du nøje overveje, hvordan de tilfældigt genererede id'er påvirker fletteboksen. En ligetil implementering af dette er dog kun en standard databaseforespørgsel, bortset fra at det er mere bekvemt at bruge med Meteor API'er på klientsiden.

TL;DR-version :Næsten hver gang du skubber data ud fra serveren, en publish er at foretrække frem for en method .

For mere information om forskellige måder at lave aggregering på, tjek dette indlæg .



  1. HBase-opgradering oven på Event Sourcing og CQRS-arkitektur på 3 uger

  2. Redis sentinels i samme servere som master/slave?

  3. Mongoose befolker vs objektnesting

  4. RuntimeWarning:Du kører arbejderen med superbrugerrettigheder:dette anbefales absolut ikke