Come monitorare le relazioni record in NoSQL?

Question

Sto cercando di capire l'equivalente di chiavi e indici esterni nei database KVP o Documento NoSQL. Dal momento che non ci sono tabelle pivotali (per aggiungere chiavi che segnano una relazione tra due oggetti) sono davvero stordito su come si sarebbe in grado di recuperare i dati in un modo che sarebbe utile per le normali pagine web.

Dire che ho un utente e questo utente lascia molti commenti in tutto il sito. L'unico modo che posso pensare di tenere traccia di che i commenti degli utenti è quello di

1. Embed loro in oggetto utente (che sembra abbastanza inutile)
2. Creare e mantenere un valore user_id:comments che contiene un elenco di ogni commento di chiave [commento: 34, commento: 197, ecc ...] in modo che possa recuperarli secondo necessità.

Tuttavia, prendendo il secondo esempio vi sarà presto colpito un muro di mattoni quando lo si utilizza per il monitoraggio altre cose, come una chiave denominata "active_comments" che potrebbero contenere 30 milioni di ID in esso che lo rende costato una tonnellata a interrogare ogni pagina solo per conoscere alcuni commenti attivi recenti. Sarebbe anche molto incline a condizioni di gara poiché molte pagine potrebbero provare ad aggiornarlo allo stesso tempo.

Come si possono tracciare relazioni come le seguenti in un database NoSQL?

• Tutti i commenti di un utente
• Tutti i commenti attivi
• Post con tag [parola chiave]
• Tutti gli studenti in un club - o tutti i club uno studente è in

Oppure sto pensando a questo in modo errato?

Answer 1

Tutte le risposte su come memorizzare molti-a-molti associazioni nel "modo NoSQL" ridurre al stessa cosa: memorizzazione dei dati in modo ridondante.

In NoSQL, non si progetta il database in base alle relazioni tra le entità di dati. Progetta il tuo database in base alle query che eseguirai contro di esso. Utilizzare gli stessi criteri che si utilizzerebbero per denormalizzare un database relazionale: se è più importante che i dati abbiano coesione (si pensi ai valori in un elenco separato da virgole invece che in una tabella normalizzata), quindi procedere in questo modo.

Ma questo inevitabilmente si ottimizza per un tipo di query (ad esempio commenti di qualsiasi utente per un dato articolo) a scapito di altri tipi di query (commenti per qualsiasi articolo di un determinato utente). Se la tua applicazione ha la necessità che entrambi i tipi di query siano ugualmente ottimizzati, non dovresti denormalizzare. Allo stesso modo, non è necessario utilizzare una soluzione NoSQL se è necessario utilizzare i dati in modo relazionale.

Esiste un rischio con denormalizzazione e ridondanza che i set di dati ridondanti non verranno sincronizzati tra loro. Questa è chiamata anomalia . Quando si utilizza un database relazionale normalizzato, l'RDBMS può prevenire anomalie. In un database denormalizzato o in NoSQL, diventa responsabilità dell'utente scrivere codice dell'applicazione per prevenire anomalie.

Si potrebbe pensare che sarebbe fantastico per un database NoSQL fare il duro lavoro di prevenire le anomalie per voi. Esiste un paradigma che può farlo: il paradigma relazionale.

Answer 2

1. utente: UserID: commenti è un approccio ragionevole - pensare ad esso come l'equivalente di un indice di colonna in SQL, con il requisito aggiunto che non si può interrogare sulle colonne non indicizzati.

2. Qui è dove devi pensare alle tue esigenze. Una lista con 30 milioni di articoli non è irragionevole perché è lenta, ma perché non è pratico fare nulla con essa. Se il tuo reale requisito è quello di visualizzare alcuni commenti recenti, è meglio tenere una lista molto breve che viene aggiornata ogni volta che viene aggiunto un commento - ricorda che NoSQL non ha requisiti di normalizzazione. Le condizioni di gara sono un problema con gli elenchi in un archivio di valori chiave di base, ma in genere la tua piattaforma supporta gli elenchi correttamente, puoi fare qualcosa con i blocchi o non ti interessa effettivamente gli aggiornamenti non riusciti.

3. Come per i commenti degli utenti - creare una parola chiave di indice: i messaggi

4. Più dello stesso - probabilmente un elenco di club come una proprietà di studente e un indice su quel campo per ottenere tutti i membri di un club

Answer 3

l'approccio CouchDB suggeriscono di emettere adeguate classi di roba in fase di mappa e riassumerla nel ridurre .. Così si potrebbe mappare tutti i commenti ed emettono 1 per l'utente dato e successivamente stampare unici.Richiederebbe tuttavia un sacco di spazio su disco per creare viste permanenti di tutti i dati rintracciabili in couchDB. btw hanno anche questa pagina wiki sulle relazioni: http://wiki.apache.org/couchdb/EntityRelationship.

Riak d'altra parte ha uno strumento per costruire relazioni. È un collegamento. È possibile inserire l'indirizzo di un documento collegato (qui commento) nel documento 'root' (qui documento utente). Ha un trucco. Se è distribuito, può essere modificato contemporaneamente in molte posizioni. Ciò causerà conflitti e di conseguenza un enorme albero di clock vettoriale:/... non così male, non così buono.

Riak ha anche un altro "meccanismo". Ha uno spazio per i nomi dei tasti su 2 livelli, chiamato benna e chiave. Così, per esempio studenti, Se abbiamo Club A, B e C e studente StudentX, studenty si potrebbe mantenere la seguente convenzione:

{ Key = {ClubA, StudentX}, Value = true }, 
{ Key = {ClubB, StudentX}, Value = true }, 
{ Key = {ClubA, StudentY}, Value = true } 

e leggere relazione solo le chiavi di elenco in date secchi. Cosa c'è che non va? È dannatamente lento. I bucket di elenco non hanno mai avuto priorità per riak. Sta diventando sempre meglio. btw. non sprechi memoria perché questo esempio {true} può essere collegato al profilo completo singolo di StudentX o Y (qui i conflitti non sono possibili).

Come lo vedi NoSQL! = NoSQL. È necessario esaminare l'implementazione specifica e testarla da soli.

Menzionato prima che i negozi di colonne sembrino adatti per le relazioni .. ma tutto dipende dalle vostre esigenze A e C e P;) Se non avete bisogno di A e avete meno di byte Peta lasciatelo, andare avanti con MySql o Postgres.

buona fortuna

Answer 4

Penso che RavenDB offra una buona soluzione a questo problema con l'indicizzazione. Le informazioni nella pagina principale http://ravendb.net/ spiegano il concetto abbastanza bene da poter creare qualcosa di analogo per la tua tecnologia.

Answer 5

Hai

"user": { 
    "userid": "unique value", 
    "category": "student", 
    "metainfo": "yada yada yada", 
    "clubs": ["archery", "kendo"] 
} 

"comments": { 
    "commentid": "unique value", 
    "pageid": "unique value", 
    "post-time": "ISO Date", 
    "userid": "OP id -> THIS IS IMPORTANT" 
} 

"page": { 
    "pageid": "unique value", 
    "post-time": "ISO Date", 
    "op-id": "user id", 
    "tag": ["abc", "zxcv", "qwer"] 
} 

Bene in un database relazionale la cosa normale da fare sarebbe in una relazione uno-a-molti è quello di normalizzare i dati. Questa è la stessa cosa che faresti anche in un database NoSQL. Basta indicizzare i campi con cui verranno recuperate le informazioni.

Per esempio, gli indici importanti per voi sono

• Comment.UserID
• Comment.PageID
• Comment.PostTime
• Page.Tag []

Se stanno usando NosDB (A .NET based NoSQL Database with SQL support) le vostre domande saranno come

SELECT * FROM Comments WHERE userid = ‘That user’; 

SELECT * FROM Comments WHERE pageid = ‘That user’; 

SELECT * FROM Comments WHERE post-time > DateTime('2016, 1, 1'); 

SELECT * FROM Page WHERE tag = 'kendo' 

Controllare tutti i tipi di query supportati dal loro SQL cheat sheet o dalla documentazione.