Po pierwsze, Map/Reduce w MongoDB nie został stworzony dla zapytań ad-hoc, istnieje znaczne obciążenie dla M/R. Nawet bardzo prosta operacja M/R na małym zestawie danych może zająć setki milisekund z powodu tego nadmiaru.
Nie mogę wiele powiedzieć o wydajności M/R w porównaniu do struktury agregacji na dużych zestawach danych w praktyce, ale teoretycznie operacje M/R na dużej bazie danych z sharded powinny być szybsze, ponieważ odłamki mogą działać operacje w dużej mierze równolegle.
Jeśli chodzi o elastyczność, ponieważ M/R faktycznie obsługuje metody javascript, masz pełną moc języka do swojej dyspozycji. Na przykład, powiedzmy, że chcesz zgrupować dane przez cosinus wartości pola. Ponieważ w strukturze agregacji nie ma ani operatora $cos, ani znaczącego sposobu budowania oddzielnych segmentów z liczb ciągłych (podobnie jak w przypadku $truncate), struktura agregacji nie pomogłaby w takim przypadku.
Tak, w skrócie, powiedziałbym, że przypadki użycia są
- utrzymaniem wyników M/R w selektywnej zbiórki i aktualizowanie go od czasu do czasu (przy użyciu parametru
out i scalanie wyników)
- Złożone zapytania dotyczące dużych, zaszyfrowanych zestawów danych
- Zapytania, które są tak skomplikowane, że nie można użyć struktury agregacji. Powiedziałbym, że jest to całkiem pewna oznaka defektu konstrukcyjnego w strukturze danych, ale w zasadzie może pomóc