Quelle est l'attraction des systèmes de base de données sans schéma?

Question

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

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

Alors que je suis attiré par la nature distribuée et facile JSON / interfaces RESTful de ces nouveaux systèmes, je ne comprends pas comment hash touche faiblement typé / valeur me aider à mon développement. Pourquoi un typé lâche, système de schéma moins serait bon pour garder les ensembles de données propres? Comment puis-je par exemple, trouver tous les articles avec des dates entre x et y quand ils pourraient ne pas avoir des dates? Y at-il concept d'une jointure?

Je comprends de nombreux systèmes ont leurs propres différences et les points forts, mais je me demande à la différence de paradigme. Je suppose que cela est un système question ouverte, mais peut-être qu'ils ont personnellement vu les réponses et les moyens de la communauté les avantages de ces systèmes aideront Enlighten moi et d'autres quand je voudrais utiliser ces (certes plus hanche) au lieu de le SGBDR traditionnel.

Answer 1

Je vais appeler une ou deux raisons communes (je suis sûr que les gens vont écrire les réponses de rédaction)

1. Avec des systèmes hautement distribués, tout ensemble de données peut être répartie sur plusieurs serveurs. Lorsque cela se produit, les contraintes relationnelles que le moteur DB peut garantir sont considérablement réduits. Certains de votre intégrité référentielle devra être traitée dans le code d'application. Ce faisant, vous découvrirez rapidement plusieurs points de la douleur:

   • votre logique est répartie sur plusieurs couches (app et db)
   • votre logique est répartie sur plusieurs langues (SQL et votre langage application de choix)

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

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

3. ACID ne fonctionne pas très bien pour les systèmes distribués ( BASE , CAP , etc.). Le langage SQL (et l'ensemble du modèle relationnel dans une certaine mesure) est optimisé pour un monde transactionnel ACID. Ainsi, une partie de la langue SQL caractéristiques et les meilleures pratiques sont inutiles tandis que d'autres sont en fait nuisibles. Certains développeurs se sentent mal à l'aise « contre le grain » et préfèrent abandonner entièrement SQL en faveur d'une langue qui a été conçu à partir du sol pour leurs besoins.

4. Coût: la plupart des systèmes SGBDR ne sont pas libres. Les dirigeants de mise à l'échelle (Oracle, Sybase, SQL Server) sont tous les produits commerciaux. Lorsque vous traitez avec une grande ( « échelle web ») les systèmes, les coûts de licence de base de données peut atteindre ou dépasser les coûts de matériel! Les coûts sont suffisamment élevés pour changer la construction normale / acheter des considérations radicalement à la construction d'une solution personnalisée au-dessus d'une offre OSS (toutes les offres de NoSQL importantes sont OSS)

Answer 2

est grand pour sans schéma deux raisons:

1. cerveau optimisation intuitivité de stockage de documents
2. Sparse-Matrix et Entité-Attribut Valeur problèmes de stockage.

Je l'ai utilisé à la fois SQL et non-SQL pour les applications de production en Ruby on Rails. Je ne suis pas un expert de la base de données et je dois avouer à googler acide et des termes similaires car ils ne sont pas familiers pour moi.

« Ah ha! Un autre suiveur de tendance savoir rien sauter sur le dernier train en marche », vous dites peut. Mais, en fait, je suis vraiment satisfait de ma décision d'utiliser MongoDB sur notre application la plus récente de 2 ans et voici pourquoi ...

Le revers de intuitivité-optimisation de cerveau a été mon expérience avec le système de commerce électronique Magento. Je ne veux pas bash parce qu'il m'a bien servi au moment, mais il a vraiment touché le processeur dur pour essayer de calculer les attributs pour chaque produit. La raison sous-jacente était le magasin entité-attribut-valeur des données de produit. Cache ou être damnés était la solution.

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

1. Nom du produit
2. Prix
3. Type de produit (

Ensuite, il devient plus difficile et couvert de notes, de codage couleur et des liens vers d'autres tables (eh oui .. relations)

4. Couleur (Seuls certains produits)
5. Taille (X Large, Large, Small) - uniquement pour les produits 8'9'10, les clubs de golf utilisent une autre échelle
6. Couleur 2. Les colliers pour chats ont deux choix de couleurs.
7. Wattage
8. Type de fixation (Homme, Femme)

Alors il se termine par un terrible gâchis de tableaux Excel qui ne font pas de sens pour moi et pas beaucoup de sens pour les gens qui travaillent avec le jour de produits et jour. Nous baisseraient les bras en l'air et décide de passer par le catalogue, puis il me frappe! Ne serait-il pas génial si vous pouviez stocker les données tel qu'il apparaît dans le catalogue !? Juste collections de documents sur chaque produit que les listes seulement 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 un magasin de document.

En résumé, le document magasins sont super quand vous avez un problème de matrice clairsemée ou des objets qui mutent leurs attributs au fil du temps. Ayant vécu dans un monde non-SQL pour 2 ans, je ne peux pas penser à une application réelle qui ne présente pas ces caractéristiques parce que le monde lui-même ressemble à un magasin de document.

Answer 3

La principale préoccupation devrait être ce que vous devez faire avec vos données. Si vous avez un énorme ensemble de données et trouvent un SGBDR traditionnel à un goulot d'étranglement, vous pouvez expérimenter avec un ou aa sans schéma la solution NoSQL.

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

Answer 4

Je n'ai joué avec MongoDB mais une chose qui m'a vraiment intéressé était de savoir comment vous pourriez les documents de nid. Dans MongoDB un document est essentiellement comme un disque. Ce qui est vraiment bien parce que, traditionnellement, dans un SGBDR, si vous avez besoin de tirer une « personne » enregistrement et obtenir l'adresse associée, l'information de l'employeur, etc., vous auriez souvent aller à plusieurs tables, les rejoindre, faire plusieurs bases de données appels. Dans une solution NoSQL comme MongoDB, vous pouvez juste imbriquer les enregistrements associés (documents) et ne pas avoir à jouer avec les clés étrangères, joindre, appels de bases de données multiples. Tout associé à un enregistrement qui est tiré.

Ceci est particulièrement pratique lorsque le traitement des objets. Vous pouvez stocker dans de nombreux cas seulement un objet comme une série de documents imbriqués.

Answer 5

bases de données NoSQL ne sont pas sans schéma; le schéma est intégré dans les données. Ils sont bien appelés semi-structurés. Dans certains magasins de données KV, cependant, le schéma peut même être intégré dans le code. L'avantage de l'approche semi-structurée est double: la flexibilité dans les colonnes qui font partie d'une ligne (une ligne peut avoir 5 colonnes et l'autre ont des 5 colonnes différentes, et la flexibilité dans les caractéristiques des colonnes (par exemple, des longueurs variables)

Answer 6

Normalement, l'attraction est celle de l'huile de serpent - la plupart des gens favourising les ont pas la moindre idée sur le théorème relationnel et SQL parler au niveau des professionnels faisant vomir. Aucune idée de ce que les conditions sont ACID, Ehy ils sont importants etc.

Ne pas dire qu'ils ne sont pas des utilisations valides .... juste dire que la plupart du temps l'attraction est les gens ne sachant pas ce qu'ils devraient savoir et tirer des conclusions stupides. Encore une fois, pas tout le monde est comme ça, mais la plupart des développeurs les favoriser sont -. Pas bien dans leur compréhension ce qu'est un système de base de données est acutally responsable de