Sistema DB ibrido: NoSQL per dati, SQL per le relazioni. La migliore pratica?

Question

Sto costruendo un'app il cui sistema DB sarà cruciale e deve essere scalabile poiché tutto il suo valore sarà nei dati.

Sto facendo un sistema di votazione dal vivo.

Sto bene con SQL e MongoDB, quindi non è quasi un fattore di decisione (anche se io tendo a come la struttura MongoDB e JS di più in questi tempi :))

Ma da tutto ciò che ho letto sul web , Mi sento ancora a disagio con la mia decisione.

Quello che voglio fare è quello di combinare i vantaggi di entrambi:

• Avere NoSQL Documenti per gli oggetti (utenti, oggetti, etc.) Commenti
• Avere tabelle SQL per i rapporti (tabella utente-Items , User-Comments etc.)
• duplicando il risultati del voto in un documento NoSQL ogni volta che c'è un voto o in un intervallo regolare (per guadagnare velocità anche in mostra risultati voto)

Grande ADVA I ntages che vedo sono:

1. Quando si esegue una query su un documento (ad es. un utente per visualizzare il suo profilo), ho tutti i vantaggi NoSQL (velocità, tutto in un unico luogo, flessibilità dello schema ecc.)
2. Quando si fanno statistiche (ad esempio numero di voti), ho tutti i vantaggi di SQL
3. parallelizzazione: posso prendere il voto in SQL e dei documenti in modalità asincrona
4. leggere veloce, scrivere slowish (e non importa nel mio caso)
5. integrità rapporto è sempre conservato

le mie domande sono:

• È una buona pratica farlo? Il web sembra piuttosto timido su di esso
• Sto ottimizzando le arachidi, anche con carico DB elevato? (Confrontando documento recupero alla piena SQL e query come select * from tabella in cui primary_key = XXX)

Answer 1

Se l'unico motivo si desidera utilizzare un database NoSQL con un RDBMS è quello di ottenere velocità e flessibilità, mi piacerebbe suggerire di utilizzare un server di caching (come Memcache). È possibile creare un documento/risultato utilizzando istruzioni SQL e memorizzarlo utilizzando un singolo valore chiave in memcache per recuperarlo in un secondo momento. È molto più facile da implementare che dire MongoDB. Ma ovviamente dipende dalle tue esigenze se vuoi davvero fare ricerche di documenti usando una chiave o un piano per usare query più complesse per i tuoi documenti.

Answer 2

Vorrei lanciare un altro suggerimento per la modellazione di oggetti e relazioni in scala.

alcuni spunti di riflessione:

1. Come detto, il modello entità/oggetti di un database di documenti come MongoDB.
2. Memorizza le relazioni in un database grafico come Titan o Neo4j.Questi sistemi sono più appropriati a mio parere per l'archiviazione di relazioni complesse. Puoi facilmente fare degli attraversamenti su molte relazioni complesse e poi quando trovi un nodo/vertice di destinazione nel grafico, puoi caricare il documento da Mongo.
3. Considerare qualcosa come Riak, che è un archivio di documenti NoSQL che anche ha collegamenti tra documenti (relazioni). Raccomandano di non rendere le relazioni troppo complesse, ma è possibile collegare insieme documenti senza la necessità di un altro sistema.

Answer 3

"La migliore pratica" è un termine orribile: viene spesso usato per giustificare l'istinto istintivo, "è così che l'abbiamo sempre fatto", o altri pregiudizi.

Tuttavia, la soluzione che descrivi ha un sacco di vantaggi (ne parli alcuni), ma anche alcuni svantaggi significativi, soprattutto perché dividi la conoscenza del tuo dominio problematico tra due archivi dati incompatibili, e questo apre molte opportunità di duplicazione - ma anche di incoerenza.

Ad esempio, la conoscenza che un determinato utente viene identificato da un determinato identificatore sarebbe condivisa tra il sistema NoSQL e il database. Se un sistema elimina quell'utente, l'altro viene lasciato in uno stato incoerente. Un determinato profilo dell'utente verrebbe diviso in due sistemi e nessuno dei due avrebbe un'immagine completa; avresti bisogno di un sacco di codice di sincronizzazione per le pulizie.

Gli sviluppatori che lavorano sulla tua piattaforma necessitano di esperienza in entrambi gli stack tecnologici: immagina di provare a eseguire il debug perché il numero di commenti di un determinato utente non è corretto.

Ora hai due punti di errore: se i database NoSQL o SQL non funzionano, l'intero sistema si interrompe. E il fallimento potrebbe non significare il crash - potrebbe anche significare problemi di prestazioni, o problemi con gli aggiornamenti, o problemi con i backup.

Non è raro che soluzioni software dispongano di più sistemi ciascuno proprietario di una parte dei dati, la suddivisione è di solito lungo le righe del dominio aziendale (il sistema CRM conosce il tuo profilo, il sistema di pagamento i dettagli della tua carta di credito, il sistema di e-commerce sa cosa hai ordinato); dividere la divisione lungo linee tecniche creerebbe un'architettura complessa con molteplici punti di errore.

Non credo che i vantaggi superino questi inconvenienti.