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

188

Pourquoi devrais-je utiliser une base de données basée sur des documents comme CouchDB au lieu d'utiliser une base de données relationnelle. Existe-t-il des types typiques d'applications ou de domaines dans lesquels la base de données documentaire est plus appropriée que la base de données relationnelle?

Bartosz Blimke
la source
Peut-être qu'une base de données orientée document pourrait être similaire à certains égards à une base de données "entité-attribut-valeur" (EAV).
ChrisW

Réponses:

167

Vous ne devriez probablement pas :-)

La deuxième réponse la plus évidente est que vous devriez l'utiliser si vos données ne sont pas relationnelles. Cela se manifeste généralement par l'absence de moyen simple de décrire vos données comme un ensemble de colonnes. Un bon exemple est une base de données dans laquelle vous stockez réellement des documents papier, par exemple en scannant le courrier de bureau. Les données sont le PDF numérisé et vous avez des métadonnées qui existent toujours (numérisées à, numérisées par, type de document) et de nombreux champs de métadonnées possibles qui existent parfois (numéro de client, numéro de fournisseur, numéro de commande, conservez-les jusqu'à ce que, Texte intégral OCR, etc.). En général, vous ne savez pas à l'avance quels champs de métadonnées vous allez ajouter au cours des deux prochaines années. Des choses comme CouchDB fonctionnent beaucoup plus bien pour ce type de données que les bases de données relationnelles.

J'aime aussi personnellement le fait que je n'ai pas besoin de bibliothèques clientes pour CouchDB à l'exception d'un client HTTP, qui est aujourd'hui inclus dans presque tous les langages de programmation.

La réponse probablement la moins évidente: si vous ne ressentez aucune douleur en utilisant un SGBDR, restez avec lui. Si vous devez toujours travailler autour de votre SGBDR pour faire votre travail, une base de données orientée document pourrait valoir le coup d'œil.

Pour une liste plus élaborée, consultez cette publication de Richard Jones .

max
la source
1
Je n'ai jamais vu de schéma de base de données en deux ans ressembler au schéma original avec lequel nous avons commencé ... donc tout est égal (ce qui n'est pas ...), vous devriez toujours utiliser une base de données sans schéma = une base de données orientée document; ce qui, à
mon
3
@ int3 Si vous ne pouvez pas décrire vos données comme un ensemble de colonnes, comment êtes-vous censé écrire des requêtes intelligentes sur ces données?
Clay Smith
46

CouchDB (depuis leur site Web )

  • Un serveur de base de données de documents, accessible via une API JSON RESTful. En règle générale, les bases de données relationnelles ne sont pas simplement accessibles via les services REST, mais nécessitent une API SQL beaucoup plus complexe. Souvent, ces API (JDBC, ODBC, etc.) sont assez complexes. REST est assez simple.

  • Ad-hoc et sans schéma avec un espace d'adressage plat. Les bases de données relationnelles ont un schéma complexe et fixe. Vous définissez des tables, des colonnes, des index, des séquences, des vues et d'autres choses. Couch ne nécessite pas ce niveau de planification avancée complexe, coûteuse et fragile.

  • Distribué, avec réplication incrémentielle robuste avec détection et gestion bidirectionnelle des conflits. Certains produits commerciaux SQL offrent cela. En raison de l'API SQL et des schémas fixes, cela est complexe, difficile et coûteux. Pour Couch, cela semble simple et peu coûteux.

  • Interrogable et indexable, avec un moteur de création de rapports orienté table qui utilise Javascript comme langage de requête. Il en va de même pour SQL et les bases de données relationnelles. Rien de nouveau ici.

Alors. Pourquoi CouchDB?

  • REST est plus simple que JDBC ou ODBC.
  • Aucun schéma n'est plus simple que le schéma.
  • Distribué d'une manière qui semble simple et peu coûteuse.
S.Lott
la source
12
Bien que je sois un grand fan des bases de données NoSQL, la première affirmation (REST est plus simple que JDBC) est très douteuse.
ᆼ ᆺ ᆼ
2
Le protocole REST me semble assez simple, puisqu'il ne s'agit que de HTTP: sans état, peu de méthodes, etc., etc. Peut-être que JDBC est (sous le capot) simple; cela ne semble pas être plus simple, basé simplement sur le fait d'être avec état.
S.Lott
5
@ S.Lott La réponse ne devrait-elle pas être plus «générique» que centrée uniquement sur CouchDb?
Pacerier
"planification avancée fragile" vs quoi? D'après mon expérience, l'alternative est la non-planification, ce qui conduit à des structures de données spaghetti modifiées sur un coup de tête.
Tejay Cardon
26

Pour stocker et servir stupidement les données d'autres serveurs.

Ces dernières semaines, j'ai joué avec une application lifestream qui interroge mes flux (délicieux, flickr, github, twitter ...) et les stocke dans couchdb. La beauté de couchdb est qu'il me permet de conserver les données d'origine dans leur structure d'origine sans frais généraux. J'ai ajouté un champ «classe» à chaque document, stockant le serveur source, et j'ai écrit une classe de rendu javascript pour chaque source.

En général, chaque fois que votre serveur communique avec un autre serveur, un stockage sans schéma est préférable car vous n'avez aucun contrôle sur le schéma. En prime, couchdb utilise les protocoles natifs des serveurs et des clients - JSON pour la représentation et HTTP REST pour le transport.

daonb
la source
Pourquoi ne pas simplement les stocker dans un fichier, ou un fichier par flux?
j_random_hacker
6
car couchdb vous permet également de créer des vues intéressantes en utilisant map / Reduce. Par exemple, je peux créer une vue basée sur la source de données, ou je peux calculer les totaux pour chaque source.
daonb
4
C'est un point brillant ... si vous consommez des données et n'avez aucun contrôle sur le schéma de données entrantes, utilisez un magasin de documents.
Joshua Robinson
1
C'est le premier argument vraiment convaincant que j'ai entendu pour la valeur des bases de données NoSQL
Caleb McNevin
20

Le développement rapide des applications vient à l'esprit.

Lorsque j'évolue constamment mon schéma, je suis constamment frustré de devoir maintenir le schéma dans MySQL / SQLite. Bien que je n'ai pas encore fait trop avec CouchDB, j'aime la simplicité de l'évolution du schéma pendant le processus RAD.

Un cas où vous ne voudrez peut-être pas utiliser une base de données non relationnelle est lorsque vous avez beaucoup de relations plusieurs-à-plusieurs; Je n'ai pas encore compris comment créer de bonnes fonctions MapReduce autour de ces types de relations, en particulier si vous avez besoin de métadonnées dans la relation de jonction. Je ne suis pas sûr, mais je ne pense pas que les fonctions CouchDB Map peuvent appeler leurs propres requêtes sur la base de données, car cela pourrait potentiellement provoquer des boucles infinies.

pixelcort
la source
1
Excellent point. Les banques de données de documents (et autres banques de données sans schéma) sont idéales pour un développement rapide à un stade précoce. Cependant, pour les mêmes raisons, ils sont parfaits pour le prototypage précoce, ils sont problématiques pour les applications de production robustes.
Tejay Cardon
6

Utilisez une base de données documentaire lorsque vous n'avez pas besoin de stocker des données dans des tables avec des champs de taille uniforme pour chaque enregistrement. Au lieu de cela, vous devez stocker chaque enregistrement comme un document présentant certaines caractéristiques. N'importe quel nombre de champs de n'importe quelle longueur peut être ajouté dynamiquement à un document à tout moment sans qu'il soit nécessaire de «modifier la table» au préalable. Les champs basés sur des documents peuvent également contenir plusieurs éléments de données.

smdelfin
la source
1

Pour élaborer sur smdelfin: flexibilité. Vous pouvez stocker des données dans n'importe quelle structure (étant non structurée et tout) et chaque document peut être complètement différent. CouchDB est particulièrement utile car avec leurs index de «vue», vous pouvez filtrer des documents spécifiques et interroger uniquement cette vue lorsque vous voulez ces sous-ensembles de votre base de données.

Mon plus gros point gagnant des bases de données documentaires qui stockent des données au format JSON: c'est le format natif de JavaScript. Par conséquent, les applications Web JavaScript fonctionnent incroyablement bien avec CouchDB. J'ai récemment créé une application Web qui utilise CouchDB et elle est très rapide tout en étant capable de gérer une structure de données qui varie constamment.

MitchB
la source
0

Les bases de données basées sur des documents ont un gros avantage par rapport aux bases de données relationnelles car elles ne nécessitent pas de définir un schéma à l'avance - avant de pouvoir entrer des données.

En outre, vous devez utiliser une base de données de documents si vos données ne sont pas relationnelles et ne peuvent pas être stockées dans une table mais sont plutôt un ensemble d'images, ou par exemple des articles de journaux.

Un autre avantage est la facilité d'utilisation des bases de données documentaires dans le développement Web. Pour plus de détails sur les modèles de base de données NoSQL, consultez cette source: https://arxiv.org/ftp/arxiv/papers/1509/1509.08035.pdf

evidrascu
la source