Come dovremmo gestire più richieste di rapporti sulle transazioni?

Question

Come dovremmo gestire più richieste di rapporti sulle transazioni?

#1 da (1 voti)
#2 da (1 voti)
#3 da (0 voti)

2

Stiamo sviluppando un sistema per il mercato al dettaglio e le sue funzionalità consentiranno ai clienti (in realtà club dei consumatori) di esaminare tutte le transazioni effettuate dai clienti finali.

Uno dei modi per ottenere queste informazioni sarà tramite un'API.

L'idea è che ci saranno richieste di rapporti con una data di inizio e una data di fine, e una risposta avrà tutte le transazioni tra quelle date.

Ci preoccupiamo che alcuni report siano molto grandi e che alcuni client richiedano ripetutamente rapporti, in questo caso il DB e la CPU saranno molto sovraccaricati.

Lo stesso server che gestirà queste richieste si occuperà anche delle transazioni al dettaglio effettive (ricevute dai dispositivi proprietari) e dell'applicazione Web.

Non siamo sicuri su come limitare le richieste di report dall'API in modo che non influiscano troppo sul sistema.

Quindi, come dovremmo affrontare questo scenario? qualche pensiero?

EDIT:

solo per chiarire: Quando ho menzionato i dispositivi proprietari intendevo i dispositivi "On-Location" che vengono utilizzati durante le vendite con i client finali, questo significa che queste richieste non dovrebbero essere ritardate, e questa è la preoccupazione principale.

Ancora una domanda: alcune persone hanno suggerito l'uso di thread con priorità, ovvero dando una priorità inferiore ai thread che recuperano i report, è una buona idea?

database api performance report-generation

posta Mithir 20.11.2011 - 11:20

fonte

3 risposte

1

Limita l'accesso API al più recente: giorno, settimana, mese, qualunque volume tu possa gestire. Tutto ciò che è più vecchio potrebbe essere fornito in file compressi precompilati da un sito di archivio ftp. La limitazione ovviamente sta cambiando il formato dei file archiviati.

Hanno solo bisogno dei dati per accedere ai propri sistemi di analisi e reporting o stai fornendo il codice per interrogare i dati?

risposta data 20.11.2011 - 16:06

fonte

0

C'è qualcosa chiamato "diagramma a cascata" (da non confondere con la metodologia di sviluppo del software a cascata). Ha tempo sull'asse X e attività sull'asse Y, come questo:

Activity A---->|
               |--- Activity B --->|
                                   | --- Activity C --->|

Ci sono strumenti per ottenere questo, ma fondamentalmente si tratta di registrare l'ora di inizio e di fine delle varie attività di una transazione, come il recupero di materiale dal DB, l'invio di materiale al client, l'attesa del client da eseguire il codice, ecc.

La chiave è che tutti questi passaggi sono sequenziali, sommando al tempo totale.

Questo può dirti se c'è un ritardo non necessario, ad esempio causato da un thread o processo in attesa su un altro senza che sia assolutamente necessario, su più macchine e connessioni.

Se utilizzi una tecnica come questa, puoi raggiungere rapidamente tutte le latenze inutili.

risposta data 21.11.2011 - 17:23

fonte

Leggi altre domande sui tag database api performance report-generation

Come ottimizzare un'attività complessa con più chiamate DB Questa aggregazione o composizione è questa?

score 1 · Accepted Answer

Se si imposta una regola aziendale in modo che 1 cliente possa richiedere al massimo 3 report al giorno e la durata totale delle date tra non sia maggiore di 30, è possibile progettare una tabella che il sistema controlla prima di una richiesta di report viene elaborato.

Un approccio migliore per studiare un po 'più ulteriormente i requisiti di segnalazione e considerare un approccio Data Mart. Spostare i dati sul server del data mart e lasciare che gli utenti eseguano i report tanto quanto desiderano dal server del data mart. Ovviamente questo richiederà più lavoro, ma è l'approccio migliore da un punto di vista dell'architettura e in futuro aiuterà i tuoi clienti con altre esigenze di reporting.