Come faccio a interrogare meglio per i dati di proprietà dell'utente quando si utilizza NoSQL

Question

Come faccio a interrogare meglio per i dati di proprietà dell'utente quando si utilizza NoSQL

#1 da (1 voti)

4

Dire che ho un tipico sito Web che fornisce agli utenti autenticati l'accesso ai loro dati (di proprietà) memorizzati. Gli utenti autorizzati devono essere in grado di eseguire operazioni CRUD sui propri dati. Se stavo usando una soluzione basata su RDBMS, userei una serie di join basati su user_id recuperati dalla sessione per assicurarmi di servire solo i dati degli utenti che li appartengono, per esempio;

select comments.* from comments
inner join blogs on blogs.id = comments.blog_id
inner join clients on clients.client_id = blogs.client_id
inner join users on users.client_id = clients.client_id
where users.user_id = X;

Questo esempio di pseudo-SQL mi fornisce tutti i dati dei commenti che appartengono all'utente.

Se stavo adottando un approccio NoSQL avrei un documento blog che ha incorporato una matrice comments e esposto un campo client_id che potrei popolare in Mongoose, ma il problema arriva quando devo eseguire una query separata per recuperare tutti i client che appartengono all'utente.

C'è un modo più efficiente per farlo? Sono preoccupato che mi manca un concetto di base. Suppongo che la risposta potrebbe essere quella di archiviare più dati correlati all'interno dei documenti, quindi avere un documento di base client che memorizza array di utenti e blog con commenti nidificati, ma sembra che il design sia troppo rigido.

architecture nosql schema

posta keithl8041 08.07.2015 - 17:33

fonte

1 risposta

Leggi altre domande sui tag architecture nosql schema

specifica relativa a un file di testo Algoritmo per scoprire se esiste un percorso (qualsiasi percorso) sopra la lunghezza X tra due vertici

score 1 · Accepted Answer

Per quanto riguarda il lato SQL, c'è l'opportunità di ottimizzare, ma dipende da ciò che si desidera ottimizzare. Se stai cercando di semplificare le query o di velocizzare le prestazioni, la denormalizzazione è un modo per raggiungere questo obiettivo. Ad esempio, potresti includere l'id client nella tabella dei commenti oltre a blog_id dato che sembra che i blog possano avere solo un client_id associato. Una volta che lo fai, la query sopra diventa:

select comments.* from comments
inner join users on users.client_id = comments.client_id
where users.user_id = X;

Questo è meno complesso e, a seconda delle dimensioni delle tabelle, potrebbe avere dei vantaggi in termini di prestazioni. Il compromesso è che ti ritroverai con un modello di dati un po 'più complesso con dati ridondanti su tabelle che rendono potenzialmente più difficile mantenere l'integrità dei dati.

Nota, nell'esempio originale sopra, è possibile semplificare la query. senza denormalizzare. In realtà non stai utilizzando nessuno dei dati della tabella "client" nel risultato, quindi includerlo nel join è estraneo dato che la tabella "users" include il client_id e può essere unita direttamente alla tabella dei blog.

Per il lato NoSQL delle cose, c'è molta variabilità tra le piattaforme rispetto a come trattano i singoli campi all'interno di un documento e come possono essere indicizzati e / o resi ricercabili. Ad esempio, è possibile mantenere ciascun post come documento separato e, almeno in MongoDB, è possibile indicizzare il campo id_cliente per rendere più veloce la ricerca e il recupero dei post corretti, ma l'approccio ottimale potrebbe essere diverso su un'altra piattaforma.

Una delle preoccupazioni legate alla creazione di un documento di grandi dimensioni che contenga tutti i post e i commenti del blog per il cliente, come suggerito sopra, è che potresti affrontare sfide con le prestazioni. In una query, potrebbe essere necessario recuperare l'intero documento, spostarlo sulla rete e navigare attraverso il documento per raggiungere l'elemento desiderato. Questo potrebbe essere lento. Se più utenti aggiungono commenti allo stesso tempo, è possibile eseguire più lag in quanto le richieste vengono accodate in attesa del rilascio dei blocchi di scrittura.

Scomporre in più documenti / raccolte con MongoDB, ad esempio, comporta la complessità aggiuntiva di dover eseguire più query per recuperare l'elemento desiderato, ma consente di leggere e aggiornare a una grana più piccola e potrebbe migliorare le prestazioni e probabilmente una minore complessità complessiva nel codice in quanto non è più necessario gestire l'intero set di post del blog per il client come una raccolta ampia e complessa.