Does the server side javascript function have performance issues in mongoDB?

Question

Does the server side of JavaScript have performance issues in MongoDB? Does V8 solve performance problems?

Why doesn't MongoDB documentation recommend using server-side functions?

Answer 1

When you ask about the viability of server-side javascript, you first need to clarify which server-side javascript you are talking about. According to the documentation, there are four different options for executing server code. Unfortunately, all of them are hacker workarounds for situations when the native API is not enough:

Eval command

eval has the disadvantage that it only works on one node. This greatly reduces its usefulness in a cluster environment. With private collections, this does not work!

By default, it also creates a global lock, which makes the database completely unusable until the script is run. This can be prevented with the nolock argument (unless the script does something that creates a global lock).

Sammaye's answer also explains some serious security concerns.

This is more of a testing and administration tool than what you should use for any regular operation.

Running .js files through mongo shell Instance on server

In this case, the code is not executed in the database, but rather on another independent process on one of the servers. This means that all the required data from other shards must be transferred to the server that runs the javascript code, regardless of what really returned with the script.

It appears as another application for the mongodb server, so it cannot do anything that you could not do from your regular application. This is another test and administration tool that you should not use in your normal work.

Find $ where is the operator

The $ where operator in the find command allows you to pass a javascript function that is used to filter values. For most trivial cases, this is much less than what other search query tools can offer, especially because it cannot use any indexes.

When using $, where you cannot avoid, at least try to use some of the usual search-query tools to reduce the number of documents that need to be passed to the $ where function.

Mapreduce

MapReduce uses two javascript functions to create aggregated data. It used to be the main data mining tool for MongoDB, but most of its usual use cases are now performed by a much more friendly aggregation structure .

It also has the same drawback as $ where: If you are not filtering, you will have to run not one, but at least two javascript functions for each document.

But MapReduce can at least run distributed and can be parallelized.

TL; dr:

Using Javascript is the latest measure for very unusual queries that cannot be done with the normal query language and that require access to too much data that will be implemented in the application. Whenever possible, do what you want to do with the specialized tools you have, or implement your logic at the application level.

Answer 2

The documentation recommends not using JavaScript stored procedures in MongoDB.

I seem to still refuse to call it the "server side", because this means that it works "in" MongoDB, which is not there, they do not store the procedure.

In any case, by default, JavaScript functions perform a global lock, which can be reduced using nolock and V8 (by default from 2.4) can be multithreaded; therefore it seems like it is useful, but there are other problems:

• eval is run based on a set of replicas and only primary
• eval does not work with private collections.
• eval must have full administrator access to run generally with auth enabled (this means using the admin user in your application)
• eval works in a stand-alone JavaScript environment that, when launched with admin acess, has full access to your database. This in itself makes calls for me, mainly because of the quirks that can be used to compromise my system from the inside out.

Honestly, changing the V8 adds some awesomeness to Map Reduce and more, but I would not say that it has changed much in terms of trying to replace stored procedures with stored JavaScript functions.

As an added note: http://docs.mongodb.org/manual/reference/command/eval/#dbcmd.eval in the warning window you should not try this.