2015-05-08 15 views
9

Ultimamente sto andando in profondità in MongoDB e mi sto interrogando sulle stored procedure JavaScript. Dopo aver letto il Blog Entry da PointBeing, ho alcune domande.Le procedure JavaScript memorizzate MongoDB sono più veloci?

  • È un vero vantaggio archiviare il mio codice in DB? Intendo funzioni come lookups for documents, non adding numbers come nell'esempio da PointBeing.
  • È più veloce del codice JavaScript per l'accesso dal lato node.js?
  • Se le mie query sono memorizzate nel database, la cache è (e più veloce)?

Sto guardando dallo sviluppo Point of node.js.

+2

Mantiene una domanda per post. SO non consente di fare 4 domande contemporaneamente. –

+3

@Salvador Queste domande sono tutte strettamente correlate, vedo poco da spaccare in tre post separati. – deceze

+1

1: No, 2: No, 3: Naturalmente non – Sammaye

risposta

13

funzioni memorizzate in db.system.js ("Procedure memorizzate", quando si desidera chiamare così) è deprecato valutazione. Gli articoli su db.eval shell function e the eval database command hanno un avviso "Deprecato dalla versione 3.0" e the article on server-sided javascript non lo menzionano più. Quindi dovresti evitare di usarlo. Una ragione è che non puoi eseguire una funzione javascript quando usi sharding. Quindi, quando costruisci un'applicazione che richiede l'eval, ne impedisci il ridimensionamento in futuro. Un altro è che le funzioni javascript minano il concetto di autorizzazione. Hanno sempre bisogno di essere eseguiti come admin, il che rende impossibile stabilire un sistema di autorizzazione sano. Ciò è particolarmente problematico dal punto di vista della sicurezza considerando che gli script lato server che utilizzano i dati forniti dall'utente possono potenzialmente essere vulnerabili a iniezioni di script arbitrarie.

Il vantaggio del javascript lato server è che viene eseguito sul server database. Ciò riduce la latenza tra application server e server di database quando è necessario eseguire un numero elevato di query. Ma puoi ottenere lo stesso vantaggio aprendo una shell mongo sul server del database e eseguendola lì.

Il vantaggio di latenza è rilevante solo quando si eseguono più query dallo script. Quando hai una sola query, avrai ancora la latenza quando invochi lo script. Quindi non ottieni nulla se non una complessità inutile.

Non vi è alcun caching aggiuntivo o altra ottimizzazione per javascript lato server.Ancora peggio: verrà rianimato e reinterpretato ogni volta che lo esegui. Quindi potrebbe anche essere più lento di javascript nel server delle applicazioni.

Inoltre, molte query complesse che richiederebbero il supporto di script per implementare solo con find() spesso può essere espresso utilizzando aggregation che nella maggior parte dei casi, essere di gran lunga più veloce di fare lo stesso con find() e javascript, perché il quadro di aggregazione è implementato in C++ e ha accesso ai documenti BSON non elaborati.

+0

È difficile implementare le query utilizzando l'API di MongoDB C# Versione 1.7.0.4714 API quando la query coinvolge molti quasi-join tra le raccolte MongoDB. Credo che rallenti le prestazioni se porti una grande quantità di dati dal mondo MongoDB nel mondo C# come oggetti POCO in un elenco. Quindi, stavo pensando se fosse opportuno adottare la pratica di implementazione dell'uso di C# per richiamare il JavaScript memorizzato in MongoDB. Stai dicendo che invocare JavaScript memorizzato è sbagliato. Per favore vedi: http://stackoverflow.com/questions/36220272/c-sharp-invocation-of-stored-javascript-in-mongodb-vs-mongodb-c-sharp-driver-ver –

+0

@CSLewis Quando devi fare un sacco di quasi-join, quindi è molto probabile che si utilizza mongodb come un database relazionale, che raramente ottiene buoni risultati. – Philipp

+0

ok, ma, cosa succede se faccio solo un'intensa quantità di analisi su una collezione con una grande quantità di dati. Penso che sarebbe una prestazione lenta inserendo un sacco di documenti dalla collezione come oggetti C# POCO nel mondo C#. Invece, ho pensato che sarebbe stato meglio se C# invocasse il JavaScript memorizzato, che avrebbe fatto molta dell'analisi intensiva, e poi avrebbe restituito i risultati finali al mondo C#. Quale altra alternativa ho? –

3

La cosa esilarante è che post sul blog (http://pointbeing.net/weblog/2010/08/getting-started-with-stored-procedures-in-mongodb.html) è stato scritto quando JS sono voluti solo singolo blocco globale filettato.

Ciò significa che non vi era nessuna caratteristica con-valuta o blocco più granulare ad esso associati (la serratura essendo ancora un problema e con-moneta viene ottenuto solo attraverso più isolati ancora). Solo perché lo vedi in qualche post sul blog casuale non significa che dovrebbe essere usato.

per rispondere alle vostre domande direttamente:

  1. Nope. In effetti lo svantaggio è che l'utente chiamante necessita di diritti di amministratore completi. Ciò significa che dai ogni singolo privilegio al tuo utente web dal momento che l'in-built JS enigne ha agganci per tutto, comprese le funzioni di amministrazione in quanto tale richiede diritti di amministratore per poter essere eseguito.

  2. Calling JS da JS JS per C++ a JS? No

  3. No, il caching di MongoDB non funziona in questo modo. Vi consiglio di leggere la documentazione fondamentali: http://docs.mongodb.org/manual/faq/fundamentals/

Problemi correlati