SQL Server e Mongo possono essere usati insieme?

Abbiamo un grande sito orientato alle notizie che ha un elevato traffico web. L'architettura è il tuo DB spesso visto - Repo Layer - Services Layer - Asp.Net MVC. Il problema che abbiamo riscontrato riguarda le prestazioni di lettura. Si scopre che tutta questa roba di oggetti di dominio DDD è ottima, in teoria, per le regole aziendali, ma ha reso la vita più difficile quando si tratta di ottimizzare le prestazioni di lettura.

Come soluzione, sto prendendo in considerazione qualcosa di completamente nuovo (per noi): usare noSQL. Vorrei utilizzare un database noSQL per i dati presentati sul nostro sito Web. Non possiamo liberarci del nostro SQL Server (almeno non in qualunque momento presto), ma mi sembra che un passo pratico sarebbe usare Mongo come database di query per tutti i nuovi sviluppi.

La mia domanda è se è possibile utilizzare SQL Server come database di record e Mongo come database di query insieme ?

Pertanto, quando uno dei nostri editor aggiorna un record, i dati verranno archiviati in SQL Server. Questo è necessario, perché c'è troppo codice legacy che non può essere riscritto dall'oggi al domani.

Ma quando un visualizzatore sul sito Web visualizza un articolo o un elenco di articoli, vorrei sfruttare le prestazioni di Mongo rispetto a SQL Server. Per mantenere un po 'aggiornati i dati, diciamo che sono vecchi o meno di 15 minuti, i dati di SQL Server dovrebbero aggiornare Mongo. RDBMS ha strumenti di replica per operazioni come questa e mi chiedo se esiste qualcosa per fare lo stesso da SQL Server a Mongo. Server Lync, forse?

— John
fonte

Possibile? Naturalmente è possibile, come due archivi di dati separati. Cosa stai chiedendo esattamente qui?

— Oded,

Ma puoi usarli insieme? Con il Mongo DB che agisce sostanzialmente come cache di sola lettura per i dati?

— John,

Ancora una volta, ovviamente, puoi "usarli insieme". Ma non è chiaro cosa significhi. Finché hai una sorta di meccanismo di aggiornamento per mongo, sei a posto. Vedi i post di Udi Dahan - ma sta a te definire il meccanismo.

— Oded,

Non ci siamo mai trasferiti a MongoDB, tuttavia sembra che l'anno prossimo possiamo. Un modo transitorio che abbiamo fatto è di archiviare JSON in campi varchar. Da tutto quello che ho letto, non c'è un buon modo per spostare i dati avanti e indietro tra NoSQL e SQL: tutto dovrà essere personalizzato, soprattutto perché i database NoSQL che sono là fuori variano notevolmente nel modo in cui fanno le cose .

— Giovanni

@Giovanni se stai cercando di rimanere relazionale e sei disposto ad allontanarti da SQL Server, potresti voler dare un'occhiata a Postgresql e alla sua integrazione json . Pertanto, memorizzando i dati in una colonna JSON che può quindi essere manipolata all'interno del database.

Risposte:

Hai riscontrato un problema che molti hanno prima di te ... un database ottimizzato per la lettura raramente è buono per l'efficienza di scrittura e viceversa. Un approccio che si è evoluto da questo impedimento in lettura e scrittura è CQRS (Command Query Responsibility Segregation). Nonostante Wikipedia che colleghi i due insieme, CQRS e CQS sono tecnicamente diversi. CQS richiede solo che un metodo apporti una modifica (comando) o richieda informazioni (query) mai entrambi.

CQRS fa un ulteriore passo avanti e specifica che si dispone di un modello separato per query e comandi. Questo singolo passaggio consente cose come la separazione del database di lettura e scrittura. Questo è quello che vuoi fare.

Non posso dire di essere un esperto di Mongo o di configurarlo per funzionare con SQL Server. Ma dalla mia comprensione, le persone usano Mongo come una vista denormalizzata del loro database transazionale. L'aggiornamento di Mongo dal db transazionale potrebbe richiedere l'esecuzione di un agente SQL. O avere un servizio separato per eseguire il polling del database.

Un'alternativa ancora migliore sarebbe far sì che il tuo servizio di comando attivi un evento ogni volta che viene effettuato un aggiornamento. Avresti quindi un servizio in ascolto per quell'evento e aggiornato MongoDB con quelle informazioni. Questo è l'approccio fondamentale all'Event Sourcing (cerca l'Event Sourcing nella pagina).

Greg Young, uno dei leader del pensiero nel mondo DDD sta attualmente scrivendo un libro della Fowler Signature Series su CQRS chiamato Event-Centric (che un tempo si chiamava CQRS). Fowler ha scritto un post sul suo bliki descrivendo l'approccio

— Michael Brown
fonte

+1 CQRS si adatta bene qui. Utilizzare gli eventi per popolare e aggiornare un database di documenti utilizzato per creare le visualizzazioni e lasciare il database sql così com'è.

— Quentin-starin,

Non abbiamo adottato un sistema CQRS, tuttavia ho prestato attenzione a ciò che Greg, Udi e altri hanno scritto. Una grande parte di CQRS non è una piattaforma specifica, ma pensa solo a comandi e query separatamente. Non penso che Greg abbia mai finito per scrivere un libro, anche se Microsoft Patterns and Practices ne ha pubblicato uno.

— Giovanni

L'unica cosa che aggiungerei a questa risposta è: se il tuo caso d'uso riguarda specificamente questo utilizzo con MS SQL e MVC, hai considerato BrightstarDB invece di MongoDB per la parte NoSQL? Ha Entity Framework e compatibilità LINQ, che potrebbe facilitare la transizione per te.

— CrazyPyro

Sì. Nel mio progetto attuale, stiamo ottenendo dati e archiviandoli in SQL Server, quindi costruendo indici di ricerca utilizzando Lucene / Solr e archiviando quelli in MongoDB. Il popolamento di MongoDB viene eseguito con un caricatore personalizzato, tuttavia: nessuna replica di SQL Server o aggiornamento automatico.

— TMN
fonte

Ok, sono solo curioso, perché non popolare direttamente il mongo? Sei sotto lo stesso vincolo di dover usare entrambi?

— Yati Sagade,

Il nostro SQL Server esistente non può essere riscritto dall'oggi al domani. Il mio pensiero è che questo è un piccolo, ma utile passo da bambino.

— Giovanni,

@yatisagade: giusto. Abbiamo rapporti che devono essere eseguiti su SQL Server, ma abbiamo un'app di ricerca globale che utilizza gli indici Lucene.

— TMN il