Scénarios d'utilisation de NoSQL ou QUAND utiliser NoSQL [fermé]

Avec tout le battage médiatique, il semble vraiment difficile de trouver des informations fiables sur le moment de l'utiliser. Je pose donc les questions suivantes, et je suis désolé si ce sont des questions vraiment stupides à l'avance:

1. Dois-je utiliser NoSQL pour les données utilisateur? Par exemple, profils, noms d'utilisateur + mots de passe, etc.
2. Dois-je utiliser NoSQL pour le contenu important? Par exemple, articles, articles de blog, inventaire de produits, etc.

Je suppose que non? Et je pense que NoSQL est juste pour les choses rapidement accessibles à partir desquelles il est OK de perdre des données. Mais j'ai également lu que les applications NoSQL ont une redondance intégrée afin que je ne perde pas de données?

De plus, si les 2 exemples ci-dessus sont mauvais, pourriez-vous me donner des cas d'utilisation spécifiques où j'utiliserais NoSQL? Je vois beaucoup de descriptions générales mais pas beaucoup d'exemples concrets. Les seules choses auxquelles je peux penser sont la messagerie et l'analyse d'utilisateur à utilisateur.

Merci!

C'est vraiment une question "ça dépend". Quelques points généraux :

• NoSQL est généralement bon pour les données non structurées / "sans schéma" - généralement, vous n'avez pas besoin de définir explicitement votre schéma à l'avance et pouvez simplement inclure de nouveaux champs sans aucune cérémonie
• NoSQL favorise généralement un schéma dénormalisé en raison de l'absence de prise en charge des JOIN par le monde RDBMS. Ainsi, vous auriez généralement une représentation aplatie et dénormalisée de vos données.
• L'utilisation de NoSQL ne signifie pas que vous pourriez perdre des données. Différentes bases de données ont des stratégies différentes. Par exemple, MongoDB - vous pouvez essentiellement choisir le niveau de compromis entre performance et potentiel de perte de données - meilleure performance = une plus grande portée pour la perte de données.
• Il est souvent très facile de faire évoluer des solutions NoSQL. Ajouter plus de nœuds pour répliquer les données est un moyen pour a) offrir plus d'évolutivité et b) offrir plus de protection contre la perte de données si un nœud tombe en panne. Mais encore une fois, cela dépend de la configuration / base de données NoSQL. NoSQL ne signifie pas nécessairement «perte de données» comme vous le supposez.
• À mon humble avis, les requêtes / rapports complexes / dynamiques sont mieux servis à partir d'un SGBDR. Souvent, la fonctionnalité de requête pour une base de données NoSQL est limitée.
• Il n'est pas nécessaire que ce soit un 1 ou l'autre choix. Mon expérience a été d'utiliser RDBMS en conjonction avec NoSQL pour certains cas d'utilisation.
• Les bases de données NoSQL n'ont souvent pas la possibilité d'effectuer des opérations atomiques sur plusieurs "tables".

Vous avez vraiment besoin de regarder et de comprendre quels sont les différents types de magasins NoSQL, et comment ils procurent l'évolutivité / la sécurité des données, etc. Il est difficile de donner une réponse générale car ils sont tous différents et abordent les choses différemment .

Pour MongoDb à titre d'exemple, consultez leurs cas d'utilisation pour voir ce qu'ils suggèrent comme étant des utilisations «bien adaptées» et «moins bien adaptées» de MongoDb.

Je pense que Nosql est "plus approprié" dans ces scénarios au moins (plus de complément est le bienvenu)

1. Facile à mettre à l'échelle horizontalement en ajoutant simplement plus de nœuds.

2. Requête sur un grand ensemble de données

   Imaginez des tonnes de tweets publiés sur Twitter chaque jour. Dans RDMS, il peut y avoir des tables avec des millions (ou des milliards?) De lignes, et vous ne voulez pas faire de requête directement sur ces tables, sans même mentionner, la plupart du temps, des jointures de table sont également nécessaires pour les requêtes complexes.

3. Goulot d'étranglement d'E / S disque

   Si un site Web doit envoyer des résultats à différents utilisateurs en fonction des informations en temps réel des utilisateurs, nous parlons probablement de dizaines ou de centaines de milliers de requêtes de lecture / écriture SQL par seconde. Les E / S disque constitueront alors un sérieux goulot d'étranglement.