di database NoSQL Modeling (durante la conversione da database SQL)

Question

Ho un database SQL che voglio convertire a uno NoSQL (attualmente sto usando RavenDB)

Qui ci sono le mie tabelle:

Trace :

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

distribuzione:

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

Applicazione:

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

Attualmente ho queste righe nei miei tabelle:

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 

Distribuzione:

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

Applicazione:

AppID: 1 , AppName: "Test1" 
AppID: 2 , AppName: "Test2" 
AppID: 3 , AppName: "Test3" 

La mia domanda è: come devo costruire il mio modello di documento NoSQL?

caso è simile:

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" 
} 

E se distribuzione 1 viene cambiato? Devo passare da ciascun documento e modificare i dati?

E quando devo usare riferimenti in NoSQL?

Answer 1

Il modo in cui modellate i vostri documenti dipende principalmente dall'applicazione e dal dominio. Da lì, il modello di documento può essere perfezionato comprendendo i modelli di accesso ai dati.

Probabilmente il tentativo di mappare un modello di dati relazionali a uno non relazionale non è una buona idea.

AGGIORNAMENTO: Penso che Matt abbia avuto l'idea principale del mio punto qui. Quello che sto cercando di dire è che non esiste un metodo prescritto (che io sappia comunque) per tradurre un modello di dati relazionali (come uno schema SQL normalizzato) in un modello di dati non relazionali (come un modello di documento) senza capire e considerando il dominio dell'applicazione. Consentitemi di elaborare un po 'qui ...

Dopo aver esaminato lo schema SQL, non ho idea di cosa sia una traccia oltre a una tabella che sembra unire Applicazioni e Distribuzioni. Inoltre non ho idea di come la tua applicazione tipicamente interroghi i dati. Conoscere un po 'di questo fa la differenza quando modellate i vostri documenti, proprio come farebbe una differenza nel modo in cui modellate i vostri oggetti di applicazione (o oggetti di dominio).

Quindi il modello di documento suggerito nella domanda potrebbe non funzionare per l'applicazione.

Answer 2

I database di documenti come Raven non sono database relazionali. NON è possibile prima creare il modello del database e poi decidere su vari modi interessanti di interrogarlo.Invece, è necessario innanzitutto determinare quali pattern di accesso si desidera supportare e quindi progettare di conseguenza gli schemi del documento.

Quindi, per rispondere alla tua domanda, quello che dobbiamo veramente sapere è come intendi utilizzare i dati. Ad esempio, la visualizzazione di tutte le tracce ordinate per ora è uno scenario chiaramente diverso rispetto alla visualizzazione di tracce associate a una specifica distribuzione o applicazione. Ognuno di questi requisiti determinerà un design diverso, così come il supporto a entrambi.

Questo di per sé potrebbe essere utile per te (?), Ma sospetto che tu voglia risposte più concrete :) Quindi per favore aggiungi alcuni dettagli aggiuntivi sull'uso previsto.

Ci sono alcuni "fare" e "non fare" al momento di decidere su una strategia:

DO: ottimizzare per i comuni casi d'uso. Esiste spesso una suddivisione in 20/80 in cui il 20% della UX guida l'80% del carico: la homepage/pagina di destinazione delle app Web è un classico esempio. La prima priorità è assicurarsi che questi siano il più efficienti possibile. Assicurati che il tuo modello di dati permetta A) di caricare quelli in una singola richiesta IO o B) sia cache-friendly

DONT: non cadere nella temuta trappola "N + 1". Questo modello si verifica quando il modello di dati obbliga a effettuare N chiamate per caricare N entità, spesso precedute da una chiamata aggiuntiva per ottenere l'elenco degli N ID. Questo è un killer, specialmente insieme a # 3 ...

DO: berrare sempre (tramite l'UX) la quantità di dati che si è disposti a recuperare. Se l'utente ha 3729 commenti, ovviamente non li recupererai tutti in una volta. Anche se fosse fattibile dal punto di vista del database, l'esperienza utente sarebbe orribile. Ecco perché i motori di ricerca usano il paradigma del "prossimo 20 risultati". In questo modo, ad esempio, è possibile allineare la struttura del database a UX e salvare i commenti in blocchi di 20. Quindi, l'aggiornamento di ogni pagina comporta un singolo DB get.

DO: bilancia i requisiti di lettura e scrittura. Alcuni tipi di sistemi sono pesanti in lettura e si può presumere che per ogni scrittura ci saranno molte letture (StackOverflow è un buon esempio). Quindi è logico rendere le scritture più costose per ottenere benefici nelle prestazioni di lettura. Ad esempio, denormalizzazione e duplicazione dei dati. Altri sistemi sono bilanciati uniformemente o addirittura scrivono pesanti e richiedono altri approcci

DO: Usa la dimensione di TIME a tuo vantaggio. Twitter è un classico esempio: il 99,99% dei tweet non sarà mai accessibile dopo la prima ora/giorno/settimana/altro. Ciò apre tutti i tipi di interessanti possibilità di ottimizzazione nello schema dei dati.

Questa è solo la punta dell'iceberg. Suggerisco di leggere un po 'su sistemi NoSQL basati su colonne (come Cassandra)