R Shiny in Memory Application o noSQL

Question

Sto eseguendo una piccola app Web utilizzando la struttura lucida di R. Lo strumento non fa molto. Sta semplicemente filtrando i frame di dati con determinati parametri dall'interfaccia utente. Il problema che ho ora è il seguente. Se un utente accede all'app tramite http, impiega molto tempo per avviare l'app. Poiché i dati, che carico nello global.R, sono piuttosto grandi (~ 5 GB). Dopo un avvio iniziale, l'App funziona senza problemi, anche quando si riaccede in un dato momento (l'app sembra essere completamente in memoria, per alcuni minuti). Dato che ho abbastanza memoria disponibile e i miei dati non cambiano in base all'interazione dell'utente, mi chiedo se potrei tenere l'app completa in memoria. È possibile forzare questo? Il mio server è in esecuzione centOS 6. Anche il problema non è il file system, l'hard disk, ecc. - Ho creato un ram disk per caricare i dati, ma l'aumento delle prestazioni è marginale. Quindi il collo della bottiglia sembra essere R, durante l'elaborazione dei dati.

Ora ho due idee, che possono superare il problema.

• Proprio come ho già detto, è possibile mantenere l'app completa in memoria?
• Non salvare i dati come oggetti R, utilizzare invece un DB noSQL veloce ad es. Redis che è in memoria

maggio uno di voi ha qualche esperienza quando si carica i dati più grandi. Sarei grato se potesse iniziare una discussione. Se è possibile, vorrei evitare il software esterno, come Redis, per mantenere tutto il più semplice possibile.

Con tutto il meglio,

Mario

Answer 1

Non ho esperienza con i database NoSQL, ma ecco come sto combinando lucido con un database Oracle per accelerare le mie applicazioni:

input dell'utente vengono passati a una query sql che viene inviata al database estremamente veloce e solo l'output di questa query viene letto in R. In molti casi (specialmente se lo sql implica un gruppo per istruzione) questo riduce il numero di osservazioni da leggere da diversi milioni a poche centinaia. Quindi, il caricamento dei dati diventa molto veloce.

Nell'esempio seguente gli utenti selezionano prima i questionari e l'intervallo di date. Questo genera una dichiarazione SQL che filtra le osservazioni rilevanti e conta le frequenze delle risposte per domanda e questionario. Queste frequenze vengono lette in R e visualizzate come dati nell'app lucida.

library(shiny) 
library(ROracle) 
library(DT) 

drv <- dbDriver("Oracle") 
con <-dbConnect(drv, username = "...", password = '...', dbname = "...") 

query <- 'select distinct questionnaire from ... order by questionnaire' 
questionnaire.list <- dbGetQuery(con, query)$questionnaire 


ui <- fluidPage(
     selectInput('questionnaire_inp','Questionnaire', 
        choices=questionnaire.list,selected=questionnaire.list,multiple=T), 
     dateRangeInput("daterange_inp", "Date range", 
        start='2016-01-01', end=Sys.Date()), 
     dataTableOutput('tbl') 
) 

server <- function(input, output) { 

    output$tbl <- renderDataTable({ 
    query <- paste0(
     "select questionnaire, question, answer, count(*) from ... 
     where title in (", paste0(shQuote(input$questionnaire_inp), collapse=","), ") 
     and date between to_date('", input$daterange_inp[1] ,"','YYYY-MM-DD') 
     and to_date ('", input$daterange_inp[1] ,"','YYYY-MM-DD') 
     group by questionnaire, question, answer") 
    dt <- dbGetQuery(con, query) 
    datatable(dt) 

    }) 

shinyApp(ui = ui, server = server) 

Answer 2

È possibile set the timeout to be a longer value. Non sono sicuro che sia possibile un valore infinito (o un valore abbastanza lungo).

Altri modi che non dipendono da un database possono essere:

1. uso data.tablefread se si legge da CSV. Questo può essere più volte più veloce di read.csv. Specificare le classi di colonne può migliorare ulteriormente la velocità.

2. Oppure utilizzare il formato binario .RDS che dovrebbe essere veloce e di dimensioni più piccole, quindi più veloce da leggere.

Se si utilizza .RDS.Rdata già non c'è molto da fare in questo aspetto.