Map / Reduce i DSL

Nie miałem okazji pracowania nad projektami, gdzie intensywnie korzysta się z map / reduce, ale od pewnego czasu chodzi mi po głowie pytanie. Z różnych źródeł jakie czytam okazuje się, że map/reduce sam w sobie bywa problematyczny do takiego stopnia, że twórcy baz tworzą nakładki w postaci DSL.

Przykłady:

• mongo dołączają agregation framework
• a google https://pl.wikipedia.org/wiki/Sawzall

Co jest głównym powodem?

Chodzi o uzyskanie deklaratywnego zapisu, aby mówić CO zamast JAK? Chodzi o optymalizacje? W SQL tak jest, że zapytanie bez przeształcania może uzyskać poprawoną wydajność i bez konieczności zmiany zapytania (np. po dodaniu indeksu).

Czy może bardziej chodzi o jakieś problemy związane z utrzymaniem? Pod jakim kątem taki map reduce jest problematyczny? Domyślam się, ze w map/reduce zapytania są bardziej kruche, przystosowane do konkretnego modelu, i że zmiana modelu może popsuć istniejące zapytania. Ale czy to jest coś porażającego, by od razu stosować DSL? Czy tego testy nie wykrywają? Przecież nawet jak w SQL zmienię model to i tak muszę upewnić się czy pozostałe zapytania nadal mają sens.

A może chodzi o coś innego?

Chętnie poznałbym jaki jest typowy powód, kiedy użycie DSL się zwarca oraz jak sami ten temat postrzegacie.

Może jest pewnien próg po przekroczeniu którego map/reduce daje w kość, czy dostrzegacie taką granicę?

Myślę że sobie sam odpowiedziałaś, map/reduce można porównać do imperatywnych niskopoziomowych operatorów używanych przez relacyjne bazy danych w stylu merge join/index scan itp. Wprowadzając abstrakcję jaką jest DSL bazy będą miał większą dowolność w wyborze planu jak wykonać takie zapytanie i pewnie może się zdarzyć że czasami wybrany plan zapytania nie będzie miał nic wspólnego z map/reduce, a zostanie użyta pod spodem inna technika którą baza uzna za lepszą w danym wypadku. Czyli dokładnie to dąży do tego co mamy w relacyjnych bazach danych, deklaratywny SQL, na podstawie którego biorąc pod uwagę statystyki i dostępne indeksy są tworzone imperatywne plany zapytań.