Il modo migliore per conservare grandi quantità di dati (nessun database relazionale necessario)

Avere dati nella struttura "1,4,5,6,14,51, ..." come un valore di dati è un valore denormalizzato .

Diciamo che hai qualcosa che assomiglia a:

Person2's friends are: 1, 4, 5, 7, 14, 51
Person3's friends are: 1, 5, 7, 15, 50

E così via. Ora, facciamo la domanda "Quante persone considerano la persona 5 come loro amica?" Bene, in una struttura denormalizzata, andrai a prendere gli amici di ogni persona e poi romperli sul delimitatore, e poi vedere se 5 è in quella lista, incrementare il conteggio e andare avanti.

Con un database relazionale, hai una struttura che assomiglia a:

  +--------+     +----------+
  | user   |     | friends  |
  |--------|     |----------|
  | id (pk)|&lt-+--| from (fk)|
  | name   |  +--| to   (fk)|
  | ...    |     +----------+
  +--------+

E la tua domanda per rispondere a questa domanda è: select count(1) from friends where to = 5 E, beh ... hai finito. Hai esaminato una piccola tabella che può essere interrogata molto rapidamente.

Hai anche cose da fare se vuoi eliminare in cascata un'eliminazione per ripulire correttamente i riferimenti in altre tabelle (hai eliminato l'utente 5, assicurati che 5 venga eliminato da tutti gli utenti). Esistono elementi come coerenza, isolamento e durata (parte di ACID ) che aiutano a garantire che i tuoi dati mantengano la struttura corretta.

NoSQL ha il suo posto. Ma non è un database relazionale e non pretende di essere. Inoltre getta via le garanzie di ACID come trade off per la velocità e la facilità di clustering (parte della velocità). Ci sono momenti in cui non ti interessa ACID e preferisci l'API fornita da un database nosql (cioè stai creando un'istanza offline di un'applicazione e metti in cache tutte le richieste web - il tuo divanodb, essendo accessibile come richiesta web, significa che quello offline non ha bisogno di un altro database).

Suggerirei di leggere il tag nosql sul bliki di Martin Fowler (blog + wiki).

Esistono soluzioni in cui nosql si adatta abbastanza bene. LDAP è un protocollo antico che potrebbe essere considerato uno dei primi database nosql esistenti oggi. Non si accede tramite sql, ma si fa per la memorizzazione dei dati ... dati gerarchici. Funziona davvero bene per questi dati e molto velocemente. Ha clustering e consistenza finale e tutte le cose a cui pensi quando senti parlare di nosql.

Non vorrei implementare un sistema di chat in LDAP - non è la struttura giusta. Cercando di rendere i database relazionali ciò che fa ldap non è neanche un processo divertente.

Se stai pensando di farlo come un'esperienza di apprendimento. Qualcosa per capire come funziona nosql, sì ... vai avanti. Prova ad implementare un sistema di chat in mongo o divano. Molte persone hanno. Non sarei sorpreso se la chat di SE non fosse supportata da un tale archivio dati ... anche se non sono sicuro che il suo divano, o mongo ... il dominio di noSQL sia abbastanza grande in quanto due database nosql potrebbero condividere più in comune con mySQL che l'uno con l'altro nel design. Scegli un database di valori-chiave? o una colonna orientata? o uno orientato documentato? o un database grafico? oppure ... Wikipedia elenca 10 diversi tipi di NoSQL con 5 diversi sub-sapori del negozio di valori-chiave.

Suggerirei di leggere da SO SQL (MySQL) vs NoSQL (CouchDB) e inseguire i collegamenti e i collegamenti correlati su quella pagina.

Se i dati sono relazionali ... beh, è probabile che sia un database relazionale che stai cercando (e dovresti assicurarti di conoscere normalizzazione del database ).

Quindi ecco un esempio. Un sistema di elaborazione articoli presso una banca dovrà archiviare le immagini anteriori e posteriori del controllo, ma una singola banca può elaborare 6.000 articoli in un giorno (12.000) di immagini. Queste immagini non devono essere recuperate molto spesso, solo in un caso di ricerca.

Dal punto di vista dello storage ha più senso archiviarli sul file system piuttosto che sul disco perché i dati non cambiano continuamente, l'accesso può essere più lento e le dimensioni del database non aumentano di alcune centinaia di gigabyte al giorno e ciò influisce tempo per ripristinare i backup.

L'applicazione richiede una logica separata per scrivere e caricare immagini rispetto ai metadati memorizzati nel database e questo è un costo aggiuntivo da sviluppare e un file system separato deve essere mantenuto.

La memorizzazione di grandi blocchi di testo nel database è probabilmente meno costosa da sviluppare e gestire rispetto alla scrittura su un file system, ma a seconda del tasso di cambiamento, delle esigenze di recupero, del costo dello storage rispetto al capitale per acquistarlo potresti creare un caso per archiviarlo al di fuori del database.

Come nota a margine, la memorizzazione di elenchi in una singola colonna di un database crea incubi di programmatori che devono analizzarli quando hanno bisogno di un singolo valore. Utilizzare la R nel sistema di gestione dei database relazionali per preservare la sanità mentale.