Sto valutando la migrazione della seguente architettura dell'applicazione: - Nginx + PHP + MySQL - Attualmente l'infrastruttura è scalabile e ridondante nel cloud AWS ed è stata progettata per supportare un client.
Il nostro prossimo piano è di estenderlo per supportare più client, queste sono le mie preoccupazioni: 1- La natura dell'applicazione è focalizzata sulla raccolta di dati granulari da parte di un gruppo di aziende con una task force di utenti basata su un elenco di attività per articolo in un dato luogo. In breve: un utente può potenzialmente raccogliere circa 14,4k record al giorno (1 account x 2 campagne x 12 azioni x 12 attività x 50 articoli) Quindi un grande cliente con 50 dipendenti e 10 posti da visitare al giorno registra circa 7,2 milioni di righe al giorno, tutto può essere misurato (un testo, un file come in una foto o un video, ecc.) Il nostro modo attuale di memorizzare i valori più granulari in una tabella si basa sul modello EAV. Ciò consente all'app di essere molto flessibile, ma come puoi vedere genera una riga verticalmente. rendendo ridondante gran parte dei valori fk e crescendo in modo esponenziale quella tabella, ci dà alcuni problemi quando proviamo a eseguire report su questo database, a meno che non scarichiamo il report da qualche altra parte.
Mi chiedevo se passare a: - Gioca + Mongodb E rendendo la visita la nostra collezione principale ridurrebbe le informazioni ridondanti. Alla fine una visita sarebbe il nostro documento più importante e memorizzerebbe valori di 14.4k, ma tutto sarebbe contenuto all'interno. Ciò significa che, in termini di documenti, genererei con 50 dipendenti x 10 la possibilità di visitare solo 500 documenti al giorno, il che sembra molto più maneggevole dal punto di vista delle operazioni.
Tuttavia, il problema qui è il reporting granulare o cross-vertical, come un report della task force per il mese. Immagino che questo possa essere scaricato.
Avrebbe giocato + Postgres essere un'opzione migliore e usare la tabella con dati bjson con slick?