Conception de base de données non relationnelle
Je suis intéressé à entendre parler des stratégies de conception que vous avez utilisées avec les bases de données "nosql" non relationnelles - c'est-à-dire la classe de données (principalement nouvelle) les magasins qui n'utilisent pas la conception relationnelle traditionnelle ou SQL (tels que Hypertable, CouchDB, SimpleDB, la banque de données Google App Engine, Voldemort, Cassandra, SQL Data Services, etc.). Ils sont également souvent appelés "magasins de clés/valeur" et, à la base, ils agissent comme des tables de hachage persistantes distribuées géantes.
Plus précisément, je veux en savoir plus sur les différences de conception de données conceptuelles avec ces nouvelles bases de données. Qu'est-ce qui est plus facile, plus difficile, que ne peut-on pas faire du tout?
Avez-vous trouvé des conceptions alternatives qui fonctionnent beaucoup mieux dans le monde non relationnel?
Avez-vous frappé la tête contre quelque chose qui semble impossible?
Avez-vous comblé l'écart avec des modèles de conception, par exemple traduire de l'un à l'autre?
Faites-vous même des modèles de données explicites maintenant (par exemple en UML) ou les avez-vous entièrement jetés en faveur de blobs de données semi-structurés/orientés document?
Manquez-vous l'un des principaux services supplémentaires fournis par les SGBDR, comme l'intégrité relationnelle, la prise en charge de transactions arbitrairement complexes, les déclencheurs, etc.?
Je viens d'un arrière-plan de base de données relationnelle SQL, donc la normalisation est dans mon sang. Cela dit, j'obtiens 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 info, il y a eu des discussions StackOverflow sur des sujets similaires ici:
Je pense que vous devez considérer que les SGBD non relationnels diffèrent beaucoup en ce qui concerne leur modèle de données et donc la conception des données conceptuelles différera également beaucoup. Dans le thread Conception de données dans des bases de données non relationnelles du groupe Google NOSQL les différents paradigmes sont classés comme suit:
- Systèmes de type Bigtable (HBase, Hypertable, etc.)
- Magasins de valeurs clés (Tokyo, Voldemort, etc.)
- Bases de données documentaires (CouchDB, MongoDB, etc.)
- Bases de données graphiques (AllegroGraph, Neo4j, Sesame, etc.)
Je suis surtout dans bases de données graphiques , et l'élégance de la conception de données utilisant ce paradigme m'a amené là, fatigué des lacunes de RDBMS . J'ai mis quelques exemples de conception de données en utilisant une base de données graphique sur ce page wiki et il y a un exemple de la façon de modéliser le basique IMDB film/acteur/données de rôle aussi.
Les diapositives de présentation (slideshare) Bases de données graphiques et l'avenir de la gestion des connaissances à grande échelle par Marko Rodriguez contient une très belle introduction à la conception de données utilisant également une base de données graphiques.
Répondre aux questions spécifiques d'un point de vue graphique:
Conception alternative: ajouter des relations entre de nombreux types d'entités sans aucun souci ni besoin de prédéfinir quelles entités peuvent se connecter.
Combler le fossé: j'ai tendance à faire cela différemment pour chaque cas, en fonction du domaine lui-même, car je ne veux pas d'un "graphique orienté tableau" et autres. Cependant, voici quelques informations sur la traduction automatique du SGBDR vers graphdb.
Modèles de données explicites: je les fais tout le temps (style tableau blanc), puis j'utilise également le modèle tel qu'il est dans la base de données.
Miss du monde RDBMS: des moyens simples de créer des rapports. Mise à jour: ce n'est peut-être pas si 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 .
Je viens juste de commencer avec les bases de données non relationnelles, et j'essaie toujours de m'en tenir compte et de déterminer quel serait le meilleur modèle. Et je ne peux parler que pour CouchDB.
Pourtant, j'ai quelques conclusions préliminaires:
Avez-vous trouvé des conceptions alternatives qui fonctionnent beaucoup mieux dans le monde non relationnel?
La conception se déplace: la conception du modèle de document (correspondant aux tables de base de données) devient presque hors de propos, tandis que tout dépend de la conception des vues (correspondant aux requêtes).
La base de données de documents échange en quelque sorte les complexités: SQL a des données inflexibles et des requêtes flexibles, les bases de données de documents sont l'inverse.
Le modèle CouchDB est une collection de "documents JSON" (essentiellement des tables de hachage imbriquées). Chaque document a un identifiant unique et peut être récupéré de manière triviale par identifiant. Pour toute autre requête, vous écrivez des "vues", qui sont des ensembles nommés de fonctions map/réduire. Les vues renvoient un jeu de résultats sous forme de liste de paires clé/valeur.
L'astuce consiste à ne pas interroger la base de données au sens où vous interrogez une base de données SQL: les résultats de l'exécution des fonctions d'affichage sont stockés dans un index et seul l'index peut être interrogé. (Comme "tout obtenir", "obtenir la clé" ou "obtenir la plage de clés".)
L'analogie la plus proche dans le monde SQL serait si vous ne pouviez interroger la base de données qu'en utilisant des procédures stockées - chaque requête que vous souhaitez prendre en charge doit être prédéfinie.
La conception des documents est extrêmement flexible. Je n'ai trouvé que deux contraintes:
- Conservez les données associées ensemble dans le même document, car il n'y a rien de correspondant à une jointure.
- Ne faites pas les documents si gros qu'ils sont mis à jour trop fréquemment (comme mettre toutes les ventes de l'entreprise pour l'année dans le même document), car chaque mise à jour du document déclenche une réindexation.
Mais tout dépend de la conception des vues.
Les conceptions alternatives que j'ai trouvées que les ordres de travail de magnitude mieux avec CouchDB que n'importe quelle base de données SQL sont au niveau du système plutôt qu'au niveau du stockage. Si vous avez des données et que vous souhaitez les diffuser sur une page Web, la complexité de l'ensemble du système est réduite d'au moins 50%:
- pas de conception de tables DB (problème mineur)
- pas de couche intermédiaire ODBC/JDBC, toutes les requêtes et transactions via http (problème modéré)
- mappage DB-objet simple à partir de JSON, ce qui est presque trivial par rapport à la même chose en SQL (important!)
- vous pouvez potentiellement ignorer l'intégralité du serveur d'applications, car vous pouvez concevoir vos documents à récupérer directement par le navigateur à l'aide de AJAX et ajouter un peu de polissage JavaScript avant de les afficher en HTML. - (ÉNORME !!)
Pour les applications Web normales, les bases de données basées sur des documents/JSON sont une victoire massive, et les inconvénients des requêtes moins flexibles et du code supplémentaire pour la validation des données semblent un petit prix à payer.
Avez-vous frappé la tête contre quelque chose qui semble impossible?
Pas encore. Mapper/réduire comme moyen d'interroger une base de données n'est pas familier et nécessite beaucoup plus de réflexion que d'écrire SQL. Le nombre de primitives étant relativement faible, l'obtention des résultats dont vous avez besoin est avant tout une question de créativité avec la façon dont vous spécifiez les clés.
Il y a une limitation dans la mesure où les requêtes ne peuvent pas regarder deux ou plusieurs documents en même temps - pas de jointures ou d'autres types de relations multi-documents, mais jusqu'à présent rien n'a été insurmontable.
À titre d'exemple de limitation, les comptes et les sommes sont faciles mais les moyennes ne peuvent pas être calculées par une vue/requête CouchDB. Correction: renvoyer la somme et compter séparément et calculer la moyenne sur le client.
Avez-vous comblé l'écart avec des modèles de conception, par exemple traduire de l'un à l'autre?
Je ne suis pas sûr que ce soit faisable. Il s'agit plus d'une refonte complète, comme la traduction d'un programme de style fonctionnel en un style orienté objet. En général, il y a beaucoup moins de types de documents qu'il n'y a de tables SQL et plus de données dans chaque document.
Une façon d'y penser est de regarder votre SQL pour les insertions et les requêtes courantes: quelles tables et colonnes sont mises à jour lorsqu'un client passe une commande, par exemple? Et lesquels pour les rapports de ventes mensuels? Cette information devrait probablement figurer dans le même document.
C'est-à-dire: un document pour la commande, contenant l'ID client et les ID produit, avec des champs répliqués si nécessaire pour simplifier les requêtes. Tout ce qui se trouve dans un document peut être interrogé facilement, tout ce qui nécessite un croisement entre la Commande et le Client doit être fait par le client. Donc, si vous voulez un rapport sur les ventes par région, vous devriez probablement mettre un code de région dans la commande.
Faites-vous même des modèles de données explicites maintenant (par exemple en UML)?
Désolé, je n'ai jamais fait beaucoup d'UML avant les bases de données de document :)
Mais vous avez besoin d'une sorte de modèle indiquant quels champs appartiennent à quels documents et quels types de valeurs ils contiennent. À la fois pour votre propre référence plus tard et pour vous assurer que tout le monde utilisant la base de données connaît les conventions. Étant donné que vous n'obtenez plus d'erreur si vous stockez une date dans un champ de texte, par exemple, et que n'importe qui peut ajouter ou supprimer n'importe quel champ comme il le souhaite, vous avez besoin à la fois d'un code de validation et de conventions pour prendre le relais. Surtout si vous travaillez avec des ressources externes.
Manquez-vous l'un des principaux services supplémentaires fournis par les SGBDR?
Nan. Mais mon expérience est développeur d'applications Web, nous ne traitons les bases de données que dans la mesure où nous devons :)
Une entreprise pour laquelle je travaillais a créé un produit (une application Web) conçu pour fonctionner sur des bases de données SQL de plusieurs fournisseurs, et les "services supplémentaires" sont si différents d'une base de données à l'autre qu'ils ont dû être mis en œuvre séparément pour chaque base de données. Il nous a donc fallu moins de travail pour déplacer la fonctionnalité hors du SGBDR. Cela s'est même étendu à la recherche plein texte.
Donc, tout ce que j'abandonne est quelque chose que je n'ai jamais vraiment eu en premier lieu. De toute évidence, votre expérience peut différer.
Une mise en garde: ce sur quoi je travaille maintenant, c'est une application Web pour les données financières, les cotations boursières et autres. C'est une très bonne correspondance pour une base de données de documents, de mon point de vue, j'obtiens tous les avantages d'une base de données (persistance et requêtes) sans aucun tracas.
Mais ces données sont assez indépendantes les unes des autres, il n'y a pas de requêtes relationnelles complexes. Obtenez les derniers devis par ticker, obtenez des devis par ticker et plage de dates, obtenez les méta-informations de l'entreprise, c'est à peu près tout. Un autre exemple que j'ai vu était une application de blog, et les blogs ne se caractérisent pas non plus par des schémas de base de données extrêmement compliqués.
Ce que j'essaie de dire, c'est que toutes les applications réussies de bases de données de documents que je connais l'ont été avec des données qui n'avaient pas beaucoup d'interrelations en premier lieu: documents (comme dans la recherche Google), articles de blog, articles de presse, données financières .
Je m'attends à ce qu'il existe des ensembles de données qui correspondent mieux à SQL qu'au modèle de document, donc j'imagine que SQL survivra.
Mais pour ceux d'entre nous qui veulent simplement un moyen simple de stocker et de récupérer des données - et je soupçonne que nous sommes nombreux - les bases de données de documents (comme dans CouchDB) sont une aubaine.
Je réponds à cette question avec CouchDB dans le fond de mon esprit, mais je présume que la plupart seraient également valables pour d'autres bases de données. Nous avons envisagé d'utiliser CouchDB, mais nous avons finalement décidé de ne pas le faire car notre accès aux données n'est pas connu à l'avance et l'évolutivité n'est pas le problème.
Plus fort:
- Il faut repenser le niveau conceptuel donc c'est plus difficile car c'est juste différent. Étant donné que vous devez connaître à l'avance vos modèles d'accès aux données, aucune traduction automatique ne peut être appliquée. Vous devez au moins ajouter le modèle d'accès.
- La cohérence n'est pas gérée par la base de données mais doit être traitée dans l'application. Moins de garanties signifie une migration plus facile, un basculement et une meilleure évolutivité au prix d'une application plus compliquée. Une application doit gérer les conflits et les incohérences.
- Les liens qui croisent des documents (ou clé/valeur) doivent également être traités au niveau de l'application.
- Les bases de données de type SQL ont des IDE beaucoup plus matures. Vous obtenez beaucoup de bibliothèques de support (bien que la superposition de ces bibliothèques rende les choses beaucoup plus complexes que nécessaire pour SQL).
Plus facile:
- Plus rapide si vous connaissez vos modèles d'accès aux données.
- La migration/basculement est plus facile pour la base de données car aucune promesse ne vous est faite en tant que programmeur d'applications. Bien que vous obteniez finalement une cohérence. Probablement. Finalement. Parfois.
- Une clé/valeur est beaucoup plus facile à comprendre qu'une ligne d'une table. Toutes les relations (arborescentes) sont déjà établies et des objets complets peuvent être reconnus.
La modélisation doit être à peu près la même, mais vous devez faire attention à ce que vous mettez dans un document: UML peut également être utilisé pour les deux OO modélisation ainsi que la modélisation DB, qui sont deux bêtes différentes déjà.
J'aurais aimé voir une bonne base de données ouverte OO bien intégrée à C #/Silverlight. Juste pour rendre le choix encore plus difficile. :)
Les bases de données relationnelles que je vois dans la vraie vie ont tendance à ne pas être très bien normalisées du tout, contrairement à ce que vous prétendez. Lorsqu'on leur a demandé, les concepteurs m'ont dit que c'était principalement à cause des performances. Les RDBM ne sont pas bons à joindre, donc les tables ont tendance à être beaucoup trop larges du point de vue de la normalisation. Les bases de données orientées objet ont tendance à être bien meilleures dans ce domaine.
Un autre point où les RDBM ont des problèmes est la gestion des clés historiques/dépendantes du temps.
Les fichiers plats ont longtemps été considérés comme obscurs et peu pratiques pour un ensemble de données de toute taille. Cependant, des ordinateurs plus rapides avec plus de mémoire permettent de charger un fichier en mémoire et de le trier en temps réel, au moins pour les applications n et locales à utilisateur unique raisonnablement petites.
Par exemple, vous pouvez généralement lire un fichier de 10 000 enregistrements ET le trier sur un champ en moins d'une demi-seconde, un temps de réponse acceptable.
Bien sûr, il existe des raisons d'utiliser une base de données au lieu d'un fichier plat - opérations relationnelles, intégrité des données, capacité multi-utilisateur, accès à distance, plus grande capacité, standardisation, etc., mais l'augmentation de la vitesse de l'ordinateur et de la capacité de la mémoire a rendu la manipulation en mémoire des données plus pratiques dans certains cas.