Modélisation base de données NoSQL (lors de la conversion de la base de données SQL)

Question

J'ai une base de données SQL que je veux convertir en un NoSQL (actuellement j'utilise RavenDB)

Voici mes tableaux:

Trace :

ID (PK, bigint, not null) 
DeploymentID (FK, int, not null) 
AppCode (int, not null) 

déploiement:

DeploymentID (PK, int, not null) 
DeploymentVersion (varchar(10), not null) 
DeploymentName (nvarchar(max), not null) 

Application:

AppID (PK, int, not null) 
AppName (nvarchar(max), not null) 

Actuellement, j'ai ces lignes dans mes tableaux:

Trace:

ID: 1 , DeploymentID: 1, AppCode: 1 
ID: 2 , DeploymentID: 1, AppCode: 2 
ID: 3 , DeploymentID: 1, AppCode: 3 
ID: 3 , DeploymentID: 2, AppCode: 1 

Déploiement:

DeploymentID: 1 , DeploymentVersion: 1.0, DeploymentName: "Test1" 
DeploymentID: 2 , DeploymentVersion: 1.0, DeploymentName: "Test2" 

Application:Ma question est: comment dois-je construire mon modèle de document NoSQL?

Si elle ressembler à:

trace/1 
{ 
"Deployment": [ { "DeploymentVersion": "1.0", "DeploymentName": "Test1" } ], 
"Application": "Test1" 
} 

trace/2 
{ 
"Deployment": [ { "DeploymentVersion": "1.0", "DeploymentName": "Test1" } ], 
"Application": "Test2" 
} 

trace/3 
{ 
"Deployment": [ { "DeploymentVersion": "1.0", "DeploymentName": "Test1" } ], 
"Application": "Test3" 
} 

trace/4  
{ 
"Deployment": [ { "DeploymentVersion": "1.0", "DeploymentName": "Test2" } ], 
"Application": "Test1" 
} 

Et si le déploiement 1 est changée? Dois-je passer par chaque document et modifier les données?

Et quand devrais-je utiliser des références dans NoSQL?

Answer 1

La façon dont vous modélisez vos documents dépend principalement de votre application et de son domaine. À partir de là, le modèle de document peut être affiné en comprenant vos modèles d'accès aux données.

La tentative aveugle de mapper un modèle de données relationnel à un modèle non relationnel n'est probablement pas une bonne idée. MISE À JOUR: Je pense que Matt a eu l'idée principale de mon point ici. Ce que j'essaie de dire c'est qu'il n'y a pas de méthode prescrite (que je sache) pour traduire un modèle de données relationnel (comme un schéma SQL normalisé) en un modèle de données non relationnel (comme un modèle de document) sans comprendre compte tenu du domaine de l'application. Permettez-moi d'élaborer un peu ici ...

Après avoir regardé votre schéma SQL, je n'ai aucune idée de ce qu'est une trace en plus d'une table qui semble rejoindre les applications et les déploiements. Je n'ai également aucune idée de la façon dont votre application interroge généralement les données. En savoir un peu à ce sujet fait une différence lorsque vous modélisez vos documents, tout comme cela ferait une différence dans la façon dont vous modélisez vos objets d'application (ou objets de domaine). Par conséquent, le modèle de document suggéré dans votre question peut fonctionner ou non pour votre application.

Answer 2

Les bases de données de documents telles que Raven ne sont pas des bases de données relationnelles. Vous NE POUVEZ PAS d'abord construire le modèle de base de données et ensuite décider de diverses manières intéressantes de l'interroger.Au lieu de cela, vous devez d'abord déterminer les modèles d'accès que vous souhaitez prendre en charge, puis concevoir les schémas de document en conséquence.

Donc, pour répondre à votre question, ce que nous devons vraiment savoir, c'est comment vous comptez utiliser les données. Par exemple, l'affichage de toutes les traces ordonnées par le temps est un scénario distinctement différent de l'affichage des traces associées à un déploiement ou une application spécifique. Chacune de ces exigences dictera un design différent, tout comme les soutiendra tous les deux. Cela peut être une information utile pour vous (?), Mais je suppose que vous voulez des réponses plus concrètes :) Donc, s'il vous plaît ajouter quelques détails supplémentaires sur votre utilisation prévue.

Il y a quelques « faire » et « à ne pas faire » au moment de décider d'une stratégie:

DO: Optimise pour les communes cas d'utilisation. Il y a souvent une panne 20/80 où 20% de l'UX entraîne 80% de la charge - la page d'accueil/landing page des applications web est un exemple classique. La première priorité est de s'assurer que ceux-ci sont aussi efficaces que possible. Assurez-vous que votre modèle de données permet A) de charger ceux dans une seule demande d'E/S ou B) est facile à mettre en cache

DONT: ne tombez pas dans le piège redouté "N + 1". Ce modèle se produit lorsque votre modèle de données vous oblige à effectuer des appels N afin de charger N entités, souvent précédé d'un appel supplémentaire pour obtenir la liste des N ID. C'est un tueur, surtout avec le # 3 ...

DO: Toujours limiter (via l'UX) la quantité de données que vous êtes prêt à aller chercher. Si l'utilisateur a 3729 commentaires, vous n'allez évidemment pas les chercher tous en même temps. Même si c'était possible du point de vue de la base de données, l'expérience utilisateur serait horrible. C'est pourquoi les moteurs de recherche utilisent le paradigme "20 prochains résultats". Ainsi, vous pouvez (par exemple) aligner la structure de la base de données sur l'UX et enregistrer les commentaires dans des blocs de 20. Ensuite, chaque actualisation de page implique une seule DB get.

DO: Équilibre les exigences de lecture et d'écriture. Certains types de systèmes sont lourds en lecture et vous pouvez supposer que pour chaque écriture il y aura beaucoup de lectures (StackOverflow est un bon exemple). Il est donc logique de rendre les écritures plus coûteuses afin d'obtenir des avantages dans les performances de lecture. Par exemple, dénormalisation et duplication de données. Les autres systèmes sont équilibrés de façon égale ou même lourds et nécessitent d'autres approches

DO: Utilisez la dimension de TIME à votre avantage. Twitter est un exemple classique: 99,99% des tweets ne seront jamais accessibles après la première heure/jour/semaine/peu importe. Cela ouvre toutes sortes de possibilités d'optimisation intéressantes dans votre schéma de données.

Ceci n'est que la pointe de l'iceberg. Je suggère de lire un peu sur les systèmes NoSQL basés sur les colonnes (tels que Cassandra)