Ciao,
sto provando ad utilizzare grafici, dashboards e indicatori vari che puntano ad un numero elevato (per modo di dire) di records e tabelle (ad es. 50K records che per un db sono normale amministraz).
Ho messo indici su ogni tabella, fatto viste etc.. ma il risultato è che la presentazione dei dati è assai lenta e poi se per caso si riaggiorna etc la pagina non finisce più. Praticamente inutilizzabile.
Io uso MySQL ma ho letto che SQLite ha una opzione di on memory che mi ispira molto (visto che SC su noSQL non se ne parla).
Qualcuno di voi mi da qualche dritta e se ha fatto delle prove / test (performance) ?
Grazie
SQLite e in memory option
Regole del forum
Nel forum è vietato fare pubblicità senza avere l'autorizzazione dello staf di Netspecial.
Nel forum è vietato fare pubblicità senza avere l'autorizzazione dello staf di Netspecial.
Re: SQLite e in memory option
Al di là del numero di record nel database, la differenza la può fare anche la query e il recordset risultato, se non erro i grafici sono fatti con interscambio di dati json, se il recordset risultato è di 20K righe... secondo me si siede.
Se le query sono già ottimizzate, non saprei cosa suggerirti, se non forse, come ho fatto in alcuni casi, nel creare tabelle subset delle righe di partenza dove i dati sono già aggregati e i filtri, ovviamente sono limitati.
Se le query sono già ottimizzate, non saprei cosa suggerirti, se non forse, come ho fatto in alcuni casi, nel creare tabelle subset delle righe di partenza dove i dati sono già aggregati e i filtri, ovviamente sono limitati.
Re: SQLite e in memory option
In generale...i grafici ed i report su quantità elevate di dati non si fanno leggendo i dati al volo.
Bisogna creare delle tabelle nelle quali salvare i risultati elaborati in precedenza (in background dal server, tramite trigger o altre procedure automatizzate o schedulate) e leggerli quando si genera la pagina.
In questo modo la lettura dei dati richiede pochi istanti. Anche quando l'elaborazione del dato statistico richiede diversi secondi o minuti.
Bisogna creare delle tabelle nelle quali salvare i risultati elaborati in precedenza (in background dal server, tramite trigger o altre procedure automatizzate o schedulate) e leggerli quando si genera la pagina.
In questo modo la lettura dei dati richiede pochi istanti. Anche quando l'elaborazione del dato statistico richiede diversi secondi o minuti.
-
- Messaggi: 116
- Iscritto il: 06 ott 2014, 08:56
Re: SQLite e in memory option
OK, grazie.
Mi dicono che comunque Fusion Chart tecnicamente "nun jea fà" sopra i 5.000 records (quindi non solo DB e query) quindi per applicazioni simil BI,
senza preparare troppi datamarts, mi sembra un po' dura.
Ho letto che sta uscendo o è in test mySQL 8 con interessanti caratteristiche e a tal proposito con nuove funzionalità anche NOSQL.
Anche qui però per utilizzare solo SC la vedo dura .... Per le connessioni e la gestione di quei tipi di dato ci vorranno anni.
Mi dicono che comunque Fusion Chart tecnicamente "nun jea fà" sopra i 5.000 records (quindi non solo DB e query) quindi per applicazioni simil BI,
senza preparare troppi datamarts, mi sembra un po' dura.
Ho letto che sta uscendo o è in test mySQL 8 con interessanti caratteristiche e a tal proposito con nuove funzionalità anche NOSQL.
Anche qui però per utilizzare solo SC la vedo dura .... Per le connessioni e la gestione di quei tipi di dato ci vorranno anni.
Re: SQLite e in memory option
Ciao, il concetto di "non ce la fa" è relativo alla lettura di 5.000 record.
Quello che dico io è che un grafico è la rappresentazione in somma, media, periodicità o altro... di un insieme di dati.
Se le operazioni di somma, media ecc... non le fai runtime ma le leggi da una tabella riassuntiva, allora il grafico si aprirà in un lampo.
Esempio:
devo mostrare un grafico con il fatturato mensile di un anno di ecommerce con migliaia di acquisti al giorno...
Se faccio una mega query ogni volta che devo visualizzare il grafico, di sicuro sarà lentissima e farò fatica a visualizzare il grafico.
Se invece salvo in una tabella il fatturato complessivo di ogni mese, la query leggerà solo dodici righe ed il grafico si aprirà in un istante.
Quello che dico io è che un grafico è la rappresentazione in somma, media, periodicità o altro... di un insieme di dati.
Se le operazioni di somma, media ecc... non le fai runtime ma le leggi da una tabella riassuntiva, allora il grafico si aprirà in un lampo.
Esempio:
devo mostrare un grafico con il fatturato mensile di un anno di ecommerce con migliaia di acquisti al giorno...
Se faccio una mega query ogni volta che devo visualizzare il grafico, di sicuro sarà lentissima e farò fatica a visualizzare il grafico.
Se invece salvo in una tabella il fatturato complessivo di ogni mese, la query leggerà solo dodici righe ed il grafico si aprirà in un istante.
Chi c’è in linea
Visitano il forum: Ahrefs [Bot] e 8 ospiti