Base de données de conception non consanguine [fermé]

Question

Je suis intéressé à entendre parler des stratégies de conception que vous avez utilisé avec bases de données non relationnelles « NoSQL » - à savoir la (la plupart du temps nouveau) classe de magasins de données qui n'utilisent pas relationnel traditionnel conception ou SQL (comme Hypertable, CouchDB, SimpleDB, Google App Engine datastore, Voldemort, Cassandra, Data services SQL, etc.). Ils sont aussi souvent appelés « magasins clés / valeur », et à la base, ils agissent comme des tables de hachage persistants géants distribués.

Plus précisément, je veux en savoir plus sur les différences dans conception conceptuel de données avec ces nouvelles bases de données. Ce qui est plus facile, ce qui est plus difficile, ce qui ne peut être fait du tout?

• Avez-vous venez avec des conceptions alternatives qui fonctionnent beaucoup mieux dans le monde non-relationnel?

• Avez-vous frappez votre tête contre tout ce qui semble impossible?

• Avez-vous comblé l'écart avec les modèles de conception, par exemple de traduire l'un à l'autre?

• Avez-vous même des modèles de données explicites du tout maintenant (par exemple dans UML) ou avez-vous les lançai entièrement en faveur des blobs de données semi-structurées / document orienté?

• vous manque l'un des principaux services supplémentaires qui fournissent des SGBDR, comme l'intégrité relationnelle, prise en charge des transactions complexes de manière arbitraire, déclencheurs, etc?

Je viens d'un arrière-plan relationnel SQL DB, donc la normalisation est dans mon sang. Cela dit, je reçois les avantages des bases de données non relationnelles pour la simplicité et la mise à l'échelle, et mon instinct me dit qu'il doit y avoir un chevauchement plus riche des capacités de conception. Qu'avez-vous fait?

Pour votre information, il y a eu des discussions sur des sujets similaires StackOverflow ici:

• la prochaine génération de bases de données
• changer les schémas de travailler avec Google App Engine
• choix d'une base de données orientée document

Answer 1

Je pense que vous devez considérer que le SGBD non relationnels diffèrent beaucoup sur leur modèle de données et donc la conception de données conceptuelles diffèrent aussi beaucoup. Dans le fil des données de conception dans les bases de données non-relationnelles du groupe NoSQL Google les différents paradigmes sont classés comme suit:

1. systèmes BigTable comme (HBase, Hypertable, etc)
2. magasins à valeur clé (Tokyo, Voldemort, etc)
3. bases de données de documents (CouchDB, MongoDB, etc)
4. bases de données graphiques (AllegroGraph, Neo4j, sésame, etc.)

Je suis la plupart du temps dans des bases de données de graphique et l'élégance de la conception de données en utilisant ce paradigme a été ce qui m'a amené là-bas, fatigué des défauts de SGBDR . J'ai mis quelques exemples de conception de données en utilisant une base de données sur ce graphique de et il y a un de la façon de modéliser la base IMDB du film / acteur / rôle trop de données.

Les diapositives de présentation (Slideshare) Graphique bases de données et l'avenir de la gestion des connaissances à grande échelle par Marko Rodriguez contient une introduction très agréable la conception de données en utilisant une base de données de graphique ainsi.

Répondre aux questions spécifiques du point de vue graphdb:

autre conception:. Ajouter des relations entre différents types d'entités sans soucis ou un besoin de prédéfinir quelles entités pouvez vous connecter

Combler l'écart: j'ai tendance à faire différent pour chaque cas, en fonction du domaine lui-même, car je ne veux pas un « graphe orienté table » et autres. Cependant, est quelques informations sur la traduction automatique de SGBDR à graphdb.

modèles de données explicites. Je fais ces tout le temps (style tableau blanc), puis utiliser le modèle tel qu'il est dans la base de données ainsi

Miss du monde SGBDR: moyens faciles pour créer des rapports. Mise à jour: peut-être ce n'est pas que difficile de créer des rapports à partir d'une base de données graphique, voir Création d'un rapport pour une base de données exemple Neo4j.

Answer 2

Je viens juste de commencer avec blocs de données non relationnelle, et je suis encore à essayer envelopper la tête autour de lui et de savoir quel est le meilleur modèle serait. Et je ne peux parler que pour CouchDB.

Pourtant, j'ai quelques conclusions préliminaires:

Avez-vous venir avec des conceptions alternatives qui fonctionnent beaucoup mieux dans le monde non-relationnel?

Les quarts de travail de mise au point de conception. La conception du modèle de document (correspondant aux tables DB) devient presque hors de propos, alors que tout dépend de la conception des vues (correspondant aux requêtes)

Le document DB permute genre de la complexité: SQL dispose de données rigides et flexibles requêtes, documents sont BDs l'inverse

.

Le modèle CouchDB est une collection de documents "JSON" (tables de hachage essentiellement imbriquées). Chaque document a un identifiant unique, et peut être trivialement récupéré par ID. Pour toute autre question, vous écrivez « vues », qui sont nommés ensembles de map / reduce fonctions. Les vues renvoient un jeu de résultats comme une liste de paires clé / valeur.

L'astuce est que vous n'interrogez pas la base de données dans le sens que vous interrogez une base de données SQL: Les résultats de l'exécution des fonctions d'affichage sont stockées dans un index, et seul l'index peut être interrogé. (Comme « obtenir tout », « obtenir la clé » ou « obtenir tessiture ».)

Le plus proche analogie dans le monde SQL serait si vous pouviez interroger la base de données en utilisant des procédures stockées - toutes les requêtes que vous souhaitez prendre en charge doit être prédéfini.

La conception des documents est extrêmement flexible. J'ai trouvé que deux contraintes:

• Conserver les données liées dans un même document, puisqu'il n'y a rien qui correspond à une jointure.
• Ne pas faire les documents si grand qu'ils sont mis à jour trop souvent (comme mettre toutes les ventes de l'entreprise pour l'année dans le même document), puisque chaque mise à jour du document déclenche une nouvelle indexation.

Mais tout dépend de la conception des vues.

Les conceptions alternatives que j'ai trouvé que les ordres de travail de grandeur mieux avec CouchDB que toute base de données SQL sont au niveau du système plutôt que le niveau de stockage. Si vous avez des données et que vous voulez les servir à une page Web, la complexité du système total est réduite d'au moins 50%:

• aucune table de DB de conception (problème mineur)
• pas ODBC / JDBC couche intermédiaire, toutes les requêtes et les transactions sur http (problème modéré)
• simple, mappage DB-objet de JSON, qui est presque trivial par rapport à la même chose dans SQL (important!)
• vous pouvez potentiellement ignorer l'ensemble du serveur d'application, que vous pouvez concevoir vos documents à récupérer directement par le navigateur en utilisant AJAX et ajoutez un peu de polissage JavaScript avant qu'ils ne soient affichés au format HTML. (énorme !!)

Pour webapps normal, le document / BDs à base JSON sont une victoire massive, et les inconvénients des requêtes moins flexibles et un code supplémentaire pour la validation des données semble un petit prix à payer.

Avez-vous frappez votre tête contre tout ce qui semble impossible?

Pas encore. Map / Reduce comme moyen d'interroger une base de données ne connaît pas, et nécessite beaucoup plus de penser que l'écriture SQL. Il y a un nombre assez restreint de primitives, afin d'obtenir les résultats dont vous avez besoin est avant tout une question d'être créatif avec la façon dont vous spécifiez les clés.

Il y a une limitation dans les requêtes ne peut pas regarder deux ou plusieurs documents en même temps - se joint pas ou d'autres types de relations multi-documents, mais jusqu'à présent rien n'a été insurmontable.

En tant que limitation exemple, le nombre et les sommes sont faciles, mais les moyennes ne peuvent pas être calculées par une vue CouchDB / requête. Fix:. Retour somme et compte séparément et calculer la moyenne sur le client

Avez-vous comblé l'écart avec les modèles de conception, par exemple de traduire l'un à l'autre?

Je ne suis pas sûr que ce soit possible. Il est plus d'une refonte complète, comme la traduction d'un programme de style fonctionnel à un style orienté objet. En général, il y a beaucoup faiguière types de documents que il y a des tables SQL et plus de données dans chaque document.

Une façon de penser est de regarder votre SQL pour les insertions et les requêtes communes: les tables et les colonnes sont mises à jour lorsqu'un client passe une commande, par exemple? Et ceux qui pour les rapports de vente mensuels? Cette information devrait probablement aller dans le même document.

C'est: un document de commande, contenant les ID d'identification et produit client, avec des champs dupliqués comme nécessaires pour simplifier les requêtes. Tout ce que dans un document peut être facilement interrogé, tout ce qui nécessite des références croisées entre dire l'ordre et la clientèle doit être fait par le client. Donc, si vous voulez un rapport sur les ventes par région, vous devriez probablement mettre un code régional dans l'ordre.

Faites-vous même des modèles de données explicites du tout maintenant (par exemple dans UML)?

Désolé, n'a jamais fait beaucoup UML avant le document soit :) DB

Mais vous avez besoin d'une sorte de modèle dit quels champs appartiennent à quels documents et quels types de valeurs qu'ils contiennent. Les deux pour votre propre référence ultérieure et pour vous assurer que everybod la DB en utilisant les conventions connaît. Puisque vous n'obtenez une erreur si vous stockez une date dans un champ de texte, par exemple, et tout le monde peut ajouter ou supprimer tout champ qu'ils se sentent comme, vous avez besoin à la fois le code de validation et les conventions pour prendre le relais. Surtout si vous travaillez avec des ressources externes.

vous manque l'un des principaux services supplémentaires qui fournissent SGBDR?

Non. Mais mon expérience est développeur d'applications web, nous traitons avec des bases de données que dans la mesure où nous devons :)

Une entreprise que je travaillais pour fait un produit (une webapp) qui a été conçu pour fonctionner dans des bases de données SQL de plusieurs fournisseurs, et les « services supplémentaires » sont si différents de DB à DB qu'ils devaient être mis en œuvre séparément pour chaque DB. Il était donc moins de travail pour nous déplaçons la fonctionnalité de la SGBDR. Cette même étendue à la recherche plein texte.

Alors tout ce que je suis Renoncer est quelque chose que je ne ai jamais eu en premier lieu. De toute évidence, votre expérience peut différer.

---

Une mise en garde: Ce que je travaille est maintenant une webapp pour les données financières, des cotations boursières et autres. C'est un très bon match pour un DB de documents, de mon point de vue, je reçois tous les avantages d'une base de données (persistance et requêtes) sans les tracas.

Mais ces données sont assez indépendantes les unes des autres, il n'y a pas de requêtes relationnelles complexes. Recevez les dernières citations par téléscripteur, obtenir des citations de symbole et plage de dates, obtenir société méta-info, qui est à peu près tout. Un autre exemple que j'ai vu était une application de blog, et les blogs ne sont pas caractérisés soit par des schémas de base de données massivement complexes.

Ce que je suis en train de dire que toutes les applications réussies de documents BDs je sais d'avoir été avec des données qui n'ont pas beaucoup interrelation en premier lieu: Documents (comme dans la recherche Google), blogs, articles de presse , les données financières.

Je pense qu'il ya des ensembles de données qui correspondent mieux à SQL que le modèle de document, donc j'imagine SQL survivra.

Mais pour ceux d'entre nous qui veulent juste un moyen simple pour stocker et récupérer des données - et je pense qu'il ya beaucoup d'entre nous -. Bases de données de documents (comme dans CouchDB) sont un don du ciel

Answer 3

Je réponds à cela avec CouchDB dans le dos de mon esprit, mais je présume le plus serait vrai pour d'autres aussi BDs. Nous avons cherché à utiliser CouchDB, mais a finalement décidé contre elle depuis notre accès aux données ne sont pas connues à l'avance et l'évolutivité n'est pas la question.

Harder:

• Takes repensant au niveau conceptuel il est « plus difficile », car il est juste différent. Puisque vous devez connaître vos habitudes d'accès aux données à l'avance, pas de traduction automatique peut être appliquée. Vous auriez besoin d'ajouter le modèle d'accès au moins.
• La cohérence est pas gérée par la base de données, mais doit être traitée dans l'application. Moins garanties signifie une migration plus facile, fail-over et une meilleure évolutivité au coût d'une application plus complexe. Une application doit faire face à des conflits et des incohérences.
• Liens quels documents croix (ou clé / valeur) doivent être traitées au niveau de l'application aussi.
• type de bases de données SQL ont IDEs qui sont beaucoup plus matures. Vous obtenez beaucoup de bibliothèques de soutien (bien que la superposition de ces bibliothèques rendre les choses beaucoup plus complexe que nécessaire pour SQL).

Plus facile:

• Plus rapide si vous connaissez vos habitudes d'accès aux données.
• Migration / Fail-over est plus facile pour la base de données car aucune des promesses sont faites pour vous en tant que programmeur d'application. Bien que vous obtenez la cohérence éventuelle. Probablement. Finalement. Un certain temps.
• Une clé / valeur est beaucoup plus facile à comprendre que d'une ligne d'une table. Tous les (arbres) les relations sont déjà, et des objets complets peuvent être reconnus.

La modélisation devrait être de la même chose, mais il faut faire attention à ce que vous mettez dans un seul document. UML peut également être utilisé pour la modélisation orientée objet, ainsi que la modélisation DB, qui sont deux déjà bêtes différentes

J'aurais aimé voir une bonne base de données ouverte OO bien intégré avec C # / Silverlight. Juste pour faire le choix encore plus difficile. :)

Answer 4

fichiers plats ont longtemps été considérés comme des Arcanes et peu pratique pour un ensemble de données de toute taille. Cependant, des ordinateurs plus rapides avec plus de mémoire permettent de charger un fichier dans la mémoire et le tri en temps réel, au moins pour raisonnablement petit n et local, les applications mono-utilisateur.

Par exemple, vous pouvez lire généralement un fichier de 10.000 dossiers et le tri sur un terrain en moins d'une demi-seconde, un temps de réponse acceptable.

Bien sûr, il y a des raisons d'utiliser une base de données au lieu d'un fichier plat - les opérations relationnelles, l'intégrité des données, la capacité multi-utilisateur, acccess à distance, plus grande capacité, normalisation, etc., mais augmentation de la vitesse de l'ordinateur et de la capacité mémoire ont contribué à faire en la manipulation -Memory des données plus pratique dans certains cas.

Answer 5

Les bases de données relationnelles que je vois dans la vie réelle ont tendance à être pas très bien normalisé du tout, contrairement à votre demande. Lorsqu'on lui a demandé, les concepteurs me disent qui est la plupart du temps en raison de la performance. SGBDR ne sont pas bonnes à se joindre, si les tables ont tendance à être beaucoup trop large d'un point de vue de la normalisation. bases de données orientées objet d'ont tendance à être beaucoup mieux à ce sujet.

Un autre point où SGBDR ont des problèmes est la manipulation des clés de l'histoire / en fonction du temps.