Se è necessario accedere alle informazioni dell'applicazione da un database per l'analisi, è meglio copiare prima le informazioni e analizzare la copia oppure è possibile analizzare i dati recuperati dal database dell'applicazione?
Il problema con nosql è che è come tornare indietro nel tempo fino all'età delle unità nastro. In base alla mia esperienza, fa schifo per quasi tutto ciò che è di piccole e medie dimensioni, in particolare le statistiche in cui si dispone di un numero molto elevato di righe piuttosto piccole, è necessario accedere a molte di esse e DECIMALI REALI, non FLAPPY CRAPPY sono talvolta piacevoli da avere. Di recente stavo pensando da dove arriva l'hype ... penso che provenga da aziende multimilionarie che potrebbero permettersi migliaia di server che eseguono nosql perché in questo modo è molto più economico e sicuro scalare applicazioni di grandi dimensioni rispetto all'assunzione di grandi team tecnici per progettare e mantenere il cluster SQL.
Ed è davvero sorprendente che i loro sviluppatori che hanno bisogno di disinfettare manualmente ogni dato non finiscano in manicomio in gran numero;)
Stavo facendo alcuni test delle migliori soluzioni nosql disponibili come 2 settimane fa, quando ho inserito un valore di 1 giorno di statistiche (circa 2-3 milioni di righe) - cosa richiedeva meno di 100 ms in mysql, non ottimizzato - ha preso il sopravvento 10 secondi in nosql con alcune ottimizzazioni sullo stesso hardware. Per non parlare del fatto che le funzioni di aggregazione standard non funzionavano perché c'erano "troppe righe da aggregare" e dovevo scrivere i lavori di riduzione delle mappe. Che è veramente patetico. Alcune query semplici, aggregate / ordinate, che impiegano 20 secondi per scrivere in SQL, impiegano giorni a fare il "database" nosql e continuano a succhiare.
Penso che se non hai 5-10 server e non sei estremamente annoiato alla ricerca di qualcosa di stupido da fare con la tua vita, allora dimenticalo. JSON è una schifezza per la memorizzazione di grandi quantità di dati. Il tempo necessario per analizzare questa merda gonfia e mandarlo in giro ti ucciderà. Ci sono alcuni casi legittimi per un'unità nastro e per nosql ... ma è stato firmato per utilizzare un'unità nastro solo perché "ha più spazio".
Se ti preoccupi delle statistiche aggiuntive, memorizza la maggior parte dei dati in colonne normali e utilizza le colonne JSON per memorizzare tutto esotico. Almeno gli utenti non attenderanno 10 minuti per ottenere un rapporto sulle metriche usate di frequente, e per le cose meno utilizzate puoi mettere un avvertimento che prenderà, ad es. 20 minuti per generare.
Per usare il DB delle applicazioni per fare query lunghe e analitiche ... puoi progettarlo "correttamente" usando un motore basato su MVCC che è molto difficile da fare e quindi puoi fare le tue query insieme alle query di applicazione senza bloccare i dati, oppure può usare il modo standard di "spostare i dati intorno" chiamato replica in modalità master-slave, fare interrogazioni analitiche sulla replica e risparmiare un paio di mesi di vita più giorni di inattività dell'applicazione quando si scopre che MVCC non è sempre così grande come pubblicizzato:)
Questo è piuttosto ampio
Per prima cosa è necessario progettare un database per le funzionalità quotidiane.
Probabilmente vorrete qualche analisi in tempo reale per l'utente che probabilmente userete solo il design del database esistente.
Per i dati storici potresti avere una tabella dedicata in cui una colonna è il nome della funzione in modo da poter eseguire analisi sulle funzionalità. E / o cercare correlazioni tra le funzionalità. Può trattarsi di un database esterno di tipo NoSQL, ma non lo chiamerei dati non strutturati in quanto necessitano di una struttura sufficiente per eseguire l'analisi.
Leggi altre domande sui tag database-design data information analytics