Architettura per dashboard che mostra statistiche aggregate

Naviga le tue risposte
3

Mi piacerebbe sapere quali sono i modelli architettonici più comuni per il seguente problema.

L'applicazione Web A ha informazioni su vendite, utenti, punteggio di reattività, ecc. Alcune di queste informazioni sono ad alta intensità di calcolo e hanno una logica di business complessa (ad es. punteggio di responsività).

Sto costruendo un'applicazione separata (B) per le attività di amministrazione interne che modificano i dati nell'applicazione web A e riportano dati dall'applicazione web A.

Per scrivere ho intenzione di usare una api riposante. Per esempio. crea una nuova entità, aggiorna entità, ecc.

Nell'applicazione B mi piacerebbe mostrare alcuni grafici e altri dati aggregati per i 12 mesi precedenti. Sto pianificando di memorizzare i dati aggregati per ogni mese in redis.

Alcuni dati dovrebbero essere aggiornati più spesso, ad esempio ogni 10 minuti.

Posso pensare a 3 modi per farlo.

  1. Un'attività pianificata nell'app B che si collega a un'API dell'app A che fornisce alcuni dati aggregati. Quindi l'app B la memorizza in Redis e la usa per visualizzare le pagine. Contro: rende il calcolo complesso all'interno di una richiesta web, richiede molto lavoro, ad es. API server e client, archiviazione, ecc., pros: la logica di business è ancora presente nell'app A

  2. Un'attività pianificata nell'app A che aggrega i dati in un processo non Web e li memorizza direttamente in Redis a cui accedere dall'app B.

  3. Un'attività pianificata nell'app A che aggrega i dati in un processo non Web e utilizza un'API nell'app B per salvarlo.

Mi piacerebbe sapere se esiste una soluzione architettonica ben nota a questo tipo di problemi e se no quali sono altri pro / contro per la soluzione che ho suggerito?

    
posta soulnafein 27.05.2014 - 18:41
fonte

2 risposte

0

Lo farei nel modo seguente:

Utilizzando lo strumento ETL e l'attività pianificata, ad esempio, otterrei i dati dall'app A e li memorizzeremo nella sua forma più grezza.

Da quei dati grezzi, userei l'app B per fare tutti i calcoli più pesanti e la visualizzazione.

Ciò mantiene i dati disponibili e pronti a manipolare nel modo desiderato, senza dover utilizzare l'app A tutto il tempo.

Mantieni le applicazioni separate, e salva e utilizza i dati solo se necessario, per semplicità.

    
risposta data 30.05.2014 - 13:24
fonte
1

Come ho detto nel commento, userei lo strumento ETL per estrarre i dati dal database dell'app A e forse anche dai log. Allo stesso tempo, trasformerei i dati grezzi in un cubo di dati, suppongo che per la dashboard sia necessario combinarli con la dimensione temporale.

L'output del processo ETL dovrebbe essere un dato più strutturato che ti aiuti a creare dashboard o a fornirli agli strumenti OLAP per l'analisi.

Durante l'operazione, lo strumento verrebbe pianificato per eseguire attività diverse a seconda delle esigenze, alcune potrebbero essere ogni ora, ogni giorno o ogni 10 minuti. Se sei preoccupato per l'impatto sul database di produzione, puoi configurare una replica del database da cui leggere.

ps. Anche se vuoi ancora creare un'API, lo strumento ETL può farlo anche per te, cioè leggere i dati e presentarlo come API con output in xml / json.

    
risposta data 02.06.2014 - 03:14
fonte

Leggi altre domande sui tag

Cosa succede in modo diverso quando si aggiunge un'attività in modo asincrono su GAE? Come eseguire il backup di dati e immagini in questo progetto? [chiuso]