Czy procedury skryptowe JavaScript przechowywane w MongoDB są szybsze?

Question

Ostatnio idę głęboko w MongoDB i zastanawiam się nad przechowywanymi procedurami JavaScript. Po przeczytaniu Blog Entry od PointBeinga mam kilka pytań.

• Czy to prawdziwa zaleta do przechowywania mojego kodu w DB? Mam na myśli funkcje takie jak lookups for documents, a nie adding numbers, jak przykład z PointBeing.
• Czy jest to szybsze niż kod JavaScript dla dostępu z strony node.js?
• Jeśli moje zapytania są przechowywane w bazie danych, czy są one buforowane (i szybsze)?

Przeglądam od rozwoju Point of node.js.

Answer 1

Ocenianie funkcje zapisane w db.system.js („Przechowywane procedur”, Kiedy chcesz zadzwonić do nich, że) jest przestarzała. Artykuły na db.eval shell function i the eval database command mają ostrzeżenie "Przestarzałe od wersji 3.0", a the article on server-sided javascript już o tym nie wspomina. Dlatego powinieneś go unikać. Jednym z powodów jest to, że nie możesz uruchomić funkcji javascript, gdy używasz shardowania. Więc kiedy tworzysz aplikację, która wymaga eval, zapobiegasz jej skalowaniu w przyszłości. Innym jest to, że funkcje javascript podważają koncepcję uprawnień. Zawsze muszą być uruchamiane jako administrator, co uniemożliwia ustanowienie rozsądnego systemu uprawnień. Jest to szczególnie problematyczne z punktu widzenia bezpieczeństwa, biorąc pod uwagę, że skrypty stronicowane, które wykorzystują dane dostarczane przez użytkowników, mogą potencjalnie być podatne na arbitralne iniekcje skryptów.

Zaletą javascript po stronie serwera jest to, że działa on na serwerze bazy danych. Zmniejsza to opóźnienie między serwerem aplikacji a serwerem bazy danych, gdy trzeba wykonać dużą liczbę zapytań. Ale możesz uzyskać tę samą korzyść, otwierając powłokę Mongo na serwerze bazy danych i wykonując ją tam.

Zaleta opóźnienia ma znaczenie tylko wtedy, gdy wykonujesz wiele zapytań ze swojego skryptu. Gdy masz tylko jedno zapytanie, nadal będziesz mieć opóźnienie podczas wywoływania skryptu. Nie zyskujesz nic poza niepotrzebną złożonością.

Nie ma dodatkowej buforowania ani innej optymalizacji dla javascript dwustronnego serwera.Co gorsza: zostanie zaatakowany i ponownie zinterpretowany za każdym razem, gdy go uruchomisz. Może to być nawet wolniejsze niż javascript na serwerze aplikacji.

Ponadto, wiele złożonych zapytań, które wymagają wsparcia skryptu tylko wdrożyć z find() często może być wyrażona za pomocą aggregation które w większości przypadków znacznie szybciej niż robi to samo z find() i javascript ponieważ ramy agregacja jest zaimplementowana w języku C++ i ma dostęp do surowych dokumentów BSON.

Answer 2

Zabawne jest to, że wpis na blogu (http://pointbeing.net/weblog/2010/08/getting-started-with-stored-procedures-in-mongodb.html) został napisany, gdy JS wziął pojedynczy globalny zamek.

Oznacza to, że nie było w nim żadnych funkcji waluty wspólnej lub bardziej szczegółowej blokady (blokada nadal stanowi problem, a wspólna waluta jest uzyskiwana tylko za pomocą wielu izolatów). To, że widzisz to w jakimś przypadkowym blogu, nie oznacza, że ​​powinno się go używać.

Aby odpowiedzieć na Twoje pytania bezpośrednio:

1. Nie. W rzeczywistości wadą jest to, że dzwoniący użytkownik potrzebuje pełnych uprawnień administratora. Oznacza to, że dajesz każdemu przywilejem swojego użytkownika, ponieważ wbudowane JS enigne ma haki na wszystko, łącznie z funkcjami administracyjnymi, jako że wymaga uprawnień administratora w celu uruchomienia.

2. Wywołanie JS z JS do JS do C++ w JS? Nie, nie ma, buforowanie MongoDB nie działa w ten sposób. Polecam zapoznanie się z dokumentacją najistotniejszych: http://docs.mongodb.org/manual/faq/fundamentals/