Quali sono alcuni casi d'uso reali per andare con un negozio di documenti NOSQL DB?

Question

Ho letto documentazione e guardando screencast specifici per Mongo DB negli ultimi giorni e sono in perdita per quando una soluzione come questa sarebbe migliore di un tipico ambiente PG o MySQL.

In particolare, la mia domanda è in quale circostanza (con caso d'uso sarebbe bello) vorresti seguire la rotta NoSQL?

Grazie!

Answer 1

1. Molti scrittori disparati. Soprattutto quando gli scrittori possono essere segmentati a causa di disconnessioni nella rete e in seguito dovranno risincronizzare i dati che sono stati scritti su entrambi i lati della biforcazione. Questo rompe l'acido e, sebbene tu possa risolvere il problema con la logica aziendale esplicita, ora sei nel territorio NoSQL. Questo è molto comune in situazioni militari, ma qualsiasi sistema in cui tutti sono uno scrittore prolifico avrà un blocco di contenuto di scrittura su un sistema acido.

2. Schemi fluidi. La modifica di uno schema in un DB tradizionale è un'operazione costosa che spesso richiede una sorta di tempi di inattività del server o altri processi complicati. Con la maggior parte dei sistemi NoSQL è banale. Quindi, se hai dati da molte fonti disparate per unire e/o hai situazioni in cui potresti voler iniziare a monitorare nuove informazioni in un secondo momento, i sistemi NoSQL saranno molto più facili da affrontare. La fusione di due fonti di dati in modo che possano essere tracciate tra loro è un buon esempio a cui riesco a pensare.

3. Replica a bassa larghezza di banda. Una volta rotto l'acido, puoi avere lettori e scrittori su nodi foglia di un grafico di rete con dati parziali che non richiedono repliche complete del database. Il prodotto della mia compagnia, il posto di comando dell'esercito del futuro lo usa.

4. Interoperabilità dei dati. La maggior parte dei database NOSQL consente di introspettare i dati senza conoscere lo schema in anticipo, consentendo più facilmente connessioni tra sistemi disparati.

5. Massiccio ridimensionamento. Questo è quello che è più spesso dibattuto e molto spesso abusato dai sostenitori di NoSQL. Se questo è l'unico motivo per cui stai scegliendo NoSQL, inizia invece con MySQL e scala in seguito.

Answer 2

Caso d'uso
Usiamo MongoDB per una struttura di dati estremamente transitoria su larga scala. In effetti funziona come un tracker / manager di lavoro con molte unità di lavoro elaborate ogni secondo. L'unità di lavoro non ha uno schema definito (unità diverse vengono inventate in qualche modo frequentemente), ma dobbiamo avere la capacità di interrogare per campi o proprietà specifiche senza iterare l'intero DB. Quindi per ricapitolare: altamente transitorio, altamente disponibile (non posso permettersi di bloccare una query) con un carico di lavoro di circa 600QP per una singola macchina "merce" in esecuzione nel cloud.

Il fatto è che è estremamente difficile fare lo stesso su una macchina SQL pur mantenendo gli stessi costi.

Altri casi d'uso popolari per MongoDB (anche per noi) sono la raccolta statistica, è estremamente efficiente nell'incremento di proprietà specifiche all'interno dei documenti, molto più, quindi la maggior parte dei sistemi RDBMS.

Ancora una volta, non è impossibile farlo in MySQL è solo più costoso e richiede più tempo (più abilità) che per una piccola azienda o un ambiente di sviluppo rapido significa che non può essere fatto.

Answer 3

Alcune API REST restituiscono i dati JSON (ad esempio molti dei API di dati del governo aperto). Se si desidera scaricare i dati REST in un archivio dati locale (nel caso in cui sia necessario eseguire l'analisi, ecc.), È banale l'ingestione di un oggetto JSON con MongoDB. Non è necessario definire uno schema da tavolo. Ancora meglio, se l'oggetto JSON cambia nel tempo (ad esempio l'API REST restituisce campi aggiuntivi) puoi comunque ingerire i dati in un solo passaggio. Provalo con un database relazionale!