Hai bisogno di consigli su MongoDB Schema for Chat App. Documenti incorporati vs correlati

Question

Sto iniziando un progetto MongoDB solo per i calci e come un'opportunità per imparare schemi MongoDB/NoSQL. Sarà un'app di chat dal vivo e lo stack include: Rails 3, Ruby 1.9.2, Devise, Mongoid/MongoDB, CarrierWave, Redis, JQuery.

Gestirò separatamente il polling della chat dal vivo e l'accodamento dei messaggi. Non sei ancora sicuro di come sia Node.js, APE o l'app personalizzata EventMachine. Ma riguardo a Mongo, sto pensando di usarlo per tutto il resto nell'app, in particolare i log delle chat e le trascrizioni storiche.

La mia domanda è il modo migliore per progettare lo schema come tutte le mie precedenti esperienze sono state con MySQL e lo schema di DB relazionale. E come sotto-domanda, quando è meglio per noi documenti incorporati o documenti correlati.

L'applicazione avrà:

conti

• multipli che hanno camere multiple
• camere multiple
• Utenti multipli per camera
• Elenco delle camere di un utente è autorizzato ad essere in
• multipla chat utente per camera
• Registri di chat ricercabili su base per camera e per utente
• file allegato opzionale per un dato chiacchierata

Dato Mongo (almeno l'ultima volta che ho controllato) ha un limite di documento di 4 MB, non credo che avere una collezione per le camere e la memorizzazione di tutte le chat room come documenti incorporati funzionerebbe così bene

Da quello che ho pensato fino ad ora, sto pensando di fare qualcosa di simile:

• Una collezione per gli account
• Una collezione per camere
  • Ogni camera si riferisce di nuovo a un account
  • Documenti correlati nelle raccolte di chat per tutti i messaggi di chat nella stanza
  • Documento incorporato che elenca tutti gli utenti attualmente in t lui camera
• Una collezione per gli utenti
  • documento incorporato elenco di tutte le stanze l'utente è attualmente in
  • documento incorporato elenco di tutte le camere che l'utente è autorizzato ad essere in
• Una raccolta per chat
  • Ogni chat si riferisce a una stanza nella collezione di camere
  • Ogni chat si riferisce a un utente nella raccolta utenti
  • Documento incorporato con informazioni sull'allegato del file caricato facoltativo.

La mia preoccupazione principale è quanto posso fare fino a quando questo finisce per sembrare uno schema relazionale e la sconfitta lo scopo? C'è sicuramente più relazione rispetto all'inclusione in corso.

Un'altra preoccupazione è che fare riferimento ai documenti correlati è molto più lento dell'accesso ai documenti incorporati che ho sentito.

Voglio fare domande generiche, come:

• Dammi tutte le camere per un account
• Dammi tutte le chat in una stanza (o filtrato attraverso intervallo di date)
• Give me tutte le chat da un utente specifico
• Dammi tutti i file caricati in una determinata stanza o per un dato org
• ecc

Qualche suggerimento su come strutturare lo schema in modo efficiente in un modo che le scale? Grazie a tutti.

Answer 1

Penso che tu sia più o meno sulla strada giusta. Userei un capped collection per le linee di chat, con ogni riga contenente l'ID utente, ID camera, timestamp, e ciò che è stato detto. Questi dati sarebbe scaduta una volta "fine" della collezione capped si raggiunge, quindi se avete bisogno di una storica registro che ci si vuole copiare i dati dalla raccolta innevate in una collezione "log" periodicamente, ma le collezioni innevate sono specificamente progettati per logging- applicazioni di stile in cui non si stanno eliminando i documenti e le questioni relative all'ordine di inserzione. Nel caso della chat, è una corrispondenza perfetta.

L'unica altra modifica che suggerirei sarebbe quella di mantenere i caricamenti in una raccolta separata, pure.

Answer 2

Sono un grande fan di mongodb come database di documenti. Ma sei sicuro che stai usando mongodb per il giusto motivo? In cosa è potente il mongodb?

È una domanda soggettiva, ma per me gli aggiornamenti sul posto (atomici) dei documenti sono ciò che rende potente mongodb. E non posso davvero vederti usarlo così tanto. E per di più si sta colpendo il formato del documento problema limite pure. (Con l'esperienza posso dirvi che incorporano file a MongoDB non è una buona idea). Vuoi avere un'applicazione di chat dal vivo anche sul database.

Lo schema del documento sembra logico. Ma non vorrei andare con MongoDB per questo tipo di progetto in cui la vostra applicazione dipende in larga misura inserti. Vorrei andare per CouchDB.

Con CouchDB che non avrebbe dovuto preoccuparsi di problemi gli allegati, è possibile incorporare facilmente. "_changes" renderebbe la vita molto più facile a Eight costruire un'applicazione di chat live/un lungo pooling/feed di motori di ricerca (se vuoi implementarne uno).

E ho visto uno open source showcase project in couchone. Ha alcune somiglianze con i tuoi obiettivi: Anologue. Si dovrebbe controllare.

PS: Mi dispiace che era un po 'fuori tema, ma non ho potuto trattenermi.