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
la source
la source
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.
la source
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.
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é.
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é.
la source
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.
la source