Voglio un banale esempio di dove MongoDB può scalare ma un database relazionale avrà problemi [chiuso]

In primo luogo, si adatta bene.

Quando un database MongoDB è troppo frequentato o troppo grande per un singolo server, è possibile aggiungere facilmente più server creando un cluster o un set di repliche di più frammenti. Scala in modo quasi lineare. Questo non funziona quasi altrettanto bene con la maggior parte dei database relazionali. Dai un'occhiata a elenco di limitazioni di MySQL quando lavori come un cluster , per esempio. La maggior parte delle voci nell'elenco non presenta problemi per MongoDB (o non si applica).

In secondo luogo, consente dati eterogenei.

Immagina, ad esempio, il database del prodotto di un negozio di computer. Quali proprietà hanno i prodotti? Tutti i prodotti hanno un prezzo e un venditore. Ma le CPU hanno una frequenza di clock, hard disk e chip RAM hanno una capacità (e queste capacità non sono paragonabili), i monitor hanno una risoluzione e così via. Come lo progetteresti in un database relazionale? Dovresti creare una tabella di valori di proprietà productID molto lunga oppure creare una tabella di prodotto molto ampia e sparsa con tutte le proprietà che puoi immaginare, ma la maggior parte di esse è NULL per la maggior parte dei prodotti. Entrambe le soluzioni non sono davvero eleganti. Ma MongoDB può risolvere questo problema molto meglio perché consente a ciascun documento di una raccolta di avere un diverso insieme di proprietà.

Alcuni esempi reali di un problema non avrei idea di come risolvere in modo ragionevole con SQL e un database relazionale da solo (forse è colpa mia).

Quindi abbiamo un database (comune relazionale) con circa 30.000 prodotti. Niente di così grande finora. Ognuno di questi prodotti ha molte caratteristiche. Ci sono quelli comuni come gruppo (cavi, antenne, custodie iphone ... circa 80), assortimento (in qualche modo simile ai gruppi: auto, hifi, mp3, solo 15), marca (30).

Poi arrivano i dati tecnici. Ogni articolo ha molti di quelli come colore, lunghezza del cavo, peso, volume. circa 200 tipi di valore e migliaia di valori.

E il più complicato: molti di questi prodotti appartengono a qualche tipo di auto (o a molti di essi) oa qualche tipo di dispositivo mobile. Quelli entrano in gerarchie nella forma come: marca (apple) model (ipad) type (1,2,3,4) e in alcuni casi generazione. (per le auto è simile, anche se invece di generazione abbiamo anni di costruzione)

Problema Passaggio 1:

Vogliamo la quantità di prodotti per ciascuno di questi attributi. Quanti sono rossi? Quanti sono nel gruppo di cavi? E così via.

Questo potrebbe parzialmente essere risolto con SQL. Sarebbe un sacco di domande e piuttosto brutto, ma penso possibile. Forse lento ma potremmo farlo ancora più brutto e mantenere i contatori in ogni tabella e aggiornarlo ad ogni cambio. Particolarmente difficile con quegli attributi in cui un prodotto può avere molteplici (come funziona con iPhone e altri 12 telefoni cellulari)

Ma ecco il passaggio due del problema:

Quando un cliente seleziona un attributo (diciamo che vuole vedere solo i prodotti rossi), vogliamo aggiornare tutti quei contatori in tempo reale. Ciò significa che avremmo query estremamente complicate (non è probabile abbastanza veloce in ogni caso) o mantenere contatori per possibili combinazioni di attributi (miliardi).

Quando ho iniziato questo progetto, hanno dato una prova all'opzione contatore e lo abbiamo fatto per un sottogruppo di attributi molto piccolo (gruppo, assortimento, marca). Il codice era brutto, buggy e lento. Inoltre ora disponevano di una tabella con contatori che era molto più grande della tabella dei prodotti.

L'utilizzo delle faccette di Apache Solr era in realtà la soluzione. Appiattisci le tabelle in un elenco di Documenti (uno per prodotto) che consente di ottenere tutti questi dati in tempo reale con query molto più semplici.

Puoi pensare in qualsiasi momento pensi che una tabella EAV sia il modo migliore per fare le cose (notoriamente lento nei database reali e difficile da interrogare), potresti aver bisogno di un database nosql. Questo è particolarmente vero quando non hai modo di sapere in anticipo quali sarebbero i campi. Un esempio potrebbe essere la memorizzazione dei dettagli dei test medici. Ogni nuovo test potrebbe avere dati completamente diversi che è necessario memorizzare. E mentre potevi (in teoria) modellare i test esistenti (con un sacco di tempo e impegno quanti ne ce ne sono migliaia), come faresti a sapere quali nuovi test potresti ottenere dai test (e forse dalle attrezzature mediche) che abbiamo " ancora inventato ancora.

The smaller the project/system the better, because it leaves less room for disagreement.

Questo è difficile perché NoSQL è migliore solo in ambienti di grandi dimensioni. Suppongo che tu intenda un esempio semplice e ne ho uno perfetto per te.

Supponiamo che tu stia creando un sito web di viaggi e che tu debba far viaggiare gli utenti da e sui 5.170 aeroporti statunitensi destinati a uno qualsiasi degli (5.1) aeroporti statunitensi (...) stessi ...

Ma ecco il Kicker, non tutti i voli sono diretti, devi dire all'utente anche tutte le opzioni di scalo, a volte 2 o 3 tappe. Devi anche dire all'utente tutte le opzioni su una finestra di 5 ore! E devi calcolare questo in meno di 10 secondi mentre l'utente è in attesa.

Questo è il relial DB Nightmare ... In NoSql, le rotte di volo sono solitamente impostate in pietra con alcune settimane di anticipo, quindi puoi calcolare tutti i Gazillions di possibili rotte in anticipo rispetto a un semplice cluster NoSql DB. ..

NoSql è il chiaro vincitore è un tale scenario.