Lorsque vous posez des questions sur la viabilité du javascript côté serveur, vous devez d'abord préciser de quel type de javascript côté serveur vous parlez. Selon la documentation , il existe quatre types différents d'exécution de code côté serveur. Malheureusement, ce sont tous des solutions de contournement pour les situations où l'API native est insuffisante :
Le eval commande
eval a l'inconvénient de ne s'exécuter que sur un seul nœud. Cela réduit considérablement son utilité dans un environnement en cluster. Avec les collections partitionnées, ça ne marche pas du tout !
Par défaut, il crée également un verrou global qui rend la base de données complètement inutilisable jusqu'à ce que le script soit exécuté. Cela peut être évité avec le nolock argument (sauf si le script lui-même fait quelque chose qui crée un verrou global).
La réponse de Sammaye explique également de sérieux problèmes de sécurité.
C'est vraiment plus un outil de test et d'administration que quelque chose que vous devriez utiliser pour toute opération régulière.
Exécuter des fichiers .js via une instance de shell mongo sur le serveur
Dans ce cas, le code n'est pas exécuté sur la base de données, mais plutôt sur un autre processus indépendant sur l'un des serveurs. Cela signifie que toutes les données requises des autres partitions doivent être transférées vers le serveur qui exécute le code javascript, peu importe ce qui est réellement renvoyé par le script.
Il apparaît comme une autre application sur le serveur mongodb, il ne peut donc rien faire que vous ne puissiez pas faire depuis votre application habituelle. C'est un autre outil de test et d'administration que vous ne devriez pas utiliser en fonctionnement normal.
Recherchez avec $where -opérateur
L'opérateur $where dans une commande find permet de passer une fonction javascript qui est utilisée pour filtrer les valeurs. Pour la plupart des cas triviaux, c'est beaucoup moins performant que ce que les autres outils de la requête de recherche ont à offrir, notamment parce qu'il ne peut utiliser aucun index.
Lorsque l'utilisation de $where ne peut être évitée, essayez au moins d'utiliser certains des outils normaux de la requête de recherche pour réduire l'ensemble de documents qui doivent être transmis à la fonction $where.
MapReduce
MapReduce utilise deux fonctions javascript pour créer des données agrégées. C'était autrefois le principal outil d'exploration de données pour MongoDB, mais la plupart de ses cas d'utilisation habituels sont désormais remplis par le beaucoup plus convivial cadre d'agrégation .
Il a également le même inconvénient que $where :à moins que vous ne filtriez, vous devrez exécuter non pas une mais au moins deux fonctions javascript pour chaque document.
Mais MapReduce peut au moins fonctionner de manière distribuée et il peut être parallélisé.
tl;dr :
L'utilisation de Javascript est une mesure de dernier recours pour les requêtes très inhabituelles qui ne peuvent pas être effectuées avec le langage de requête normal et qui nécessitent l'accès à trop de données pour être implémentées dans l'application. Lorsque cela est possible, faites ce que vous voulez faire avec les outils spécialisés dont vous disposez ou implémentez votre logique sur la couche application.
