Questi due scenari sarebbero buoni candidati per un database NoSQL?

NoSQL non è un termine molto ben definito e tutte le soluzioni che vengono eseguite con questo nome hanno caratteristiche molto diverse, quindi molto può essere possibile o meno a seconda di cosa esattamente si sta pensando di fare con esso.

Fondamentalmente potresti usare alcune delle soluzioni più generali come forse MongoDB o Cassandra per sostituire semplicemente il tuo attuale database relazionale. In alcuni casi questo ha più senso in altri meno, ma funzionerà una volta che il tuo team si sarà abituato. Certe cose saranno più facili allora, altre saranno più difficili e dovrai pesare queste opzioni l'una contro l'altra e decidere (il che abbastanza spesso significa che non ci sono vantaggi abbastanza grandi e il semplice fatto che tutti nel team si sentano più a loro agio con le relazioni e SQL renderà la decisione facile)

Altre soluzioni NoSQL che sono più specializzate non sono davvero buoni candidati per sostituire il tuo DB relazionale, come database di grafici o semplici archivi di valori chiave. Quindi, da qui parliamo principalmente di quei database che sono almeno in una certa misura simili ai database relazionali.

Scenario 1

Dove lavoro abbiamo esattamente questo scenario, anche se molto più complesso con molti attributi diversi per articolo. Alcuni di questi attributi in gerarchie come Apple - > iPad - > Air.

I dati sono ancora memorizzati in un database relazionale. Ma: cercare questo in tempo reale è diventato un dolore. Con SQL era lento e il codice sarebbe stato terribilmente complesso. Seleziona più tabelle, con l'opzione aggiuntiva di escludere determinati attributi come "non blu".

In questo caso Apache Solr o Elastic Search sono una soluzione. Sebbene, naturalmente, i dati siano duplicati dal database relazionale.

Ma da qui la nostra esperienza con questo tipo di archivio di documenti ha dimostrato che è in grado di gestire alcuni problemi molto bene e prenderemo in considerazione la possibilità di sostituire parte della struttura relazionale esistente con altri tipi di storage. Quindi non l'intero database in cui archiviamo anche tutti i dati transazionali come ordini ecc., Ma per esempio estrapola tutte le informazioni sugli attributi che possono essere gestite molto meglio nell'aggregato come le strutture dati di NoSQL.

Scenario 2

Difficile da dire, dal momento che ciò che descrivi è molto probabilmente solo una parte molto piccola della gestione dell'utente. Lo storage senza schemi è un vantaggio con molti database NoSQL. Ma alcuni database relazionali consentono di archiviare anche questi dati (purché non sia necessario interrogarli tramite SQL nella maggior parte dei casi).

Ad esempio, Cassandra ti consente di definire le famiglie di colonne in questo caso, in cui la prima serie di attributi sarebbe una di queste famiglie e la variabile ne attribuisce un'altra.

Come qualcuno ha detto: NoSQL è meno sullo storage e più sull'interrogazione. Quindi la domanda è quale sarà il tipico caso d'uso per quelle query.

Un tipico problema sarebbero i dati transazionali qui. Se si desidera memorizzare gli ordini, un modo sarebbe uno schema in cui gli utenti e i loro ordini formano un aggregato (tipo di documento utente che contiene gli ordini come documenti secondari). Ciò renderebbe molto semplice e veloce l'acquisizione di un utente insieme ai suoi ordini, ma renderebbe molto difficile recuperare tutti gli ordini del mese scorso per le statistiche sulle vendite.

Anche i punti di forza delle soluzioni NoSQL sono che può essere più facile eseguirli su più cluster se devi lavorare con dataset molto grandi.

Conclusione: Entrambi i tuoi scenari potrebbero essere modellati con determinate soluzioni NoSQL, ma non credo che (supponendo che debbano essere eseguiti in un ambiente più ampio) giustificano davvero un grande sforzo in più nell'apprendimento , formazione e implementazione e forse alcuni altri svantaggi aggiuntivi perché entrambi non sono abbastanza specifici per sfruttare appieno i punti di forza di NoSQL. Almeno non in quella semplice forma lo descrivi. Le cose possono diventare molto diverse una volta che alcuni aspetti che descrivi sarebbero molto, molto importanti nello scenario di utilizzo, come nello scenario uno i dati degli attributi diventano molto complessi o nello scenario due i campi variabili diventano la parte più grande dei dati che si memorizzano con ogni utente.

Ho usato il documento dbs (ravendb per essere specifico) come il mio archivio di dati preferito da più di 3 anni e davvero non voglio guardare indietro.

Almeno per quel tipo di database nosql la domanda più grande è "cosa succede in questo documento? Cosa succede in un altro documento? Cosa succede in un documento correlato?" Sfortunatamente non ci sono molte indicazioni su questo. Poi di nuovo gli RDB hanno una tecnologia di oltre 30 anni, quindi c'è un corpus di lavoro piuttosto massiccio, ma non ci sono ancora risposte perfette a tutti i problemi - ad esempio, rifiuterei qualsiasi soluzione di valore attributo-entità come il tuo scenario # 2 senza vere, vere buone ragioni per fare l'EAV - preferirei modellare estensioni di dati come sotto-tipo-tabelle o usare un qualche tipo di campo estensioni comprendente dati serializzati.

In ogni caso, non ci sono principi perfetti ma ci sono alcuni buoni principi guida che si possono seguire. I due che mi hanno aiutato di più sono:

1. Modella i tuoi documenti intorno ai limiti delle transazioni. Le join sono molto più costose da elaborare e utilizzare con gli oggetti, quindi essere in grado di selezionare Foo by ID e ottenere tutto foo ha un senso e rende più facile lavorare su molti livelli. Ora, questo non vuol dire che tutto debba essere un documento enorme: i confini delle transazioni possono essere più limitati di "tutto ciò che ha a che fare con un mobile". Nel caso del tuo scenario n. 1, probabilmente osserverei i limiti delle transazioni come i Mobili compresi i materiali e quindi un documento Istruzioni separato. La logica è che probabilmente gestisci mobili e materiali insieme, ma le istruzioni probabilmente provengono da qualche altra parte. Tieni presente che l'aggregazione sul front-end è piuttosto economica. Le categorie sono un esempio interessante che mi porta a. . .

2. La duplicazione dei dati è ok se gestisci correttamente. Un importante principio di base di RDBMS è "non duplicare i dati" in gran parte perché è cresciuto in un mondo in cui lo storage su disco era di ordini di grandezza più caro di quello del 2014. Per i database in stile documento può avere senso avere copie di cose all'interno dei confini della tua transazione. Ad esempio prendiamo le categorie di mobili dallo scenario n. 1 - probabilmente avrei un FurnitureCategoryDocument che avrebbe tutte le informazioni sulla categoria. Avrei anche alcune informazioni chiave - ID e nome almeno - incorporate nei documenti per facilità d'uso. Questo va bene fintanto che puoi aggiornare in cascata, che richiede più codice di ON AGGIORNAMENTO CASCADE, nella tua app.

Spero che questo aiuti a demistificare un po 'le cose.