Sont des bases de données orientées document destinées à remplacer les bases de données relationnelles?

Question

Récemment, je travaille un peu avec MongoDB et je dois dire que je l'aime vraiment. Cependant, il est un type de base de données complètement différent alors je suis habitué. Je l'ai remarqué qu'il est très certainement mieux pour certains types de données, mais pour les bases de données fortement normalisé, il pourrait ne pas être le meilleur choix.

Il me semble cependant qu'il peut tout à fait prendre la place d'à peu près toute base de données relationnelle que vous pourriez avoir et dans la plupart des cas de meilleures performances, ce qui est ahurissant. Cela conduit à me poser quelques questions:

1. sont des bases de données orientées document en cours d'élaboration pour la prochaine génération de bases de données et remplacer essentiellement des bases de données relationnelles complètement?
2. Est-il possible que les projets seraient mieux à l'aide à la fois une base de données orientée document et un côté de base de données relationnelle côte à côte pour diverses données qui sont mieux adaptés à l'un ou l'autre?
3. Si les bases de données orientées document ne sont pas destinées à remplacer les bases de données relationnelles, alors que quelqu'un a un exemple d'une structure de base de données qui serait tout à fait mieux dans une base de données relationnelle (ou vice-versa)?

Answer 1

  

sont des bases de données orientées document ont été développés pour être la prochaine génération de bases de données et remplacer essentiellement des bases de données relationnelles complètement?

Non

. bases de données orientées document (comme MongoDB) sont très bons au type de tâches que nous voyons habituellement dans des sites Web modernes (Look-up rapide d'articles individuels ou de petits ensembles d'objets).

Mais ils font des grands compromis avec les systèmes relationnels. Sans des choses comme ACID la conformité qu'ils ne vont pas être en mesure de remplacer certains SGBDR. Et si vous regardez des systèmes comme MongoDB, le manque d'acide conformité est une grande raison pour laquelle il est si rapide.

  

Est-il possible que les projets seraient mieux à l'aide à la fois une base de données orientée document et un côté de base de données relationnelle côte à côte pour diverses données qui sont mieux adaptés à l'un ou l'autre?

Oui. En fait, je suis en cours d'exécution d'un site web très grande production qui utilise à la fois. Le système a été lancé en MySQL, mais nous avons migré une partie de celui-ci vers MongoDB, b / c nous avons besoin d'un magasin valeur-clé et MySQL est tout simplement pas très bon pour trouver un élément dans un 150M enregistrements.

  

Si les bases de données orientées document ne sont pas destinées à remplacer les bases de données relationnelles, alors que quelqu'un a un exemple d'une structure de base de données qui serait tout à fait mieux dans une base de données relationnelle (ou vice-versa)?

bases de données orientées document sont grandes données de stockage qui est facilement contenue dans la "valeur de clé" et simple, linéaire "relations parent-enfant". Des exemples simples ici sont des choses comme les blogs et les Wikis.

Cependant, bases de données relationnelles ont encore une jambe forte sur des choses comme des rapports, qui tend à être « basé sur un ensemble ».

Honnêtement, je peux voir un monde où la plupart des données sont « traitées » par base de données orientée documents, mais où la déclaration est effectuée dans une base de données relationnelle qui est mis à jour par carte-réduire les emplois.

Answer 2

Ceci est vraiment une question d'aptitude à.

Si vous voulez être en mesure de se joindre quelques tables ensemble et retourner un ensemble filtré des résultats, vous ne pouvez le faire avec une base de données relationnelle. Si vous voulez des performances hallucinantes et ont des volumes incroyables de données, qui est lorsque la colonne familiale ou les bases de données orientées document sont dans leur propre.

Ceci est un classique compromis. bases de données relationnelles vous offrent toute une série de caractéristiques, qui est livré avec un coût de performance. Si vous ne pouvez joindre, index, analyse ou d'effectuer toute une autre liste de fonctionnalités, vous supprimez la nécessité d'avoir une vue sur les données ALL, ce qui vous donne la performance et la distribution dont vous avez besoin crunch données sérieuses.

En outre, je vous recommande de suivre les blogs de Ayende Rahien sur ce sujet.

http://ayende.com/blog/

Answer 3

@Sohnee est sur place. Je pourrais ajouter que les bases de données relationnelles

• sont excellents pour la récupération des informations dans des combinaisons inattendues - même si parfois que mène à la mauvaise idée de rapports complets en cours d'exécution sur les systèmes de production sensibles au facteur temps plutôt que sur un entrepôt de données séparée
.
• sont une technologie mature où vous pouvez facilement trouver du personnel et bien des solutions testées à un certain nombre de problèmes (y compris les limites du modèle relationnel, ainsi que la mise en œuvre imparfaite qui est SQL).

Demandez-vous ce que vous voulez faire, et ce que qualités sont importantes pour vous. Vous pouvez faire de la programmation de tout ce qui concerne dans les scripts shell. Veux-tu?

Answer 4

Je continue à poser la même question, qui est ce qui m'a atterri ici. Je l'utilise aussi bien MySQL et MongoDB (pas en tandem actuellement, bien que son idée). Je dois dire honnêtement que je suis très heureux de ne jamais toucher à nouveau MySQL. Bien sûr, il y a le respect « acide », mais avez-vous déjà rencontré la nécessité de réparer vos tables avec MySQL? Avez-vous déjà eu une base de données corrompue? Ça arrive. Avez-vous déjà eu d'autres problèmes avec MySQL? Tous les arguments de verrouillage ou verrous morts? Un problème avec le regroupement? Comment était-il facile à installer et à configurer?

MongoDB ... Vous allumez-le et il est fait .... Ensuite, il est autosharding. Il est incroyablement simple et il est aussi incroyablement rapide. Alors, pensez à ce sujet. Votre temps.

Non, ils n'ont pas JOIN mais il est tout à fait une déclaration inexact de dire qu'il escompte plus de 99% des besoins de gestion des données. Je reçois souvent l'opposition en essayant d'expliquer MongoDB, les gens même ricaner. Avouons-le simplement. Les gens ne veulent pas apprendre de nouvelles choses et ils pensent que ce qu'ils savent est tout ce dont ils ont besoin. Bien sûr, vous pouvez vous en utilisant MySQL le reste de votre vie et construire vos sites Web. Il fonctionne, nous savons que cela fonctionne. Nous savons aussi qu'il échoue. Si elle n'a pas, vous ne demanderiez jamais la question et nous voyons serait probablement pas tant de bases de données orientées document. Nous savons que oui elle est redimensionnée mais il est une douleur à l'arrière pour l'escalader.

permettent également Eliminons la circulation et mise à l'échelle de l'image. Sortez la configuration. Maintenant, concentrons-nous sur l'utilisation. Quelle est votre expérience lors de l'utilisation de MySQL? Comment êtes-vous avec l'architecture serveur MySQL et des requêtes efficaces? Combien de temps passez-vous à la recherche sur les requêtes avec EXPLIQUER? Combien de temps passez-vous faire des diagrammes de schéma? ... Je dis Retire ça de temps. Il est mieux dépensé ailleurs.

Ce sont mes deux cents. Je fais vraiment l'amour MongoDB et l'espoir de ne jamais utiliser MySQL à nouveau et pour le type de sites web que je construis, il est très possible que je ne aurai pas besoin. Bien que j'essaie toujours de savoir quand je veux utiliser MySQL sur MongoDB, pas quand je peux (avouons-le, il stocke les données, félicitations, je pourrais écrire une tonne de fichiers XML aussi, mais ce n'est pas une bonne idée) , mais quand il bénéficierait d'utiliser l'un ou l'autre. En attendant, je vais faire mon travail avec MongoDB et ont moins de maux de tête.

Answer 5

Tant que vous n'avez pas besoin des transactions multi-objets, MongoDB peut être un remplacement favorable à un SGBDR, en particulier dans un contexte d'application Web. Vitesse, schemalessness, et la modélisation de documents sont utiles ce domaine.

Answer 6

Dans mes bases de données orientées document d'opinion ne sont bons pour

1. Les bases de données dont les données sont mieux représentés en utilisant un modèle hiérarchique (arbre). Ce n'est pas commun pour les bases de données du site.
2. Bases de données avec une énorme quantité de données telles que les bases de données Facebook et Amazon. Dans ce cas, il est nécessaire de sacrifier les avantages du modèle relationnel.

Answer 7

AFAIK, les bases de données de documents ne pas JOIN. C'est à peu près un show-bouchon pour> 99% des besoins de gestion des données.

Comme Matthew Flaschen souligne dans les commentaires, même sur le bureau, bases de données telles que SQLite introduisent la sémantique SQL dans les zones qui ont traditionnellement utilisé les formats de fichiers de propriété ou XML.