Quel est l'intérêt des systèmes de base de données sans schéma?

Question

J'en ai entendu beaucoup parler de schéma (souvent distribué) systèmes de base de données comme MongoDB, CouchDB, SimpleDB, etc...

Même si je peux comprendre qu'ils pourraient être utiles à certaines fins, dans la plupart de mes applications que j'essaie de conserver les objets qui ont un certain nombre de champs d'un type spécifique, et je pense automatiquement dans le modèle relationnel. Je suis toujours en train de penser en termes de lignes avec entier unique id, null/not null champs, types de données SQL, et de sélectionner des requêtes pour trouver des ensembles.

Alors que je suis attiré par la nature distribuée et facile JSON/RESTful interfaces de ces nouveaux systèmes, je ne comprends pas comment faiblement typé clé/valeur hachages va m'aider avec mon développement. Pourquoi un lâche tapé, schéma du système d'être bon pour garder propres ensembles de données? Comment puis-je par exemple, rechercher tous les articles avec les dates entre x et y, quand ils pourraient ne pas avoir les dates? Est-il un concept d'une jointure?

Je comprends de nombreux systèmes ont leurs propres différences et les points forts, mais je me demandais, à la différence de paradigme. Je suppose que c'est une question ouverte, mais peut-être de la communauté réponses et les moyens qu'ils ont personnellement vu les avantages de ces systèmes permettra de m'éclairer et d'autres au sujet quand j'ai envie de faire usage de ces (certes plus de la hanche) systèmes au lieu de la traditionnelle SGBDR.

Answer 1

Je vais juste appeler une ou deux raisons (je suis sûr que les gens vont écrire les réponses d'essai)

1. Hautement systèmes distribués, un ensemble de données peuvent être réparties sur plusieurs serveurs. Lorsque cela se produit, le relationnel contraintes que le moteur de base de données peut garantir sont considérablement réduits. Certains de votre intégrité référentielle devront être traitées dans le code de l'application. Ce faisant, vous découvrirez rapidement plusieurs points de la douleur:

   • votre logique est réparti sur plusieurs couches (application et db)
   • votre logique est réparti sur plusieurs langues (SQL et votre application à la langue de son choix)

   Le résultat est que la logique est moins encapsulé, moins portable, et BEAUCOUP plus cher à changer. De nombreux développeurs se retrouvent écrit plus de logique dans le code de l'application et moins à la base de données. Poussée à l'extrême, le schéma de base de données devient hors de propos.

2. Schéma de gestion-en particulier sur les systèmes où les temps d'arrêt n'est pas une option-est difficile. en réduisant le schéma réduit la complexité de cette difficulté.

3. L'ACIDE ne fonctionne pas très bien pour les systèmes distribués (de BASE, PAC, etc). Le langage SQL (et l'ensemble du modèle relationnel, dans une certaine mesure) est optimisé pour les opérations à l'ACIDE monde. Donc, certaines des fonctionnalités du langage SQL et les meilleures pratiques sont inutiles alors que d'autres sont réellement nocives. Certains développeurs se sentent mal à l'aise "contre le grain" et préfère abandonner SQL entièrement en faveur d'une langue qui a été conçu à partir du sol jusqu'à leurs exigences.

4. Coût: la plupart des systèmes SGBDR ne sont pas libres. Les leaders de la mise à l'échelle (Oracle, Sybase, SQL Server) sont des produits commerciaux. Lorsque vous traitez avec de gros ("web"), des systèmes de base de données de coûts de licences peuvent atteindre ou dépasser les coûts de matériel! Les coûts sont assez élevés pour changer la normale construire/acheter considérations radicalement vers la construction d'une solution personnalisée sur le dessus d'un système de guichet unique offrant (tous les importants NOSQL offres sont OSS)

Answer 2

La principale préoccupation devrait être ce que vous devez faire avec vos données. Si vous avez une énorme quantité de données et sont à la recherche d'un SGBDR traditionnels pour être un goulot d'étranglement, alors vous voudrez peut-être essayer avec un schemaless ou un NOSQL solution.

La plupart des environnements que je suis au courant de l'utilisation de NOSQL solutions également utiliser un SGBDR solution dans une certaine forme ou de la mode. SGBDR de solutions basées sur la norme où l'intégrité des données est extrêmement important et vous avez besoin d'ACIDE transactions. Toutefois, si votre système n'est pas très basée sur la transaction, mais vous avez besoin de faire évoluer ou de réel rapide, un NOSQL solution peut être souhaitable.

Answer 3

Schemaless est idéal pour deux raisons:

1. Le cerveau d'optimiser l'intuitivité de stockage de document
2. Résout Rares-de la Matrice et de l'Entité-Attribut-Valeur de problèmes de stockage.

J'ai utilisé à la fois SQL et No-SQL pour les applications de production en Ruby on Rails. Je ne suis pas un expert base de données, et je dois avouer à googler ACIDE et d'autres termes similaires comme ils ne sont pas familier pour moi.

"Ah ha! Un autre savoir-rien suiveur de tendance à sauter sur la dernière boule de neige" vous pouvez dire. Mais, en fait, je suis vraiment content de ma décision d'utiliser MongoDB notre plus récente de 2 ans d'application, et voici pourquoi...

L'envers de la médaille de cerveau-l'optimisation de l'intuitivité a été mon expérience avec Magento e-commerce. Je ne veux pas bash, car il m'a bien servi à l'époque mais il a vraiment touché le processeur dur pour essayer de calculer les attributs de chaque produit. La raison sous-jacente est l'Entité-Attribut-Valeur de stocker des données produit. Cache ou être damné était la solution.

Le principal avantage pour moi, c'est l'optimisation dans le seul endroit qui est vraiment important - votre propre cerveau. De nombreuses technologies sont critiqués sur leur efficacité dans la mémoire, processeurs, de matériel et d'avoir encore une DB qui est extrêmement intuitive de comprendre apporte ses propres mérites. Nous avons trouvé qu'elle s'empresse d'ajouter des fonctionnalités à notre code, car la base de données a tout simplement l'air beaucoup comme le monde réel, nous sommes à la modélisation. Quand j'ai demandé aux clients de e-commerce pour me présenter leur liste de produits qu'ils auront naturellement tendance à utiliser Excel (pensez à la table du magasin). Les premières colonnes sont faciles:

1. Nom Du Produit
2. Prix
3. Type De Produit (

Ensuite, il devient plus difficile et couverts dans les notes, les codes de couleur et des liens vers d'autres tables (et oui.. les relations)

1. Couleur (Seulement certains produits)
2. Taille (X Grand, Grand, Petit) - uniquement pour les produits 8'9'10, les clubs de golf de l'utilisation d'une échelle différente
3. Couleur 2. Les colliers pour chat ont deux choix de couleurs.
4. Puissance en watts
5. Type de fixation (Masculin, Féminin)

De sorte qu'il se termine par un terrible gâchis de tableaux Excel qui n'ont pas de sens pour moi et pas beaucoup de sens pour les personnes qui travaillent avec les produits de jour en jour. Nous jeter les bras en l'air et décident d'aller à travers le catalogue, et puis il me frappe! Ne serait-il pas génial si vous pouviez stocker les données comme il apparaît dans le catalogue!? Juste une collection de données sur chaque produit que des listes de l'attribut de ce produit. Vous pouvez ensuite choisir les attributs communs à l'index pour la récupération à une date ultérieure. Bien sûr, c'est une banque de document.

En résumé, le document magasins sont grands quand vous avez une matrice creuse problème ou des objets qui muter leurs attributs au fil du temps. Ayant vécu dans un No-SQL monde pendant 2 ans, je ne peux pas penser à une application du monde réel qui n'ont pas de ces fonctionnalités, car le monde lui-même ressemble à un magasin de documents.

Answer 4

J'ai seulement joué avec MongoDB, mais une chose qui m'intéressait était de savoir comment vous pouvez imbriquer des documents. Dans MongoDB un document est fondamentalement comme un record. C'est vraiment sympa parce que, traditionnellement, dans un SGBDR, si vous avez besoin de tirer une "Personne" enregistrer et obtenir l'adresse associée, l'employeur info, etc. vous auriez souvent aller à de multiples tables, de se joindre à eux, faire plusieurs appels de base de données. Dans une solution NoSQL comme MongoDB, vous pouvez imbriquer les enregistrements associés (documents) et de ne pas avoir à jouer avec les clés étrangères, l'assemblage, de multiples appels de base de données. Tout associé avec qu'un seul enregistrement est tiré.

Ceci est particulièrement utile lorsque vous traitez avec des objets. Vous pouvez, dans de nombreux cas simplement pour stocker un objet comme une série de documents imbriqués.

Answer 5

Les bases de données NoSQL ne sont pas sans schéma; le schéma est intégré aux données. Ils sont correctement appelés semi-structurés. Cependant, dans certains magasins de données KV, le schéma peut même être incorporé dans du code. L’avantage de l’approche semi-structurée est double: flexibilité dans laquelle les colonnes font partie d’une rangée (une rangée peut avoir 5 colonnes et une autre 5, et la flexibilité des caractéristiques des colonnes (par exemple, des longueurs variables)