Migrazione di un'applicazione da SQL a NoSQL [chiuso]

0

Ho a che fare con un servizio di mvce per SQL che è il Database di WideWorldImporters di Microsoft e che lo migra in un NoSQL su MongoDB.

Il sistema in questione potrebbe utilizzare alcune frazioni di SQLDB in meno rispetto agli altri, ma certamente non è stato formulato un approccio chiaro tranne che, comprendiamo, denormalizzazione , costruendo viste basate su come l'informazione è consumato, centrale e fondamentale per la nostra nuova applicazione su NoSQL.

A questo proposito, è difficile determinare da quale angolo affrontare questa mastodontica bestia di un compito davanti a noi e io sono un membro chiave della task force. Ogni consiglio sull'approccio da adottare è cortesemente sollecitato. Tutto ciò che abbiamo ora è di pianificare il 25% di visualizzazioni sulle tabelle e riutilizzare la logica di creazione della vista per formare discriminatori di mangusta.

    
posta DL Narasimhan 08.03.2018 - 17:11
fonte

2 risposte

2

I am faced with taking a mvce's for SQL which happens to be the WideWorldImporters Database from Microsoft and migrating it to a NoSQL on mongodb.

Domanda: perché?

Hai un database perfettamente ragionevole in esecuzione su un DBMS piuttosto solido. Perché senti la necessità di portarlo a una soluzione NoSQL?

... no clear approach has been formulated ...

Qual è il risultato finale che stai cercando di raggiungere ?

Se è solo per "creare qualcosa in NoSQL", il porting da un DBMS relazionale non ti darà un risultato "Buono" (e ti scoraggierà e / o il tuo Management da [sempre] tentando di ripetere l'esercizio quando, per un altro scopo, potresti avere enormi benefici).

Scegli le tue battaglie. Considera NoSQL per un progetto in cui ti darà [il maggior] beneficio.

    
risposta data 08.03.2018 - 17:25
fonte
1

Dopo aver effettuato il passaggio da SQL Server a ElasticSearch, posso fornire alcune informazioni su cosa aspettarsi. Abbiamo scelto ElasticSearch perché avevamo bisogno di qualcosa con migliori (più efficienti) funzionalità di ricerca sfaccettata di quanto avessimo con SQL Server. Una delle caratteristiche principali era la capacità di ottenere il conteggio dei documenti che corrispondevano alle nostre sfaccettature non selezionate all'interno del sottoinsieme di dati che stavamo già cercando. Questo e le funzionalità di ricerca di testo completo erano più facili da utilizzare.

Detto questo, abbiamo dovuto fare quanto segue:

  1. Suddividi i dati in documenti che dovevamo cercare (ad esempio insegnamenti, devozioni, libri, eventi, ecc.)
  2. Scrivi il nostro strumento per eseguire un ETL (Estrai, Trasforma, Carica)
  3. Scrivi la complessa logica di trasformazione che ha anche ripulito i peccati di formattazione da oltre un decennio di manutenzione

Il primo passo è la tua fase di pianificazione. Qui è dove si progetta ciò che si inserisce nel documento. Se si dispone di un documento gerarchico che si desidera cercare separatamente, è necessario capire quante informazioni di riepilogo si desidera conservare nel documento principale.

Abbiamo optato per un oggetto di riferimento con sufficienti informazioni di riepilogo che non abbiamo dovuto eseguire una seconda query per ottenere gli oggetti figlio quando abbiamo visualizzato informazioni sullo schermo. Potresti decidere che non funziona per il tuo progetto. Ci sono dei compromessi, soprattutto perché gli aggiornamenti devono essere fatti in più posizioni. Nella mia situazione, ci sono pochissimi aggiornamenti.

Consiglio vivamente di cogliere l'occasione per ripulire i dati.

Il processo ETL che ho scelto ha funzionato bene per il backup da SQL:

  • Crea gli oggetti del tuo modello, la maggior parte delle API del database dei documenti li serializza come JSON o BSON
  • Esegui la tua Estrai / Trasforma in quegli oggetti modello
  • serializza gli oggetti del modello in un file BSON (utilizzando il formato Avro)

Il ripristino è stato un semplice caricamento dei dati del modello nel database dei documenti

  • Serializza gli oggetti del modello dal file BSON
  • Scrivili così come sono nel tuo database dei documenti

Il backup era un semplice download dei dati del modello dal database dei documenti

  • Leggi i record dal database dei documenti
  • Serializza gli oggetti del modello nel file BSON

A questo punto è possibile eseguire il backup da SQL Server e ripristinare il database del documento, nonché disporre di un backup e di ripristinare i dati con il database del documento.

    
risposta data 08.03.2018 - 18:31
fonte

Leggi altre domande sui tag