Come progettare una soluzione di database NoSQL per la mia applicazione

0

Un saluto a tutti. Sto creando una directory online per la mia azienda utilizzando NodeJS. Il nostro account supporta centinaia di applicazioni del client e ogni applicazione ha determinati parametri come Application Name , SLA , App ID , insieme a dettagli di contatto come i numeri di telefono e gli indirizzi e-mail di tutte le persone chiave correlate al applicazione.

In precedenza, tutto questo era archiviato in un foglio Excel e il client doveva trovare le informazioni manualmente da Excel. Sto creando una directory online che renderà questa ricerca un processo semplice. L'amministratore carica semplicemente il foglio Excel e viene analizzato e ogni riga viene archiviata come documento JSON nel DB NoSQL. Poiché ci sono circa 25 campi per ogni applicazione, e al momento in cui questo progetto è iniziato, Application era l'unico oggetto i cui dettagli dovevano essere catturati, sono andato con un database NoSQL (IBM Cloudant - basato su Apache CouchDB). Ha funzionato molto bene. Le ricerche sono veloci, ho progettato il DB per avere indici di query (full-text) sui campi Application ID e Application Name .

Ora, il mio manager è disposto ad estendere questo concetto. Abbiamo anche una cosiddetta Standby Matrix, che memorizza i dettagli per un particolare mese, delle persone che saranno "su chiamata" per una particolare applicazione. Ogni persona è "su chiamata" per una settimana. Quindi questo foglio Excel contiene tutti i App ID s, seguito dal nome della persona in servizio per quell'applicazione per quella settimana. Ci sono 4 righe per ogni applicazione, una per ogni settimana del mese. Questi dati sono memorizzati in un database separato. Il campo comune è App ID .

Ora quello che voglio ottenere è, durante la ricerca di un'applicazione, il nome della persona attualmente in servizio. Se fosse stato un database SQL, le cose erano semplici: basta unire le tabelle su "App ID's. Tuttavia, Cloudant (o qualsiasi NoSQL) non supporta i join, quindi attualmente l'unica soluzione che vedo è interrogare prima il database dell'applicazione e poi il database dei dettagli di standby. Per ridurre il sovraccarico, sto pianificando di inserire un pulsante "Ottieni dettagli chiamata", facendo clic sul quale si attiverà la seconda query, evitando di interrogare inutilmente il DB per tutti i risultati della ricerca.

C'è una soluzione migliore per questo, e la mia soluzione è accettabile? L'applicazione avrà un carico da basso a moderato - circa 30-35 query / ora al massimo. Per quanto possibile, voglio attenermi all'architettura corrente ed evitare di passare a una soluzione SQL.

    
posta Aditya Medhe 04.09.2016 - 07:03
fonte

0 risposte

Leggi altre domande sui tag