Migrazione da SQL a NoSQL Databases
Passaggi per migrare i dati da un database relazionale a NoSQL
L'utilizzo di un database relazionale nelle applicazioni .NET non è privo di limitazioni, come la sua incapacità di gestire più carico senza sostituire l'hardware esistente (scaling up) e la sua incapacità di aggiornare il suo modello di dati rigido, ad esempio righe e colonne. Se stai affrontando queste sfide, potresti aver già deciso di spostare il tuo database su NoSQL. Se non sei ancora convinto, allora potresti voler leggere Perché NoSQL?
Considerando il caso in cui hai esaurito le opzioni per ridimensionare il livello del tuo database e hai scelto di spostare i tuoi dati NoSQL, l'arduo compito della migrazione potrebbe impedirti di fare questo salto.
Sebbene la migrazione sia un compito arduo, se suddivisa in fasi, può essere affrontata in modo molto organizzato semplificandoti la vita. Questo whitepaper è qui per aiutarti a organizzare il processo di migrazione in 6 passaggi logici.
Se segui questi semplici passaggi, sono destinati ad aiutarti nel processo di migrazione. Questo documento ritiene che tu conosca già le nozioni di base sulle funzionalità di NosDB, una rete NoSQL Banca dati dei documenti. In caso contrario, per favore, vai al sito web. Di seguito vi presento i dettagli del suddetto processo.
Passaggio 1: identificare l'ambito
Il primo e più importante passo è comprendere il modello di business e lo schema del database. Dovrai inoltre comprendere completamente il modo in cui la tua applicazione accede a questi dati e al flusso di dati da e verso il tuo database. Ciò aiuta a identificare due informazioni chiave:
- La parte dello schema del database a cui si accede maggiormente (letture, scritture o entrambe)
- Dati raggruppati, cioè sempre accessibili insieme per letture e scritture.
Avere queste informazioni ti aiuta a identificare le decisioni chiave nei passaggi rimanenti. Pertanto, questo è anche il passaggio più cruciale.
Passaggio 2: identificare NoSQL Requisiti di installazione
Una volta che avrai finito di comprendere il tuo modello di business e il flusso di dati, sarai in buona forma per prendere alcune decisioni approssimative su come distribuire il tuo NoSQL cluster, in base ai requisiti aziendali. Ad esempio, annotare il numero corrente di applicazioni in esecuzione, il numero di utenti e la velocità di accesso sono alcune metriche importanti. Notare quale parte dei dati è altamente sensibile, ovvero è necessario disporre di un backup a tutti i costi, aiuta anche a decidere la strategia di distribuzione dei nodi di replica.
Dal NoSQL database è un database distribuito, puoi sfruttare la natura distribuita a tuo vantaggio e distribuirlo in base alle tue esigenze aziendali. Il più grande vantaggio che ottieni, oltre alla scalabilità, è la distribuzione/distribuzione del tuo NosDB frammenti di cluster in diverse posizioni GEO. Ciò ti consente di distribuire shard vicino alla posizione geografica della tua applicazione ed evitare costosi viaggi di rete. E migliora le prestazioni dell'app.
Ricorda solo che tutto ciò che stiamo facendo qui è delineare i requisiti. Rivisiteremo sicuramente queste impostazioni dopo aver identificato, creato e ottimizzato le nostre collezioni.
Passaggio 3: converti e ottimizza le raccolte JSON
Ora che hai i requisiti di base del tuo cluster di distribuzione, il tuo "schizzo" determinerà le tue strategie di ottimizzazione.
Converti tabelle in raccolte
Innanzitutto, converti semplicemente le tabelle dal database relazionale in raccolte e converti le colonne in attributi. Questo è il normalizzato dati provenienti da un database relazionale.
Denormalizza i dati incorporando i documenti
Successivamente, è necessario denormalizzare tabelle isolate, cioè tabelle che non significano nulla se non correlate con un'altra tabella. In termini relazionali, le tabelle isolate lo sono tavoli di giunzione. Per esempio, Dettagli dell'ordine in un database Northwind ha più senso quando menzionato in riferimento a un Ordine. Pertanto, la scelta giusta sarebbe incorporare OrderDetails all'interno del file Ordina documenti.
Converti relazioni
Ora, ciò che ti rimane sono quelle raccolte contenenti documenti che hanno i rispettivi tavoli di giunzione incorporato al loro interno. Ma che dire delle relazioni molti-a-molti, uno-a-molti e altre? È qui che le tue conoscenze sui dati raggruppati naturalmente e sui dati a cui si accede insieme tornano utili.
Nel Esempio di migrazione del database NorthWind, le ed Ordina le tabelle sono correlate ma non sempre accessibili insieme. Quindi, non ha senso incorporare il Oggetto Cliente all'interno Documento d'ordine. Inoltre, incorporando il Documento cliente duplicherà inutilmente i dati, cosa che vogliamo evitare il più possibile. In caso contrario una singola modifica nel profilo Cliente richiederà all'applicazione di apportare la modifica in tutti i Ordine.Cliente documenti. Un costo di calcolo non necessario.
D'altra parte, le Categorie sono sempre richieste dall'applicazione ogni volta che il Prodotto viene recuperato; pertanto, questo è un buon candidato per l'incorporamento. E non dimenticare che il bello dei documenti JSON è che possono anche supportare array e array di documenti JSON per arricchire i tuoi oggetti.
Modello ibrido: il meglio della normalizzazione e della denormalizzazione
Dal NoSQL lo schema si basa sul flusso di dati dell'applicazione, se una raccolta presenta i vantaggi di mantenerla sia incorporata che non incorporata, adottare il modello ibrido.
Nel database di esempio Northwind, a cui si fa riferimento nella pagina precedente, questo fenomeno è riscontrabile nel Categoria ed Prodotto tavoli. Lo scenario è che ogni volta che a Prodotto si accede, l'applicazione deve conoscerla Categoria. Ma l'applicazione deve anche scoprirlo Prodotti by Categoria.
Se l' Categoria è stato mantenuto in una tabella separata, il recupero di un singolo prodotto significherebbe due chiamate al database, una per recuperare il file Prodotto e l'altro per recuperare il rispettivo Categoria, quindi il costo aggiuntivo della rete. Se solo il Categoria è stato incorporato, quindi per scoprire tutte le categorie dovresti eseguire la seguente istruzione SQL:
SELECT DISTINCT product.Category.CategoryName FROM Products;Una semplice query SQL ma non molto efficiente, vero? Quindi la risposta è mantenere il Categoria documento in una raccolta differenziata ma incorporare solo quella parte che è necessariamente richiesta dal Prodotto. Questo è chiamato a Modello ibrido.
Ad esempio, nel nostro scenario, quando l'applicazione recupera il documento Product, richiede solo la conoscenza del Categoria Nome e Categoria Descrizione. Pertanto, non è assolutamente necessario incorporare il file Categoria Immagine in ogni documento Prodotto. In effetti, se duplicato, richiederà molto spazio di archiviazione non necessario e aumenterà le dimensioni del documento, imponendo così un costoso viaggio di rete.
Questo è un caso d'uso perfetto di un modello ibrido, quindi le collezioni avrebbero la forma seguente:
"Product" {
"name": "string",
"category": {
"name": "string",
"description": "string",
}
}e conservare Categoria anche separatamente:
"Category" {
"name": "string",
"description": "string",
"picture": byte[]
}
}Decidi la tua strategia di distribuzione
La prossima cosa da decidere è la probabile strategia di distribuzione delle tue collezioni. Lo schizzo iniziale dei requisiti di configurazione influisce direttamente su questo.
Hai tre opzioni per la tua strategia di distribuzione:
- Distribuzione basata sull'intervallo: Questa strategia consente di definire come i dati vengono distribuiti tra i nodi in base agli intervalli specificati per ogni shard. Ad esempio, se il tuo NosDB cluster è distribuito GEO con uno shard a New York e un altro a Londra, quindi i dati generati e richiesti dalle applicazioni esistenti a New York dovrebbero trovarsi nella stessa posizione GEO, ottimizzando così i costi di rete. Questa strategia è utilizzata principalmente nei cluster distribuiti GEO, ma ha anche altri casi d'uso.
- Distribuzione basata su hash: L'hashing consente di distribuire i dati tra gli shard in modo uniforme, distribuendo così anche il carico in modo uniforme. Questa strategia non è la scelta migliore per un cluster distribuito GEO, ma è ottima per NosDB cluster all'interno di un unico data center.
- Raccolta partizionata singola (Disabilita distribuzione): Questo disabilita completamente la distribuzione su una raccolta. Usa questa opzione se il tuo set di dati è piccolo o vuoi che si trovi in un'unica macchina.
Dopo aver deciso la tua strategia di distribuzione, potresti voler rivedere l'ottimizzazione della tua raccolta e la tua strategia di distribuzione per vedere se possono essere ulteriormente ottimizzate. Di solito sono sufficienti un paio di iterazioni per prendere una decisione.
Passaggio 4: migrare i dati
Infine, dopo un intenso brainstorming, arriva la parte relativamente facile, ovvero la migrazione dei dati dal database relazionale al NoSQL database.
Per prima cosa crea i tuoi oggetti .NET che rappresentano le tue raccolte e documenti JSON. Sì! non è necessario alcun ORM per inserire i dati poiché l'API .NET converte automaticamente i tuoi oggetti .NET in documenti JSON. (Solo una nota, tuttavia, puoi anche scegliere di utilizzare l'integrazione ADO.NET fornita insieme a NosDB).
Quindi, accedi al tuo database relazionale e popola questi oggetti .NET e inseriscili nel file NoSQL database. Puoi anche utilizzare CLR Trigger e CLR UDF forniti da NosDB per assistere la tua migrazione.
Dopo aver migrato i tuoi dati, ora è il momento di migrare la tua applicazione per adottare i dati in termini di raccolte e documenti. Privo di NosDB non hai la possibilità di utilizzare ADO.NET o CLR Trigger e UDF ma puoi comunque utilizzare l'API.
Passaggio 5: migrare l'applicazione
Esistono diversi modi per migrare l'applicazione .NET funzionante NosDB. NosDB supporta operazioni SQL come SELECT, INSERT, UPDATE e DELETE. L'uso delle operazioni SQL riduce notevolmente la curva di apprendimento per migrare l'applicazione, ad esempio è possibile utilizzare la sintassi a cui si è abituati. Puoi persino gestire il cluster di database in NosDB usando SQL.
NosDB supporta SQL con tutti i molteplici modi in cui è possibile accedere al database, vale a dire:
- API .NET
- ADO.NET
- LINQ
- API Java
- API REST
Puoi anche utilizzare l'API lato server per migliorare le prestazioni delle tue applicazioni, sfruttando la potenza della distribuzione utilizzando framework come MapReduce. Se non stai usando NosDB hai solo la possibilità di chiamare direttamente l'API. SQL e ADO.NET sono forniti solo da NosDB.
Passaggio 6: convalidare la migrazione
Dopo la migrazione, la convalida è l'ultimo passaggio dell'intero processo: verifica tutti i tuoi test, convalida i dati migrati e la tua applicazione. Questo passaggio dipende completamente da te e dai tuoi processi aziendali. Banco il neocostituito NoSQL database. Controlla i limiti dell'attuale configurazione del cluster (sebbene sia possibile scalare in orizzontale ogni volta che lo desideri) e dotarti degli strumenti giusti come NosDB Management Studio per gestire e monitorare l'intero cluster da un'unica posizione.
Questo è tutto! Se segui questi passaggi puoi organizzare la tua migrazione da un database relazionale a a NoSQL database in un processo logico in 6 fasi.