web-dev-qa-db-fra.com

Quand quelqu'un utiliserait-il MongoDB (ou similaire) sur un SGBD relationnel?

Je suis un peu confus à propos de toute la chose NoSQL et autres. Quand choisiriez-vous d'utiliser quelque chose comme MongoDB plutôt que quelque chose comme Oracle ou MySQL? Je ne comprends pas vraiment la "différence" en ce qui concerne l'utilisation entre eux.

D'après ma compréhension, les bases de données de type NoSQL ne sont pas censées remplacer les SGBDR, mais que sont-elles censées faire exactement?

databasenosqlrdms
138
user6791

J'ai déjà utilisé CouchDB pour trois projets d'animaux domestiques.

  • Un système de micro blogging.
  • Pour enregistrer des informations pour une petite application de prise de notes que j'ai faite.
  • Une application de brainstorming à usage général.

La raison principale pour laquelle j'ai choisi ceci plutôt que quelque chose comme MSSQL ou MySQL est la flexibilité que vous obtenez en l'utilisant. Pas de schéma rigide. Si trois mois plus tard, vous avez besoin d'une certaine table pour avoir un champ supplémentaire, et ceci et cela, il vous suffit de le changer et il ondule à partir de là.

J'ai utilisé Beginning CouchDB par Apress pour apprendre à l'utiliser.

Par exemple, CouchDB utilise json pour communiquer vers/depuis la base de données. Si votre langue peut POST data, alors vous pouvez l'utiliser pour communiquer avec la base de données.

Lisez aussi: Pourquoi devrais-je utiliser une base de données basée sur des documents au lieu d'une base de données relationnelle? sur StackOverflow

34
Sergio

Désolé d'ajouter une autre réponse, mais aucune des réponses ici n'est très satisfaisante. Cette réponse est spécifique à MongoDB (par opposition à la vaste gamme d'autres options de stockage de données qui ne sont pas des bases de données relationnelles).

Avantages:

  • MongoDB a une latence plus faible par requête et passe moins de temps CPU par requête car il fait beaucoup moins de travail (par exemple pas de jointures, de transactions). En conséquence, il peut gérer une charge plus élevée en termes de requêtes par seconde et est donc souvent utilisé si vous avez un grand nombre d'utilisateurs.
  • MongoDB est plus facile à partager (à utiliser dans un cluster) car il n'a pas à se soucier des transactions et de la cohérence.
  • MongoDB a un vitesse d'écriture plus rapide car il n'a pas à se soucier des transactions ou des annulations (et n'a donc pas à se soucier du verrouillage).
  • MongoDB n'a pas de schéma au cas où vous auriez un cas d'utilisation spécial qui pourrait en profiter.

Inconvénients:

  • MongoDB ne prend pas en charge les transactions. C'est ainsi qu'il obtient la plupart de ses avantages.
  • En général, MongoDB crée plus de travail (par exemple plus de coût CPU) pour le serveur client. Par exemple, pour joindre des données, il faut émettre plusieurs requêtes et effectuer la jointure sur le client.
  • Même ici en 2017, il y a moins de prise en charge d'outils pour MongoDB que pour les bases de données relationnelles simplement parce qu'il est plus récent. Il y a aussi moins d'experts MongoDB que leurs homologues relationnels.

Points souvent mal compris:

  • MongoDB et les bases de données relationnelles prennent en charge l'indexation. Leurs performances de requête sont similaires en termes d'exécution de grandes requêtes.
  • MongoDB ne supprime pas la nécessité de migrations ou plus précisément, la mise à jour de vos données existantes à mesure que votre schéma évolue. Par exemple: si vous avez une application qui s'appuie sur une table d'utilisateurs pour contenir certaines données, et que vous modifiez cette table pour contenir des données différentes (disons que vous ajoutez un champ d'image de profil), alors vous devrez toujours:
    • Écrivez votre application pour gérer les objets pour lesquels cette propriété n'est pas définie OU
    • Écrivez une migration unique pour mettre une valeur par défaut pour cette propriété OU
    • Écrire du code pour fournir une valeur par défaut au moment de la requête si ce champ n'est pas présent OU
    • Gérer le champ manquant d'une autre manière
26
Pace

Pour voler sans vergogne de Renesis (en fait, je fais cette réponse CW):

Utilisation des SGBDR au lieu d'autres types:

13
Matthew Read

Lorsque vos données ne sont pas relationnelles, il peut y avoir des avantages majeurs à utiliser des bases de données NoSQL comme les performances et l'évolutivité (selon les circonstances, bien sûr). Certains modèles de conception tels que CQRS facilitent considérablement l'exploitation des données non relationnelles dans des domaines qui exigeraient classiquement l'utilisation exclusive d'une base de données SQL.

Il est courant d'utiliser des bases de données comme mongo pour les données mises en cache. Par exemple, si vous devez générer un rapport, vous pouvez effectuer une requête SQL compliquée qui joint et agrège un tas de données à la volée, ou vous pouvez simplement extraire un seul document json de votre base de données mongo qui contient déjà tout ce dont vous avez besoin pour générer le rapport. Cela rend la lecture des données vraiment facile (et rapide!), Mais peut rendre l'écriture des données assez compliquée (c'est là qu'intervient le CQRS).

9
Graeme Hill

Les bases de données comme MongoDB sont excellentes lorsque vous savez généralement où se trouvent vos données (au lieu d'avoir besoin d'écrire plusieurs requêtes compliquées). Avec Mongo, les données "liées" sont soit imbriquées dans les données parent, soit elles ont des clés primaires/étrangères. C'est très bien si, par exemple, vous avez des messages et des commentaires; en général, vous n'allez pas afficher de commentaires en dehors du contexte d'une publication, il est donc logique que les commentaires soient contenus dans une publication (de cette façon, vous obtenez tous les commentaires pour la publication sans avoir à interroger une table distincte).

MongoDB est sans schéma. Cela signifie qu'il prendra la structure des données que vous lui lancerez, pour la plupart.

D'un autre côté, si vous devez utiliser des fonctions d'agrégation et ressentez le besoin d'interroger des données de manière complexe qui ne peut pas être obtenue par le biais d'incorporation ou de relations simples dans Mongo, c'est à ce moment que vous savez qu'il est temps d'utiliser un SGBDR comme MySQL ou PostgreSQL.

MongoDB n'est pas destiné à remplacer SQL. Il répond simplement à différents besoins et MongoDB et un SGBDR peuvent être utilisés conjointement. À mon avis, MongoDB n'est pas tout à fait nécessaire si vous n'avez pas besoin que vos données soient flexibles ou intégrées dans un document parent. Le développement avec MongoDB est très amusant car il y a beaucoup moins d'étapes impliquées pour obtenir un projet (disons dans Rails) opérationnel. Besoin de changer? Aucun problème. Ajoutez simplement un attribut à votre modèle. Terminé.

Je ne peux pas parler pour de nombreuses autres bases de données NoSQL, bien que je sache qu'elles sont généralement conçues de manière similaire pour répondre à un besoin spécifique qui ne peut pas être satisfait par un SGBDR. Certains résident entièrement en mémoire ou peuvent être fragmentés ou mis à l'échelle très facilement. Je suis sûr que Cassandra est conçu pour continuer à fonctionner sans perte de données si un nœud tombe en panne. Redis est essentiellement un magasin de valeurs clés qui réside en mémoire (avec des écritures de disque périodiques pour la persistance), mais a également la possibilité de stocker des types de données comme des ensembles et de les trier.

8
Ravenstine

La principale victoire est lorsque vous souhaitez partager des données ou avoir des bases de données multi-maîtres. Vous pouvez partager des données dans MySQL, mais cela se transforme en une difficulté majeure. Si vous effectuez de nombreuses écritures, il est souvent utile de partager les données sur plusieurs serveurs, le problème est que si vous souhaitez avoir une cohérence référentielle forte tout en faisant cela, il peut être très difficile, voire impossible, de rechercher le théorème CAP.

Les bases de données SQL ont une très bonne cohérence mais un support de partitionnement vraiment mauvais, les bases de données NoSQL ont tendance à aller dans l'autre sens. Facile à partitionner mais souvent ce qu'on appelle la cohérence éventuelle. Si vous construisez un site de messagerie qui est ok, pour une banque probablement pas OK.

Le plus est qu'il existe maintenant plusieurs modèles pour stocker les données, il y a donc un choix dans la façon dont vous implémentez les choses, alors qu'auparavant, vous n'aviez que des bases de données SQL.

SE Radio a eu quelques bons épisodes sur ce sujet.

6
Zachary K

MongoDB fonctionne bien lorsque vous écrivez beaucoup de données et lorsque vos besoins en matière de requêtes ne sont pas trop compliqués. Par conséquent, MongoDB est un bon choix lorsque vous implémentez CQRS avec Event Sourcing du côté Commande - c'est-à-dire que votre magasin d'événements est une base de données MongoDB.

Du côté des requêtes, nous utilisons toujours une base de données SQL Server avec des vues et WCF Data Services en haut, en raison de sa flexibilité. Je pense que dans la plupart des cas, vous aurez vraiment besoin de la puissance d'une base de données relationnelle pour interroger.

1
Roy Dictus

La différence immédiate et fondamentale entre MongoDB et un SGBDR est le modèle de données sous-jacent. Une base de données relationnelle structure les données en tables et lignes, tandis que MongoDB structure les données en collections de documents JSON. JSON est un format de données auto-descriptif et lisible par l'homme. Conçu à l'origine pour des échanges légers entre navigateur et serveur, il est devenu largement accepté pour de nombreux types d'applications.

Les documents JSON sont particulièrement utiles pour la gestion des données pour plusieurs raisons. Un document JSON est composé d'un ensemble de champs qui sont eux-mêmes des paires clé-valeur. Cela signifie que chaque document JSON porte sa propre conception de schéma lisible par l'homme partout où il va, permettant aux documents de se déplacer facilement entre la base de données et les applications clientes sans perdre leur sens.

JSON est également un format de données naturel à utiliser dans la couche application. JSON prend en charge une structure de données plus riche et plus flexible que les tables composées de colonnes et de lignes. En plus de prendre en charge les types de champs tels que nombre, chaîne, booléen, etc., les champs JSON peuvent être des tableaux ou des sous-objets imbriqués. Cela signifie que nous pouvons représenter un ensemble de relations sophistiquées qui sont une représentation plus proche des objets avec lesquels nos applications fonctionnent. L'utilisation de documents JSON dans notre base de données signifie que nous n'avons pas besoin d'un mappeur relationnel d'objet entre notre base de données et les applications qu'elle sert. Nous pouvons conserver nos données sous la bonne forme

1
Diwakar upadhyay

Si vos données nécessitent beaucoup de requêtes, une solution NoSQL n'est pas bonne et lorsque vous avez besoin d'un support transactionnel (ACID), un NoSql n'est pas le meilleur choix. Je pense que NoSQL brille lorsque vous avez beaucoup de lectures qui doivent être rapides et lorsque la structure est quelque peu adhoc, vous récupérez par document ou par structure de page, quelque chose comme ça. Mais beaucoup de solutions NoSQL s'améliorent beaucoup assez rapidement, donc les lacunes disparaîtront peut-être bientôt. Quoi qu'il en soit, je pense que les bases de données relationnelles sont toujours adaptées à la plupart des applications.

1
marko