Base de données documentaire ou base de données relationnelle: comment choisir?

Je suis un type SQL, mais je sais qu'il n'y a pas que des bases de données SQL - la base de données de documents principalement. Comme pour la plupart des technologies, il existe des avantages et des inconvénients pour chaque technologie.

J'ai lu quelques articles, mais ils étaient trop théoriques. Ce que je voudrais, ce sont deux cas réels:

quand le passage de la base de données relationnelle à la base de données documentaire a amélioré
quand le passage de la base de données documentaire à la base de données relationnelle a amélioré

L'amélioration étant tout ce qui fait de meilleurs programmes - moins de temps de développement, d'évolutivité, de performances, tout ce qui est lié à la programmation. Il y a une mise en garde pour 2.: des histoires comme "retomber dans la base de données relationnelle parce que tout le monde connaît SQL" n'est pas bonne

nosql relational-database

— Johan Buret
source

Mauvaise approche. Il ne s'agit pas de "performances" ou "d'évolutivité". Il s'agit du modèle qui correspond au problème que vous essayez de résoudre. Vous voudrez peut-être mettre à jour votre question pour permettre l'idée que la base de données relationnelle n'est peut-être pas adaptée à de nombreux types de problèmes.

— S.Lott

@ S.Lott, le choix est souvent celui de la performance. considérez que toute base de données relationnelle peut être utilisée comme une simple base de données de document - seule la performance serait une caractéristique distinctive.

— edA-qa mort-ora-y

J'ai reformulé ma question pour qu'elle ne soit pas chargée du tout.

— Johan Buret

@ edA-qa mort-ora-y: "toute base de données relationnelle peut être utilisée comme une simple base de documents". Cela doit être faux, sinon les gens n'auraient pas inventé d'alternative. "seule la performance serait une caractéristique distinctive". Seulement vrai si vous supposez que le modèle relationnel fait tout aussi bien. S'il faisait tout, il n'y aurait pas d'alternative. Encore. Nous avons des alternatives. Il y a beaucoup de problèmes (comme les hiérarchies) qui ne correspondent pas au modèle relationnel parfaitement bien , et nécessitent des trucs intelligents. Ou un autre modèle de données.

— S.Lott

"lire quelques articles"? Veuillez fournir quelques liens ou titres ou références ou citations. Nous ne savons pas ce que "trop théorique" signifie pour vous.

— S.Lott

Réponses:

La principale raison du choix d'une base de données NoSQL ces dernières années a été la disponibilité . Pour des entreprises comme Amazon, Google et Facebook, une heure d'indisponibilité n'est pas acceptable. Pour atteindre une haute disponibilité, vous devez réduire le point de défaillance unique, ce qui signifie que vous devez utiliser un système distribué avec plusieurs ordinateurs en cas de panne d'un ordinateur, le service est toujours disponible.

Les bases de données Relatione traditionnelles ne sont pas très bonnes dans une configuration multi-maîtres distribuée. C'est pourquoi NoSQL a été si populaire ces derniers temps. Donc, si vous avez besoin d'une haute disponibilité, vous pouvez choisir une base de données NoSQL comme Riak, Cassandra, HBase, S3 ou BigTable.

Il y a un bon article de blog sur Dynamo d'Amazon qui est une bonne introduction aux bases de données NoSQL distribuées.

Maintenant, le terme NoSQL est très large, il existe donc de nombreuses bases de données NoSQL qui ne sont pas distribuées. Mais ils résolvent d'autres problèmes. Par exemple, Neo4j - une base de données de graphiques convient à un type de requêtes pour lesquelles le SGBDR traditionnel n'est pas optimisé. Ou comme dans votre cas, une base de données de documents, où vous n'avez pas à modifier le schéma si vous souhaitez ajouter des champs pour certains documents. En d'autres termes, une base de données de documents est bonne lorsque la plupart des publications (documents) ont des champs différents, donc une table relationnelle avec des colonnes prédéfinies n'est pas utilisable.

Cependant, la plupart des bases de données NoSQL ne sont pas aussi flexibles que les bases de données RDBMS traditionnelles, c'est donc un bon choix d'utiliser une base de données RDBMS traditionnelle jusqu'à ce qu'elle ne puisse plus résoudre vos problèmes.

— Jonas
source

+1, D'accord, la flexibilité est un prix énorme à payer si vous n'en avez pas besoin.

— maple_shaft

J'ai une approche simple pour déterminer la base de données qui correspond le mieux aux données.

Je me demande simplement: en supposant que je n'aurais pas de base de données, est-ce que je préfère enregistrer le plus et les données importantes en tant que document ou les stocker dans une feuille de calcul.

Lorsque la réponse est "Feuille de calcul", cela indique clairement qu'un modèle relationnel et un SGBDR traditionnel conviennent le mieux aux tâches la plupart du temps. Si les données sont vraiment simples, comme seulement les paires de valeurs clés ou les tables simples et que l'intégrité référentielle n'est pas un sujet, alors une base de données NoSQL est probablement la mieux adaptée à la tâche et pourrait augmenter considérablement les performances!

De plus, lorsque vous ne trouvez pas du tout de structure commune, une base de données NoSQL est la mieux adaptée à la tâche.

Lorsque les données ressemblent davantage à des documents, par exemple des données textuelles structurées hiérarchiquement sans relations claires, je pense immédiatement à une base de données XML, qui vous permet facilement de stocker des documents structurés hiérarchiques. Parfois, il est préférable d'utiliser un logiciel de gestion de documents.

Donc, afin de donner une réponse concrète et simple à vos deux questions: Cela dépend des données.

quand le passage de la base de données relationnelle à la base de données documentaire a amélioré

Lorsque vous devez conserver des données textuelles structurées de manière hiérarchique, une base de données Xml peut être une grande amélioration en termes de maintenabilité et probablement aussi d'évolutivité.

quand le passage de la base de données documentaire à la base de données relationnelle a amélioré

Eh bien, par exemple lorsque les données sont principalement sous forme de tableau avec des relations claires et que vous devez garantir l'intégrité.

— Faucon
source

+1 pour la feuille de calcul par rapport à l'analogie du document - grande aide - merci.

— HDave

Nous avons dû abandonner le modèle relationnel car les données que nous obtenions n'avaient pas de schéma statique simple, évident, fixe.

Les utilisateurs - et les user stories - n'avaient pas de schéma statique fixe.

Nous avons essayé d'imposer un schéma RDBMS fixe et statique, mais c'était une erreur.

Chaque livraison de données tierces (provenant de clients et de fournisseurs) était similaire, mais pas identique. Nous avons essayé de le mapper à un schéma relationnel fixe, mais la variabilité était trop grande. Soit nous devions ajouter des champs à chaque fichier (plusieurs par semaine), soit nous devions nous éloigner du schéma relationnel fixe et statique.

Si nous considérions chaque enregistrement comme un «document» avec un sous - ensemble commun d'éléments et une collection unique (ainsi que mal définie) d'éléments de données supplémentaires, nous étions beaucoup, beaucoup plus heureux.

La collection mal définie d'éléments de données est ce dont les utilisateurs avaient réellement besoin pour leurs cas d'utilisation.

Le schéma fixe et statique du modèle relationnel ne correspondait pas à nos cas d'utilisation.

— S.Lott
source

J'ai vu d'autres projets ne pas répondre aux exigences en raison exactement des exigences que vous avez décrites. C'est à cela que les bases de données de documents étaient destinées.

— maple_shaft