Próbowałem użyć MongoDB 2.4.3 (również wypróbowany 2.4.4) z mapReduce na klastrze z 2 odłamkami za każdym razem 3 repliki. Mam problem z tym, że wyniki zadania mapReduce nie są redukowane do zbierania danych wyjściowych. Próbowałem Incremental Map Reduce. Próbowałem też "scalania" zamiast zmniejszania, ale to też nie działało.MapReduce w MongoDB nie wypuszcza
Mapa zredukować bieg polecenia na Mongos: (pot nie jest sharded)
db.coll.mapReduce(map, reduce, {out: {reduce: "events", "sharded": true}})
co daje następujący wynik:
{
"result" : "events",
"counts" : {
"input" : NumberLong(2),
"emit" : NumberLong(2),
"reduce" : NumberLong(0),
"output" : NumberLong(28304112)
},
"timeMillis" : 418,
"timing" : {
"shardProcessing" : 11,
"postProcessing" : 407
},
"shardCounts" : {
"stats2/192.168.…:27017,192.168.…" : {
"input" : 2,
"emit" : 2,
"reduce" : 0,
"output" : 2
}
},
"postProcessCounts" : {
"stats1/192.168.…:27017,…" : {
"input" : NumberLong(0),
"reduce" : NumberLong(0),
"output" : NumberLong(14151042)
},
"stats2/192.168.…:27017,…" : {
"input" : NumberLong(0),
"reduce" : NumberLong(0),
"output" : NumberLong(14153070)
}
},
"ok" : 1,
}
Więc widzę, że mapreduce jest przejechany 2 rekordy, w wyniku których powstają 2 rekordy. Jednak w wartościach postProcessCount dla obu shardów licznik wejściowy pozostaje równy 0. Również próba znalezienia rekordu przy wyszukiwaniu _id nie daje wyniku. W pliku dziennika MongoDB nie mogłem znaleźć komunikatów o błędach związanych z tym.
Po próbie odtworzenia tego z nowo utworzoną kolekcją wyjściową, że ja również odłożyłem haszowany _id i dałem te same indeksy, nie byłem w stanie tego odtworzyć. Podczas wyprowadzania samo wejście do innej kolekcji
db.coll.mapReduce(map, reduce, {out: {reduce: "events_test2", "sharded": true}})
Wynik jest przechowywany w zbiorze wyjściowym i mam następujący wynik:
{
"result" : "events_test2",
"counts" : {
"input" : NumberLong(2),
"emit" : NumberLong(2),
"reduce" : NumberLong(0),
"output" : NumberLong(4)
},
"timeMillis" : 321,
"timing" : {
"shardProcessing" : 68,
"postProcessing" : 253
},
"shardCounts" : {
"stats2/192.168.…:27017,…" : {
"input" : 2,
"emit" : 2,
"reduce" : 0,
"output" : 2
}
},
"postProcessCounts" : {
"stats1/192.168.…:27017,…" : {
"input" : NumberLong(2),
"reduce" : NumberLong(0),
"output" : NumberLong(2)
},
"stats2/192.168.…:27017,…" : {
"input" : NumberLong(2),
"reduce" : NumberLong(0),
"output" : NumberLong(2)
}
},
"ok" : 1,
}
kiedy ponownie uruchamiając skrypt z tego samego wejścia ouputting ponownie Druga kolekcja pokazuje, że zmniejsza się w postProcessCounts. Tak więc funkcje mapowania i zmniejszania działają dobrze. Dlaczego nie działa na większej pierwszej kolekcji? Czy robię coś złego tutaj? Czy są jakieś specjalne ograniczenia dotyczące kolekcji, które można wykorzystać jako dane wyjściowe do zmniejszenia mapy?
dla uproszczenia, ponieważ ta kolekcja nie jest zignorowana (i jest mała), dlaczego nie uruchamiasz mapreduce w nieudzieloną kolekcję wyjściową? –
również początkowo mówisz, że coll nie jest sharded, ale później mówisz, że próbujesz ponownie z nową kolekcją, którą * także * zignorowałeś. więc straciłeś mnie na tym, czy początkowa kolekcja jest zerwana i dlaczego odrzucasz kolekcję wyjściową. –
Kolekcja danych wejściowych nie jest odrzucana, ale kolekcje wyjściowe są. Tak więc problem polega na tym, że w pierwszym usuniętym zbiorze nie zapisano żadnych danych wyjściowych, chociaż w drugim wyświetleniu kolekcji z pominięciem ** jest napisane **. Do celów testowych użyłem tu niewielkiego wkładu, aby łatwiej było zobaczyć, co się dzieje, planowałem to zrobić przy większych wejściach w przyszłości. Również aktualizacja istniejących rekordów (z redukcją, patrz http://docs.mongodb.org/manual/tutorial/perform-incremental-map-reduce/) jest bardzo wygodna. – Mark