Perché NoSQL è migliore per questo scenario?

5

Scenario ipotetico: diciamo che stiamo scaricando JSON da Facebook con i dettagli dei check-in, post di un amico di un utente ... Questi vengono come un documento per amico per attività, quindi con 8 attività un utente con 300 amici causerà il nostro sistema per effettuare 2400 richieste su Facebook, scaricando 2400 documenti JSON.

Diciamo che vogliamo unire questi 2400 documenti insieme, ordinare le attività per data_creato discendente e poi sfogliare le pagine in una sorta di pseudo newsfeed. Per favore non commentare la saggezza di ricreare un newsfeed di Facebook in questo modo.

Supponiamo inoltre di voler scaricare nuovamente tutti questi dati ogni volta che ci viene comunicato che è stato modificato da Facebook. (FB ha un servizio di aggiornamento a cui puoi iscriverti per gli utenti della tua app). Per argomento, supponiamo che tutti i dati debbano essere aggiornati ogni 5 minuti e supponiamo inoltre di voler supportare 1000 utenti simultanei e che la dimensione media del documento JSON sia 25kb.

Sono curioso di sapere come le tecniche NoSQL sarebbero migliori rispetto all'analisi del JSON sull'ingestione in un database relazionale? Per me sembra che la mappa / riduzione siano solo sinonimi di analisi / aggregazione e che entrambi gli approcci richiederanno la stessa cosa. Quali vantaggi otterrei dall'utilizzare NoSQL?

    
posta Infin8Loop 05.02.2013 - 18:40
fonte

2 risposte

6

What advantages would I get from using NoSQL?

NoSQL scalerà meglio con il crescere del numero di utenti.

Gli RDBMS tradizionali non si adattano davvero bene. Tutto ciò che puoi fare è lanciare macchine più grandi al problema. Non sono adatti ai sistemi distribuiti (cloud ad es.).

NoSQL è (in determinate circostanze) migliore nella gestione di strutture gerarchiche come documenti / JSON.

Il punto chiave da comprendere è che questi meccanismi di archiviazione sono basati su valori-chiave e quindi possono recuperare dati archiviati insieme molto velocemente, al contrario di dati che sono "semplicemente correlati" (quali RDBMS sono stati costruiti per).

Nel tuo caso ciò significherebbe che puoi facilmente recuperare tutti i record per un certo utente molto velocemente, ad esempio. Nei database relazionali tradizionali è necessario denormalizzare lo schema per le prestazioni o mantenere pulito lo schema, ma potenzialmente subire penalizzazioni delle prestazioni causate da join o aggregazioni pesanti.

Guarda in questo modo: perché una mappa hash (key value store) è veloce? È possibile recuperare elementi da una hashmap in quasi O (1) poiché l'hash si traduce direttamente in un indirizzo di memoria (semplificato). La ricerca di un indice binario in contrasto con quello produrrebbe O (log (n));

Per il tuo caso, MongoDB o CouchDB potrebbero essere buone soluzioni, poiché sono già basate su JSON.

Secondo me, usare una soluzione NoSQL qui è una buona scelta. Vuoi recuperare tutte le attività di un utente come feed. Se sono scritti correttamente nell'archivio dati, NoSQL dovrebbe, in teoria, eccellere in questo, senza la necessità di unire qualsiasi cosa o di preoccuparsi degli indici appropriati. @Earlz ha anche detto che non hai garanzie ACID per i database NoSQL. Ciò rende NoSQL veloce e probabilmente non hai bisogno di proprietà ACID per la tua applicazione. Fai un tentativo!

Inoltre, c'è un buon articolo di Martin Fowler sull'argomento. Ha fatto un bel diagramma che mi piace molto:

Vai consulta le sue pagine per leggere alcune profonde riflessioni su NoSQL.

    
risposta data 05.02.2013 - 19:05
fonte
1

Prima di tutto un database NoSQL è un database che non utilizza un'interfaccia SQL. Ciò che tutti i database NoSQL hanno in comune è che non usano un'interfaccia SQL. Mi sono appena ripetuto? Sì, ma non c'è nient'altro da dire sui database NoSQL come gruppo. Qualsiasi altra cosa che viene detta sui database NoSQL su Internet è errata per alcuni membri del gruppo, o probabilmente lo sarà in futuro in qualche momento con il rilascio di un nuovo database o di un upgrade di funzionalità di uno esistente.

Tutto questo per dire che chiedere se un database NoSQL è una buona scelta per un particolare lavoro non è una domanda in grado di rispondere dato che diversi database NoSQL hanno caratteristiche enormemente diverse.

Nello scenario che descrivi il problema più grande sarebbe sicuramente che stai martellando Facebook con 8000 richieste HTTP al secondo, ma ignoriamolo e concentrati sul problema abbastanza comune di avere una grande quantità di piccoli pezzi di dati.

Gestione dei dati

A parità di altre condizioni, qual è la differenza di prestazioni tra il recupero di una stringa da 8 byte e una stringa da 16 byte da un database? È insignificante e, escludendo qualche oscuro controesempio che è vero per qualsiasi database, SQL o meno, il sovraccarico di tutto ciò che accade in una richiesta fa sembrare il tempo necessario per copiare 8 byte in più. Se vuoi spostare velocemente i dati attraverso un database, ordinarli in grossi blocchi adatti al tuo caso d'uso è una delle cose più significative che puoi fare, spesso molto più importante di quale software di database usi.

Ovviamente ci sono casi in cui il tuo uso non si adatta a grandi blocchi di dati, in alcuni casi una strategia di memorizzazione nella cache in cui i dati vengono mantenuti sia nella forma di suddivisione originale che in blocchi può funzionare bene, in altri casi non c'è un molto da fare ma mantenendo separati i piccoli pezzi.

Manipolazione dei dati

I database sono lenti, vale a dire se si implementa una funzione di manipolazione dei dati in un programma comune, ad esempio prendendo un sacco di piccole stringhe e unendole in una sola e implementando funzionalità simili attraverso una richiesta di database, quindi la versione del database richiede in genere da 100 a 1000 volte il tempo necessario per eseguire l'operazione. Ovviamente la cifra esatta dipende dal database, alcuni database non saranno in grado di farlo, quindi dovresti scrivere un programma che recuperi tutti i dati, esegua l'operazione e poi scrivi il risultato nel database, che è anche un metodo piuttosto lento.

In generale, non fare sul database ciò che potresti ragionevolmente fare ai dati prima che vengano scritti nel database.

Quale database scegliere

Dopo aver preso tutte queste considerazioni, quali sono i requisiti per un database? Sei riuscito a creare una struttura che non ha bisogno delle caratteristiche fantasiose / lente offerte da alcuni database? Se lo facessi, un database SQL potrebbe essere come un coltello svizzero con una lama opaca, molte caratteristiche interessanti, ma non particolarmente adatto a quello che ti serve. Alcuni dei database NoSQL sono semplicemente più veloci e migliori quando servono solo le funzionalità semplici, altri adattano il lavoro allo stesso modo di un database SQL.

La grande domanda

Nonostante sia stato scritto per ultimo in questo post, è la domanda che dovresti fare prima di tutte le altre domande che ho menzionato. Hai davvero bisogno di un database?

È un'ipotesi comune che quando si gestisce una quantità significativa di dati, è necessario utilizzare un database. Ma con un computer moderno è possibile memorizzare diversi gigabyte di dati nella memoria dell'applicazione. Questo ti dà accesso rapido e facile, e i buoni strumenti per la manipolazione sono a portata di mano. L'unica cosa che non ti dà è la persistenza, se il crash del programma di c'è una perdita di energia i dati vengono persi. In molti casi è comunque perfettamente accettabile, il tuo esempio ha dati con una durata di ~ 5 minuti, non ha bisogno di persistenza, non ha bisogno di un database.

    
risposta data 05.02.2013 - 21:50
fonte

Leggi altre domande sui tag