Scénarios d'utilisation de NoSQL ou QUAND utiliser NoSQL

Question

Avec tout le battage médiatique que je suis trouve ça vraiment difficile de trouver des informations fiables sur l'utilisation de ce. Donc, je pose les questions suivantes, et je suis désolé si ce sont vraiment des questions stupides à l'avance:

1. Dois-je utiliser le NoSQL pour les données de l'utilisateur? E. g. les profils, les noms d'utilisateur + mots de passe, etc.
2. Dois-je utiliser le NoSQL pour le contenu important? E. g. les articles, billets de blog, des stocks de produits, etc.

Je suppose non? Et j'ai envie de le NoSQL est juste pour rapidement accessible choses à partir de laquelle il est normal de perdre des données. Mais j'ai aussi lu que le NoSQL applications ont redondance intégrée, de sorte que je n'ai pas de perdre des données?

Aussi, si les 2 exemples ci-dessus sont mauvais, pourriez-vous me donner d'affaires spécifiques en cas d'utilisation où je voudrais utiliser NoSQL? Je vois beaucoup de descriptions générales mais pas beaucoup d'exemples du monde réel. Les seules choses que je pense sont les utilisateurs de la messagerie et de l'analytique.

Merci!

Answer 1

C'est vraiment un "ça dépend" un peu la question. Certains généraux points:

• Le NoSQL est généralement bon pour les non structurées/"schemaless" données - généralement, vous n'avez pas besoin de définir explicitement votre schéma à l'avant et peut inclure de nouveaux champs sans aucune cérémonie
• NoSQL généralement favorable à une denormalised schéma en raison de l'absence de soutien pour les Jointures par le SGBDR monde. Donc, vous avez généralement aplatie, dénormalisée représentation de vos données.
• À l'aide de NoSQL ne signifie pas que vous risquez de perdre des données. Différents dbs ont des stratégies différentes. par exemple, MongoDB - vous pouvez choisir quel niveau de compromis entre les performances et le 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 mettre à l'échelle les solutions NoSQL. L'ajout de nœuds supplémentaires pour répliquer les données vers est un moyen pour une) offre 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, dépend de la NoSQL db/configuration. NoSQL ne signifie pas nécessairement "perte de données" comme vous en déduire.
• À mon humble avis, complexe/requêtes dynamiques/reporting sont les mieux servis à partir d'un SGBDR. Souvent les fonctionnalités de requête pour une NoSQL db est limitée.
• Il n'a pas à être un 1 ou l'autre choix. Mon expérience a été à l'aide de SGBDR en conjonction avec le NoSQL pour certains cas d'utilisation.
• NoSQL db, manquent souvent de la capacité à effectuer des opérations atomiques sur plusieurs "tableaux".

Vous avez vraiment besoin de regarder et de comprendre ce que les différents types de NoSQL magasins sont, et comment ils vont sur la façon de fournir l'évolutivité et la sécurité des données, etc. Il est difficile de donner un conseil de réponse, car ils sont vraiment tous différents, et d'aborder les choses différemment.

Pour MongoDb par exemple, de vérifier leurs Cas d'Utilisation pour voir ce qu'ils proposent comme étant "bien adapté" et "moins bien adapté" utilise de MongoDb.

Answer 2

Je pense que le Nosql est "plus adapté" dans ces scénarios au moins (plus complémentaire est la bienvenue)

1. Facile à l'échelle par le simple ajout de plusieurs nœuds.

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

   imaginer des tonnes de tweets postés sur twitter tous les jours. Dans RDMS, il pourrait y avoir des tables avec des millions (milliards ?) de lignes. et vous ne voulez pas faire de requête sur les tables directement, même pas mention, la plupart du temps, les jointures de table sont également nécessaires pour les requêtes complexes.

3. Disk i/o Goulot d'étranglement Si un site web besoin d'envoyer les résultats aux différents utilisateurs en fonction des utilisateurs des informations en temps réel, nous sommes probablement parler des dizaines ou des centaines de milliers de sql en lecture/écriture de requêtes par seconde. Puis disk i/o sera un sérieux goulot d'étranglement.

Answer 3

Récemment, j'ai écrit 2 articles de blog qui peut vous aider à faire votre choix mieux. On est sur ce genre de choses à regarder dehors pour si vous envisagez de commutation vers le NoSQL comme MongoDB et l'autre compare utilisation de l'espace disque entre MySQL et MongoDB qui en soi peut affecter les performances si le serveur de la base de données est hébergée sur de ne pas avoir assez de RAM. Vous pouvez voir ces articles ici:

http://blog.trackerbird.com/content/mongodb-performance-pitfalls-behind-the-scenes

et ici:

http://blog.trackerbird.com/content/mysql-vs-mongodb-disk-space-usage