Are MongoDB Stored JavaScript Procedures faster?

Question

I have questions regarding stored JavaScript Procedures. After reading the Blog Entry from PointBeing, I have some questions.

• Is there an advantage to storing my code in the DB? I mean functions like lookups for documents, not adding numbers like the example from PointBeing.
• Is MongoDB stored javascript faster than node.js javascript?
• Is MongoDB stored javascript queries cached and are they any faster?

I'm interested in MongoDB stored javascript performance compared to Node.js Javascript.

Answer 1

Evaluating functions stored in db.system.js ("Stored procedures", when you would like to call them that) is deprecated. The articles on the db.eval shell function and the eval database command have a "Deprecated since version 3.0" warning and the article on server-sided javascript doesn't mention it anymore. So you should avoid using it. One reason is that you can not run a javascript function when you use sharding. So when you build an application which requires eval, you prevent it from scaling in the future. Another is that javascript functions undermine the permission concept. They always need to be run as admin, which makes it impossible to establish a sane permission system. This is especially problematic from a security standpoint considering that server-sided scripts which use user-provided data can potentially be vulnerable to arbitrary script injections.

The advantage of server-sided javascript is that it runs on the database server. This reduces latency between application server and database server when you need to perform a large number of queries. But you can get the same advantage by opening a mongo shell on the database server and executing it there.

The latency advantage is only relevant when you perform multiple queries from your script. When you have only one query, you will still have the latency when invoking the script. So you gain nothing except unnecessary complexity.

There is no additional caching or other optimization for server-sided javascript. Even worse: It will get reparsed and reinterpreted everytime you run it. So it might even be slower than javascript in your application server.

Further, many complex queries which would require script support to implement only with find() can often be expressed using aggregation which will in most cases be far faster than doing the same with find() and javascript because the aggregation framework is implemented in C++ and has access to the raw BSON documents.

Answer 2

The hilarious thing is that blog post ( http://pointbeing.net/weblog/2010/08/getting-started-with-stored-procedures-in-mongodb.html ) was written when JS only took single threaded global lock.

That means there was no con-currency features or more granular lock associated with it (the lock still being a problem and con-currency is only achieved through multiple isolates still). Just because you see it in some random blog post does not mean it should be used.

To answer your questions directly:

1. Nope. In fact the disadvantage is that the calling user needs full admin rights. This means you give every single privilege to your web user since the inbuilt JS enigne has hooks for everything, including administration functions as such it requires admin rights in order to run.

2. Calling JS from JS to JS to C++ in JS? No

3. No, MongoDB caching does not work like that. I recommend you read the fundamentals documentation: http://docs.mongodb.org/manual/faq/fundamentals/