Als je vraagt naar de levensvatbaarheid van server-sided javascript, moet je eerst duidelijk maken over wat voor soort server-sided javascript je het hebt. Volgens de documentatie , zijn er vier verschillende soorten server-zijdige code-uitvoering. Helaas zijn het allemaal nogal hackachtige oplossingen voor situaties waarin de native API onvoldoende is:
De eval commando
eval heeft het nadeel dat het maar op één knooppunt draait. Dit vermindert het nut ervan in een geclusterde omgeving aanzienlijk. Met shard-collecties werkt het helemaal niet!
Standaard creëert het ook een globale vergrendeling die de database volledig onbruikbaar maakt totdat het script is uitgevoerd. Dit kan worden voorkomen met de nolock argument (tenzij het script zelf iets doet dat een globale vergrendeling creëert).
Het antwoord van Sammaye verklaart ook enkele ernstige veiligheidsproblemen.
Het is eigenlijk meer een test- en administratietool dan iets dat je zou moeten gebruiken voor een normale operatie.
.js-bestanden uitvoeren via een mongo-shell-instantie op de server
In dit geval wordt de code niet uitgevoerd op de database, maar op een ander onafhankelijk proces op een van de servers. Dit betekent dat alle vereiste gegevens van andere shards moeten worden overgedragen naar de server waarop de javascript-code wordt uitgevoerd, ongeacht wat er daadwerkelijk door het script wordt geretourneerd.
Het verschijnt als een andere applicatie op de mongodb-server, dus het kan niets doen wat je ook niet zou kunnen doen vanuit je normale applicatie. Het is nog een test- en administratietool die u bij normaal gebruik niet zou moeten gebruiken.
Zoeken met de $where -operator
De $where-operator in een find-opdracht maakt het mogelijk om een javascript-functie door te geven die wordt gebruikt om waarden te filteren. In de meeste triviale gevallen is dit een stuk minder performant dan wat de andere tools van de zoekquery te bieden hebben, vooral omdat het geen gebruik kan maken van indices.
Als het gebruik van $where niet kan worden vermeden, probeer dan in ieder geval enkele van de normale tools van de zoekquery te gebruiken om het aantal documenten dat moet worden doorgegeven aan de $where-functie te verminderen.
MapReduce
MapReduce gebruikt twee javascript-functies om geaggregeerde gegevens te maken. Het was vroeger de primaire tool voor datamining voor MongoDB, maar de meeste van zijn gebruikelijke gebruiksscenario's worden nu vervuld door de veel gebruiksvriendelijkere aggregatieraamwerk .
Het heeft ook hetzelfde nadeel als $where:tenzij u filtert, moet u voor elk document niet één maar minstens twee javascript-functies uitvoeren.
Maar MapReduce kan op zijn minst gedistribueerd worden uitgevoerd en het kan worden geparalleliseerd.
tl;dr:
Het gebruik van Javascript is een laatste redmiddel voor zeer ongebruikelijke zoekopdrachten die niet kunnen worden gemaakt met de normale zoektaal en waarvoor toegang tot te veel gegevens nodig is om in de toepassing te worden geïmplementeerd. Doe waar mogelijk wat u wilt doen met de gespecialiseerde tools die u tot uw beschikking heeft of implementeer uw logica op de applicatielaag.