Quels sont les avantages d'utiliser une base de données sans schéma comme MongoDB par rapport à une base de données relationnelle?

J'ai l'habitude d'utiliser des bases de données relationnelles comme MySQL ou PostgreSQL, et combinées avec des frameworks MVC tels que Symfony, RoR ou Django, et je pense que cela fonctionne très bien.

Mais récemment, j'ai beaucoup entendu parler de MongoDB qui est une base de données non relationnelle, ou, pour citer la définition officielle ,

une base de données évolutive, haute performance, open source, sans schéma et orientée document.

Je suis vraiment intéressé à être à la pointe et je veux être au courant de toutes les options que j'aurai pour un prochain projet et choisir les meilleures technologies disponibles.

Dans quels cas l'utilisation de MongoDB (ou de bases de données similaires) est-elle meilleure que d'utiliser une base de données relationnelle «classique»? Et quels sont les avantages de MongoDB par rapport à MySQL en général? Ou du moins, pourquoi est-ce si différent?

Si vous avez des pointeurs vers de la documentation et / ou des exemples, ce serait également d'une grande aide.

Voici quelques-uns des avantages de MongoDB pour la création d'applications Web:

1. Un modèle de données basé sur des documents. L'unité de stockage de base est analogue à JSON, aux dictionnaires Python, aux hachages Ruby, etc. Il s'agit d'une structure de données riche capable de contenir des tableaux et d'autres documents. Cela signifie que vous pouvez souvent représenter dans une seule entité une construction qui nécessiterait plusieurs tables pour être correctement représentée dans une base de données relationnelle. Ceci est particulièrement utile si vos données sont immuables.
2. Capacité de requête approfondie. MongoDB prend en charge les requêtes dynamiques sur des documents à l'aide d'un langage de requête basé sur des documents presque aussi puissant que SQL.
3. Aucune migration de schéma. Étant donné que MongoDB est sans schéma, votre code définit votre schéma.
4. Une voie claire vers l'évolutivité horizontale.

Vous aurez besoin d'en savoir plus à ce sujet et de jouer avec pour avoir une meilleure idée. Voici une démo en ligne:

http://try.mongodb.org/

Les avantages sont nombreux.

Par exemple, votre schéma de base de données sera plus évolutif, vous n'aurez pas à vous soucier des migrations, le code sera plus agréable à écrire ... Par exemple, voici l'un des codes de mon modèle:

class Setting
  include MongoMapper::Document

  key :news_search, String, :required => true
  key :is_availaible_for_iphone, :required => true, :default => false

  belongs_to :movie
end

Ajouter une clé, c'est simplement ajouter une ligne de code!

Il y a aussi d'autres avantages qui apparaîtront à long terme, comme une meilleure scallabilité et une meilleure vitesse.

... Mais gardez à l'esprit qu'une base de données non relationnelle n'est pas meilleure qu'une base de données relationnelle . Si votre base de données a beaucoup de relations et de normalisation, il peut être inutile d'utiliser quelque chose comme MongoDB. Il s'agit de trouver le bon outil pour le travail.

Pour plus de choses à lire, je vous recommande de jeter un œil à " Pourquoi je pense que Mongo est aux bases de données ce que Rails était aux Frameworks " ou à ce post sur le site Web de mongodb. Pour vous enthousiasmer et si vous parlez français, jetez un œil à cet article expliquant comment configurer MongoDB à partir de zéro.

Edit: J'ai presque oublié de vous parler de ce railscast de Ryan . C'est très intéressant et donne envie de commencer tout de suite!

L'avantage du sans schéma est que vous pouvez vider tout ce que votre charge contient, et personne n'aura jamais de raison de s'en plaindre ou de dire que c'était faux.

Cela signifie également que tout ce que vous y jetez reste totalement vide de sens une fois que vous l'avez fait.

Certains qualifieraient cela de grave désavantage, d'autres non.

Le fait qu'une base de données relationnelle ait un schéma bien établi, est une conséquence du fait qu'elle a un ensemble bien établi de prédicats d'extension, qui sont ce qui nous permet d'attacher un sens à ce qui est enregistré dans la base de données, et qui sont également une condition préalable nécessaire pour que nous le fassions.

Sans un schéma bien établi, pas de prédicats d'extension, et sans précicates d'extension, aucun moyen pour l'utilisateur de donner un sens à ce qui s'y trouvait.

MongoDB a été présenté sur FLOSS Weekly cette semaine - http://twit.tv/floss105 Une base de données utilisant un concept similaire est CouchDB qui a été présentée sur un autre FLOSS Weekly: http://twit.tv/floss36

Je pense que cela vaut la peine de les écouter en plus des liens fournis par @marcgg

Mon expérience avec Postgres et Mongo après avoir travaillé avec les deux bases de données dans mes projets.

Postgres (SGBDR)

Postgres est recommandé si vos futures applications ont un schéma compliqué qui nécessite beaucoup de jointures ou si toutes les données ont des relations ou si nous avons une écriture lourde. Postgres est open source, plus rapide, conforme à ACID et utilise moins de mémoire sur le disque, et est tout à fait performant pour le stockage JSON également et comprend une sérialisation complète des transactions avec 3 niveaux d'isolation des transactions.

Le plus grand avantage de rester avec Postgres est que nous avons le meilleur des deux mondes. Nous pouvons stocker des données dans JSONB avec des contraintes, de la cohérence et de la vitesse. D'autre part, nous pouvons utiliser toutes les fonctionnalités SQL pour d'autres types de données. Le moteur sous-jacent est très stable et s'adapte bien à une bonne gamme de volumes de données. Il fonctionne également sur votre choix de matériel et de système d'exploitation. Postgres fournit des capacités NoSQL ainsi qu'une prise en charge complète des transactions, stockant des documents JSON avec des contraintes sur les données des champs.

Contraintes générales pour Postgres

La mise à l'échelle horizontale de Postgres est beaucoup plus difficile, mais faisable.

Les opérations de lecture rapide ne peuvent pas être entièrement réalisées avec Postgres.

PAS de bases de données SQL

Mongo DB (Tigre filaire)

MongoDB peut battre Postgres dans la dimension de «l'échelle horizontale». Le stockage JSON est ce pour quoi Mongo est optimisé. Mongo stocke ses données dans un format binaire appelé BSONb qui est (à peu près) juste une représentation binaire d'un sur-ensemble de JSON. MongoDB stocke les objets exactement comme ils ont été conçus. Selon MongoDB, pour les applications gourmandes en écriture, Mongo affirme que le nouveau moteur (Wired Tiger) offre aux utilisateurs une augmentation jusqu'à 10 fois des performances d'écriture (je devrais essayer ceci), avec une réduction de 80% de l'utilisation du stockage, ce qui contribue à réduire les coûts de stockage. , atteindre une plus grande utilisation du matériel.

Contraintes générales de MongoDb

L'utilisation d'un moteur de stockage sans schéma pose le problème des schémas implicites. Ces schémas ne sont pas définis par notre moteur de stockage, mais sont définis en fonction du comportement et des attentes de l'application.

Les technologies NoSQL autonomes ne répondent pas aux normes ACID car elles sacrifient les protections des données critiques au profit de performances à haut débit pour les applications non structurées. Il n'est pas difficile d'appliquer ACID sur les bases de données NoSQL, mais cela rendrait la base de données lente et rigide dans une certaine mesure. «La plupart des limitations de NoSQL ont été optimisées dans les nouvelles versions et versions qui ont largement surmonté ses limitations précédentes».

Tout est question de compromis. MongoDB est rapide mais pas ACID, il n'a pas de transactions. C'est mieux que MySQL dans certains cas d'utilisation et pire dans d'autres.

Ci-dessous les lignes écrites dans MongoDB: le guide définitif.

Il y a plusieurs bonnes raisons:

1. Conserver différents types de documents dans la même collection peut être un cauchemar pour les développeurs et les administrateurs. Les développeurs doivent s'assurer que chaque requête ne renvoie que des documents d'un certain type ou que le code d'application exécutant une requête peut gérer des documents de formes différentes. Si nous recherchons des articles de blog, il est difficile d'éliminer les documents contenant des données d'auteur.
2. Il est beaucoup plus rapide d'obtenir une liste de collections que d'extraire une liste des types d'une collection. Par exemple, si nous avions une clé de type dans la collection qui indiquait si chaque document était un document «skim», «entier» ou «chunky monkey», il serait beaucoup plus lent de trouver ces trois valeurs dans une seule collection que de avoir trois collections distinctes et interroger leurs noms
3. Le regroupement de documents de même nature dans la même collection permet la localisation des données. Obtenir plusieurs articles de blog à partir d'une collection contenant uniquement des articles nécessitera probablement moins de recherches sur le disque que d'obtenir les mêmes articles à partir d'une collection contenant des articles et des données d'auteur.
4. Nous commençons à imposer une certaine structure à nos documents lorsque nous créons des index. (Ceci est particulièrement vrai dans le cas d'index uniques.) Ces index sont définis par collection. En ne plaçant que des documents d'un seul type dans la même collection, nous pouvons indexer nos collections plus efficacement

Après une question de bases de données avec stockage textuel), j'ai jeté un coup d'œil sur MongoDB et des systèmes similaires.
Si j'ai bien compris, ils sont censés être plus faciles à utiliser et à configurer, et beaucoup plus rapides. Peut-être aussi plus sécurisé car le manque de SQL empêche l'injection SQL ...
Apparemment, MongoDB est principalement utilisé pour les applications Web.
Fondamentalement, et ils affirment qu'eux-mêmes, ces bases de données ne sont pas adaptées aux requêtes complexes, à l'exploration de données, etc. Mais elles brillent pour récupérer rapidement de nombreuses données plates.

1. MongoDB prend en charge la recherche par champs, les recherches d'expressions régulières, ainsi que les fonctions de script Java définies par l'utilisateur.
2. MongoDB peut être utilisé comme système de fichiers, tirant parti des fonctionnalités d'équilibrage de charge et de réplication de données sur plusieurs machines pour stocker des fichiers.