Architettura e re-design del database per la migrazione e il supporto di più client

2

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?

    
posta raul782 05.05.2018 - 03:45
fonte

1 risposta

0

Un database di documenti si trova MongoDB ha un modello di archiviazione molto diverso da un database relazionale come Postgres.

Se vai su MongoDB, dovrai scegliere tra normalizzato modello di dati o il modello incorporato :

  • Il modello normalizzato utilizza riferimenti per gestire uno a molte relazioni tra entità indipendenti. Non avrai bisogno di chiavi esterne, ma il database usa invece un riferimento a 12 byte. Navigare tra i record usando un riferimento è ultraveloce (più veloce che passare attraverso un indice). Tuttavia, per leggere tutti i dati relativi, è necessario disporre di più letture, il che rende i report un po 'più difficili.
  • Il modello incorporato memorizza i dati correlati insieme utilizzando le raccolte quando necessario. È più veloce per leggere tutti i dati correlati contemporaneamente, ma potrebbe essere più lento a scrivere, se le raccolte crescono dinamicamente. L'accesso potrebbe anche essere più lento se la ricerca / navigazione non viene eseguita in un documento ma nella raccolta (ad esempio, cerca tutti gli account correlati a un articolo specifico).

Se vai su Postgres, continuerai a utilizzare un modello relazionale basato su fk. Forse non è performante come le relazioni MongoDB, ma è piuttosto flessibile nei criteri di selezione.

Sarà difficile prevedere le esibizioni. I benchmark generalmente non tengono conto dei diversi modelli di dati che è possibile utilizzare in MongoDB. Le prestazioni dipenderanno anche dal tipo di attività (leggi, scrivi o quale mix) e dal numero di clienti. Tuttavia, in base ai dati non elaborati , sembra che Postgres sia ancora una scelta eccellente

    
risposta data 05.05.2018 - 22:47
fonte

Leggi altre domande sui tag