NoSQL Use Case Scenarios o WHEN per usare NoSQL

Con tutto il clamore sembra davvero difficile trovare informazioni affidabili su quando utilizzare questo. Quindi pongo le seguenti domande, e mi dispiace se queste sono domande davvero stupide in anticipo:

  1. Dovrei usare NoSQL per i dati utente? Ad esempio profili, nomi utente + password, ecc.
  2. Dovrei usare NoSQL per contenuti importanti? Ad esempio articoli, post di blog, inventario di prodotti, ecc.

Sto assumendo no? E mi sento come NoSQL è solo per le cose rapidamente accessibili da cui è OK per perdere i dati. Ma ho letto anche che le app NoSQL hanno ridondanza integrata per non perdere dati?

Inoltre, se i precedenti 2 esempi sono sbagliati, potresti fornirmi specifici casi di utilizzo aziendale in cui utilizzerei NoSQL? Vedo molte descrizioni generali ma non molti esempi reali. Le uniche cose che posso pensare sono la messaggistica e l’analisi da utente a utente.

Grazie!

È davvero una domanda “dipende”. Alcuni punti generali :

  • NoSQL è in genere un bene per i dati non strutturati / “schemaless” – di solito, non è necessario definire esplicitamente il proprio schema in anticipo e può solo includere nuovi campi senza alcuna cerimonia
  • NoSQL in genere favorisce uno schema denormalizzato a causa dell’assenza di supporto per JOINs per il mondo RDBMS. Quindi di solito hai una rappresentazione appiattita e denormalizzata dei tuoi dati.
  • L’uso di NoSQL non significa che potresti perdere dati. DB diversi hanno strategie diverse. ad es. MongoDB – puoi essenzialmente scegliere quale livello scambiare le prestazioni rispetto al potenziale per la perdita di dati – prestazioni migliori = maggiori possibilità di perdita di dati.
  • Spesso è molto semplice scalare le soluzioni NoSQL. L’aggiunta di più nodes per la replica dei dati è uno dei modi per a) offre una maggiore scalabilità eb) offre una maggiore protezione contro la perdita di dati in caso di guasto di un nodo. Ma ancora, dipende dal DB / configurazione NoSQL. NoSQL non significa necessariamente “perdita di dati” come si deduce.
  • IMHO, query / reporting complessi / dinamici sono meglio serviti da un RDBMS. Spesso la funzionalità di query per un DB NoSQL è limitata.
  • Non deve essere un 1 o l’altra scelta. La mia esperienza ha utilizzato RDBMS in combinazione con NoSQL per determinati casi d’uso.
  • I DB NoSQL spesso non hanno la capacità di eseguire operazioni atomiche su più “tabelle”.

Hai davvero bisogno di guardare e capire quali sono i vari tipi di negozi NoSQL, e come vanno a fornire scalabilità / sicurezza dei dati, ecc. È difficile dare una risposta a tutto campo in quanto sono davvero tutti diversi e affrontare le cose in modo diverso .

Come esempio di MongoDb, controlla i loro casi d’uso per vedere cosa suggeriscono come usi “ben adattati” e “meno adatti” di MongoDb.

Penso che Nosql sia “più adatto” almeno in questi scenari (più informazioni supplementari sono benvenute)

  1. Facile da ridimensionare semplicemente aggiungendo più nodes.

  2. Query su set di dati di grandi dimensioni

    Immagina tonnellate di tweet pubblicati su Twitter ogni giorno. In RDMS, potrebbero esserci tabelle con milioni (o miliardi?) Di righe e non si desidera eseguire query su tali tabelle direttamente, nemmeno menzionando, la maggior parte del tempo, anche le join di tabelle sono necessarie per query complesse.

  3. Collo di bottiglia di I / O del disco

    Se un sito web deve inviare risultati a diversi utenti in base alle informazioni in tempo reale degli utenti, probabilmente stiamo parlando di decine o centinaia di migliaia di richieste di lettura / scrittura SQL al secondo. Quindi il disco i / o sarà un serio collo di bottiglia.