Quali tipi di situazioni sono adatte per utilizzare sia un database relazionale che NoSQL?

Question

Questa non è una domanda di tipo NoSQL contro SQL. Sono interessato a tipi di scenari in cui è possibile utilizzare una combinazione di database RDBMS e NoSQL e l'utilizzo della combinazione è adatto. In generale, comprendo che "dipende" dalla situazione e dal compito in corso, ma penso che debbano esserci alcune situazioni generali/comuni in cui questa combinazione è molto utile.

Ognuno dei suddetti tipi di soluzioni ha punti di forza e punti deboli: quello che sto cercando sono situazioni/scenari in cui i punti di forza di entrambi possono essere pienamente sfruttati e utilizzati.

Nella mia mente, uno potrebbe essere l'e-commerce. Pagamenti, transazioni ecc. Su un RDBMS (pensare ACID) e informazioni sui prodotti e cataloghi in un database NoSQL. Ma è adatto?

Problemi di taglio trasversale di un'applicazione es. La registrazione è probabilmente adatta per una soluzione di tipo NoSQL come un altro esempio.

In alternativa, perché non dovresti utilizzare entrambi questi tipi di tecnologie in combinazione?

Modifica: solo per reiterare, capisco che sia SQL che NoSQL hanno i loro vantaggi e svantaggi intrinseci e che determinati tipi di situazioni sono più adatti a uno solo dei suddetti archivi di dati.

Iknow i giganti come Facebook, Google ecc probabilmente utilizzano una combinazione di questi, ma in quasi tutti i maggior parte dei casi non penso più così i membri potranno mai lavorare su tali soluzioni enormi. Più roba tipica di tutti i giorni.

RavenDB è una soluzione NoSQL che supporta le transazioni ACID

Answer 1

Non è davvero una questione di programmazione, ma qui è quello che penso.

Se si considera il teorema PAC http://en.wikipedia.org/wiki/CAP_theorem, si potrebbe supporre che Relationnal database concentrarsi sulla coerenza e di disponibilità, mentre NoSQL concentrarsi sulla disponibilità e la partizione tolleranza (con EVENTUALE COERENZA).

Se si desidera che la query SQL sia realmente coerente, è consigliabile utilizzare un RDBMS. Se non si tratta di un pre-requisito, è possibile utilizzare un database NoSQL.

Ecco perché la maggior parte delle volte, la migliore risposta è utilizzare entrambi, approfittando di entrambi.

Answer 2

Un buon esempio potrebbe essere qualsiasi archivio dati distribuito che viene aggiornato su più nodi contemporaneamente e che deve supportare query ad hoc potenzialmente complesse. I nodi sarebbero "alla fine coerenti", il che significa che qualsiasi nodo particolare potrebbe avere lacune nella sua immagine dei dati in qualsiasi momento.

Questo si adatta bene a un RDBMS perché gli spazi possono essere gestiti in modo molto semplice dai collegamenti "esterni" tra le relazioni. Il modello relazionale dovrebbe essere più adatto a questo, ad esempio, a un modello basato sul grafico, perché il modello grafico si basa su percorsi di navigazione tra diversi elementi di dati. Se manca un elemento, il grafico viene suddiviso in due grafici e quindi qualsiasi query basata su percorso potrebbe essere invalidata.Questo problema non esiste nel modello relazionale perché i database relazionali sono non di navigazione: non esistono "collegamenti" strutturali tra gli elementi di dati, quindi la "forma" delle query sui dati non deve essere modificata solo perché mancano i dati.

Answer 3

Una risposta ovvia potrebbe essere la segnalazione di un punto in cui uno è più appropriato dell'altro in una semplice applicazione.

Ad esempio, è possibile utilizzare un databae di documento come RavenDB o Couch per il proprio lavoro OLTP, poiché consente di salvare le entità e di interrogare tali entità in proiezioni appiattite su tutti i documenti (viste a query singola). (RavenDB più di CouchDB, ma non è né qui né lì ;-))

Si potrebbe anche usarlo per la segnalazione semplice, utilizzando Map/Reduce per darvi alcune statistiche per la visualizzazione su determinate pagine (prodotti popolari, tag cloud, ecc).

Tuttavia, molti sistemi di reporting sono creati per interrogare gli archivi relazionali, quindi è possibile che si desideri replicare i dati in un database di report.

Ad esempio, in RavenDB, è possibile prendere qualsiasi indice e replicare automaticamente i dati in tale indice in un archivio relazionale.

Ha senso perché avere i dati in un formato relazionale significa che è possibile eseguire complesse query su più documenti e integrarsi con i prodotti di reporting esistenti, senza intralciare il lavoro OLTP standard o la progettazione del database dei documenti.

Questa è solo una delle tante risposte, perché ci sono altri esempi in cui un particolare tipo di archivio dati è più adatto a uno scopo specifico, alla fine della giornata non c'è modo di allontanarsi da quello. (A meno che non crediate ai ragazzi VoltDB)

Answer 4

A meno che non stiate operando su una scala in cui i database relazionali semplicemente non funzioneranno, il grande vantaggio di NoSQL è la facilità di sviluppo - cose come non richiedere un ORM o script di aggiornamento del database. Non appena inizi a utilizzare SQL per una parte del sistema, è necessario uno sforzo minimo per utilizzarlo per altre parti.

In quasi tutti i progetti ci saranno componenti più adatti a un particolare tipo di archivio dati. La domanda importante è se la differenza sia sufficiente a giustificare il sovraccarico dell'utilizzo di più archivi di dati. Generalmente ciò significa una combinazione di scale, rapporti ad hoc e strutture dati che non si adattano bene ad un database relazionale.

Answer 5

NOSQL potrebbe essere utilizzato per replicare i dati da un datastore SQL. In questo scenario voglio creare documenti da record SQLITE mobili e fare affidamento su couch o mongo per replicarli su un nosql sul server. Il server SQL può quindi elaborare i documenti in arrivo.