Existe-t-il de réels avantages à NoSQL par rapport au SGBDR pour les données structurées sur une machine?
Je me suis donc efforcé de déterminer si NoSQL apportait vraiment cette valeur en dehors du taillage automatique et du traitement des données non structurées.
En supposant que je puisse adapter mes données STRUCTURED sur une seule machine OR possède une fonctionnalité efficace de «partage automatique» pour SQL, quels sont les avantages des options NoSQL? J'ai déterminé ce qui suit:
Basé sur les documents (MongoDB, Couchbase, etc.) - En dehors de ses capacités de «découpage automatique», j'ai du mal à comprendre où se trouve l'avantage. Les objets liés sont assez similaires aux jointures SQL, tandis que les objets incorporés volent considérablement en taille de document et posent un défi en termes de réplication (un commentaire peut appartenir à la fois à un utilisateur ET à un utilisateur, et les données seraient donc redondantes). En outre, la perte d’ACID et les transactions sont un gros désavantage.
Basé sur la valeur de la clé (Redis, Memcached, etc.) - Sert un cas d'utilisation différent, idéal pour la mise en cache mais pas pour les requêtes complexes
Columnar (Cassandra, HBase, etc.) - On dirait que le gros avantage ici est davantage la façon dont les données sont stockées sur disque, et surtout utile pour les agrégations plutôt que pour une utilisation générale
Graph (Neo4j, OrientDB, etc.) - Le plus intriguant, l'utilisation à la fois d'arêtes et de nœuds constitue une proposition de valeur intéressante, mais surtout utile pour des données relationnelles très complexes plutôt que pour une utilisation générale.
Je peux voir les avantages des bases de données Key-value, Columnar et Graph pour des cas d'utilisation spécifiques (mise en cache, mappage de la relation de réseau social, agrégations), mais je ne vois aucune raison d'utiliser quelque chose comme MongoDB pour des données STRUCTURÉES en dehors de son environnement. partage des capacités.
Si SQL possède une capacité similaire de «partage automatique», SQL serait-il une évidence pour les données structurées? Il me semble que ce serait le cas, mais j'aimerais connaître l'opinion des communautés ...
REMARQUE: Ceci concerne une application CRUD typique telle qu'un réseau social, un site de commerce électronique, un CMS, etc.
Stockage sans schéma (ou sans schéma). Possibilité de modifier le stockage (essentiellement d'ajouter de nouveaux champs aux enregistrements) sans avoir à modifier le schéma de stockage «déclaré». Les SGBDR nécessitent la déclaration explicite de ces "champs" et nécessitent des modifications explicites du schéma avant qu'un nouveau "champ" ne soit enregistré. Un moteur de stockage sans schéma permet des modifications rapides de l'application, il suffit de modifier le code de l'application pour enregistrer les champs supplémentaires, ou de renommer les champs, ou de supprimer des champs et de le faire.
Les SGBDR traditionnels considèrent le système sans schéma comme un inconvénient, car ils soutiennent qu’à long terme, il faut interroger le stockage et gérer les enregistrements hétérogènes (certains ont certains champs, d’autres ont), ce qui le rend difficile à gérer. Mais pour une start-up, l'absence de schéma est extrêmement séduisante, car la rapidité de son itération et sa mise sur le marché sont tout ce qui compte (et souvent à juste titre).
Vous nous avez demandé de supposer que les données peuvent tenir sur une seule machine, OR, votre base de données possède une fonctionnalité de partage automatique efficace.
En supposant que vos données SQL disposent d'une fonctionnalité de partage automatique, cela signifie que vous parlez d'exécuter un cluster. Chaque fois que vous utilisez un cluster de machines, vous devez vous soucier de la tolérance aux pannes.
Supposons, par exemple, que vous utilisiez la méthode la plus simple pour partager vos données par fonction d'application et que vous stockiez toutes vos données de compte d'utilisateur sur le serveur A et votre catalogue de produits sur le serveur B.
Est-ce acceptable pour votre entreprise si le serveur A tombe en panne et qu'aucun de vos utilisateurs ne peut se connecter?
Est-ce acceptable pour votre entreprise si le serveur B tombe en panne et que personne ne peut acheter quelque chose?
Sinon, vous devez vous préoccuper de la configuration de la réplication des données et du basculement à haute disponibilité. Faisable, mais pas agréable ou facile pour les bases de données SQL. D'autres types de stratégies de partage (clé, service de recherche, etc.) présentent les mêmes problèmes.
De nombreuses bases de données NoSQL géreront automatiquement la réplication et les basculements. Certains le feront hors de la boîte, avec très peu de configuration. C'est un avantage énorme d'un point de vue opérationnel.
Description complète: je suis un ingénieur chez FoundationDB, une base de données NoSQL qui automatiquement gère le partage, la réplication et le basculement avec très peu de configuration. Il possède également une couche SQL afin que vous n'ayez pas à abandonner les données structurées.