Comment structurer les relations dans Azure Cosmos DB?

voix
0

J'ai deux ensembles de données dans la même collection dans le cosmos, celui-ci sont « postes » et l'autre sont des « utilisateurs », ils sont liés par les postes créés par les utilisateurs.

À l'heure actuelle ma structure est la suivante;

// user document
{
id: 123,
postIds: ['id1','id2']
}

// post document
{
id: 'id1',
ownerId: 123
}
{
id: 'id2',
ownerId: 123
}

Mon principal problème avec cette configuration est la nature fongible de celui-ci, le code doit appliquer le lien et s'il y a des données de bugs sera perdu très facilement sans façon claire pour le récupérer.

Je suis également préoccupé par la performance, si un utilisateur a 10.000 postes qui est 10.000 Je vais devoir lookups faire pour résoudre tous les postes ..

Est-ce la bonne méthode pour la modélisation des relations d'entités?

Créé 19/12/2018 à 14:09
source utilisateur
Dans d'autres langues...                            


1 réponses

voix
2

Comme l'a dit David, il est une longue discussion, mais il est très commun, puisque j'ai sur heure ou de temps « libre », je suis plus heureux d'essayer de répondre, une fois pour toutes, je l'espère.

POURQUOI Normaliser?

La première chose que je remarque dans votre message: vous êtes à la recherche d' un certain niveau d'intégrité référentielle ( https://en.wikipedia.org/wiki/Referential_integrity ) qui est quelque chose qui est nécessaire lorsque vous décomposez un plus grand objet dans ses pièces constitutives. Aussi appelé normalisation.

Bien que cela se fait normalement dans une base de données relationnelle, il est en train de devenir aussi populaire dans la base de données non relationnelle, car il aide beaucoup à éviter la duplication des données qui crée généralement plus problème que ce qu'il résout.

https://docs.mongodb.com/manual/core/data-model-design/#normalized-data-models

Mais avez-vous vraiment besoin? Puisque vous avez choisi d'utiliser la base de données de documents JSON, vous devez tirer parti du fait qu'il est en mesure de stocker tout le document et puis juste enregistrer le document avec toutes les données du propriétaire: nom, prénom, ou toutes les autres données que vous avez sur l'utilisateur qui a créé le document. Oui, je dis que vous pouvez évaluer ne pas avoir la poste et l'utilisateur, mais seulement les messages, avec des informations utilisateur à l'intérieur patchage peut être effectivement très correct, car vous serez sûr d'obtenir les données exactes pour l'utilisateur existant au moment de la création de poste. Disons, par exemple, je créer un poste et j'ai biographie « X ». Je puis mettre à jour ma biographie à « Y » et de créer un nouveau poste. Les deux post aura différentes biographies d'auteur et cela est juste, car ils ont exactement capturé la réalité.

Bien sûr, vous pouvez également afficher une biographie dans une page auteur. Dans ce cas, vous aurez un problème. Lequel vous allez utiliser? Probablement la dernière.

Si tous les auteurs, afin d'exister dans votre système, doit avoir de blog publié, qui pourrait bien être suffisant. Mais vous voulez peut-être d'avoir un auteur écrire sa biographie et d'être listé dans votre système, avant même qu'il écrit un billet de blog.

Dans ce cas, vous devez Normaliser le modèle et créer un nouveau type de document, juste pour les auteurs. Si tel est votre cas, alors, vous devez également comprendre comment handler la situation décrite précédemment. Lorsque l'auteur mettra à jour sa propre biographie, vous mettre à jour tout le document auteur, ou en créer un nouveau? Si vous créez un nouveau, de sorte que vous pouvez garder une trace de tous les changements, vous mettez également à jour tous les post précédent afin qu'ils référencent le nouveau document, ou non?

Comme vous pouvez le voir la réponse est complexe et dépend vraiment de quel type d'information que vous voulez capturer du monde réel.

Donc, tout d'abord, savoir si vous avez vraiment besoin de garder les messages et les utilisateurs séparés.

COHÉRENCE

Supposons que vous voulez vraiment avoir les messages et les utilisateurs conservés dans des documents séparés, et donc vous normalisent votre modèle. Dans ce cas, gardez à l' esprit que Cosmos DB (mais NoSQL en général) les bases de données n'offrons pas tout type de support natif pour la cohérence, de sorte que vous êtes à peu près sur votre propre. Les index peuvent aider, bien sûr, vous voudrez peut -être indexer la propriété OWNERID, de sorte que , avant la suppression d' un auteur, par exemple, vous pouvez vérifier si efficacement il y a un poste blog fait par lui / elle qui restera orphelins autrement. Une autre option est de créer manuellement et tenir à jour un autre document que, pour chaque auteur, garde la trace des messages de blog qu'il / elle a écrit. Avec cette approche , vous pouvez simplement regarder ce document pour comprendre quels messages blogue appartiennent à un auteur. Vous pouvez essayer de conserver ce document mis à jour automatiquement en utilisant des déclencheurs, ou le faire dans votre application. Il suffit de garder à l' esprit que lorsque vous normalisez, dans une base de données NoSQL, maintenir la cohérence des données est votre responsabilité. C'est exactement le contraire d'une base de données relationnelle, où votre responsabilité est de garder la cohérence des données lorsque vous Dénormaliser il.

LES PERFORMANCES

Performance pourrait être un problème, mais vous ne modélise pas habituellement afin de soutenir les performances en premier lieu. Vous modèle afin de vous assurer que votre modèle peut représenter et stocker les informations dont vous avez besoin du monde réel et de l'optimiser afin d'avoir des performances correctes avec la base de données que vous avez choisi d'utiliser. Comme base de données différente aura des contraintes différentes, le modèle sera alors adapté pour faire face aux contraintes que. Ceci est rien de plus et rien de moins que le bon vieux de discussion de modélisation « logique » vs « physique ».

Dans le cas Cosmos DB, vous ne devriez pas avoir des requêtes qui vont croisée partition comme ils sont plus chers.

Malheureusement, le partitionnement est quelque chose que vous avez choisi une fois pour toutes, si vous avez vraiment besoin d'avoir clairement dans votre esprit ce que sont l'utilisation la plus courante si vous voulez soutenir au mieux. Si la majorité de vos requêtes sont effectuées sur base par auteur, je partition par l'auteur.

Maintenant, alors que celui-ci peut semble un choix intelligent, il sera seulement si vous avez beaucoup d'auteurs. Si vous avez un seul, par exemple, toutes les données et les requêtes vont dans une seule partition, ce qui limite BEAUCOUP votre performance. Rappelez-vous, en fait, que Cosmos DB RU sont répartis entre toutes les partitions disponibles: avec 10.000 RU, par exemple, vous obtenez habituellement 5 partitions, ce qui signifie que toutes vos valeurs seront réparties sur 5 partitions. Chaque partition aura une limite supérieure de 2000 RU. Si vos requêtes utilisent qu'une seule partition, votre performance maximale réelle est que 2000 et non 10000 Ferroviaires.

J'espère vraiment que cela vous aide à commencer à trouver la réponse. Et j'espère vraiment que cette aide à favoriser et à développer une discussion (comment modéliser une base de données de documents) que je pense qu'il est vraiment dû et maintenant mature.

Créé 03/01/2019 à 02:37
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more