閃亮的服務器：更新服務器上的數據的最佳做法是什麼

Question

我有一個閃亮的應用程序，它是從一些文件加載​​數據。 在服務器上，在不中斷 服務器的情況下更新這些文件的最佳方式是什麼？

搜索互聯網，我發現這兩種解決方案：

1）使用reactivePoll()或reactiveFileReader()

http://shiny.rstudio.com/gallery/reactive-poll-and-file-reader.html

2）使用reactiveValues()

Update a data frame in shiny server.R without restarting the App

values <- reactiveValues() 
updateData <- function() { 
    vars <- load(file = "my_data_frame.RData", envir = .GlobalEnv) 
    for (var in vars) 
    values[[var]] <- get(var, .GlobalEnv) 
} 
updateData() # also call updateData() whenever you want to reload the data 

output$foo <- reactivePlot(function() { 
    # Assuming the .RData file contains a variable named mydata 
    plot(values$mydata) 
} 

重新加載閃亮加載的文件的最佳做法是什麼？

感謝您的任何意見！

Answer 1

讓我試着重新構思你的問題，定位你指的一些紙張/樣本代碼。

在非常高的水平（即不必擔心太多反應性），R + shiny與將數據作爲ETL過程的一部分（例如）處理的標準方式沒有區別。

I.e.可以加載到光澤服務器的以下類型的外部數據的之一：

1. 負載靜止數據，即駐留在文件中的文件系統 ，或執行一個RDBMS查詢數據。這是覆蓋大部分用法的標準案例 。
2. 加載運動數據。這通常指的是您嘗試分析的某種類型的數據流（即，沒有將 保存到文件或RDBMS表中）。

允許談論不同品種所述第一殼體的第一，靜止數據：

server <- function(input, output, session) { 
--- 
output$foo <- reactivePlot(function() { 
    someQuery <- dbGetQuery(...) # some query of a database 
    plot(values$mydata) 
} 
--- 
} 

上面的代碼將運行在每次執行反應性官能團時查詢。

這就是反應性可以幫助大家的地方：例如沒有其他更改，上面的代碼將爲連接到應用程序的每個用戶執行一次。

如果底層數據由外部進程頻繁更新，則不同用戶的結果可能會有所不同。而且，任何導致被動構造被重新執行的東西都會重新執行查詢（例如，刷新瀏覽器，查詢將被重新執行，因爲每個瀏覽器刷新都會生成不同的會話）。

正如你從任何閃亮的培訓中應該知道的，接下來的步驟可能是將上面的反應結構鏈接到其他UI元素，例如操作按鈕或selectInput來過濾數據。

server <- function(input, output, session) { 
--- 
output$foo <- reactivePlot(function() { 
if((length(input$actionbutton) ==0) | (length(input$selectData) == 0)) return() 
# the reactive now is connected to these two shiny inputs and executed every time they change 

someQuery <- dbGetQuery(...) # some query of a database, maybe with a *where* clause dependent on input$selectData 
    plot(values$mydata) 
} 
--- 
} 

現在查詢將被執行的每個動作時間按下按鈕或一個新的選擇時。

假設對於您的用例，我相信您已經在ETL中看到或實施過，您的數據經常會發生變化。假設文件（或表）由外部進程持續更新。

請注意，即使經常更新（您正在通過批處理數據，或者如果間隔非常小，小批量處理），此用例通常仍被視爲處於休眠狀態。

這裏是你的第一個例子，其中reactiveFileReader和reactivePoll的不同結構進場。

如果您有一個文件，例如日誌文件，由外部進程非常頻繁地更新，則可以使用reactiveFileReader。

如果您有數據庫表，例如您可以每隔x秒用reactivePoll進行輪詢。

在這裏，您的代碼可以充分享受反​​應：自動該代碼將每隔x秒爲您執行一次，並且您的所有其他反應代碼依賴於它也將被刷新。現在

，讓我們假設你試圖減少在其上的數據閃亮的檢查。能走多遠，你去*批次大小」（即窗口）？

如果我沒有記錯帶鄭元暢一段時間的討論回想起來，他有信心，有光澤將能夠處理高達每秒50,000 events（想象查詢您的數據庫或讀取您的文件多達每秒多次）

假設我記得這個正確的，我會反正考慮50,000 events一個理論上的限制（你將不得不打折在RBMS中查詢你的數據所花的時間，可能通過局域網等），所以對於文件訪問，我會使用大於1毫米的東西秒（即< 1,000個文件讀取每秒），以及RDBMS的更大的時間間隔。

因此上述函數的時間單位是毫秒不應該令人驚訝。

我認爲，通過上述結構，可以實現使用R + shiny非常宏偉的微批處理管道。

這可能是甚至有可能設想使用Apache Kafka數據發佈到R + shiny（也許使用的Shiny Server Pro多個實例與負載均衡服務卡夫卡：好吃）`

那麼，怎麼樣在運動數據？如果你從一個消防站以R and shiny可管理的速度獲得數據，你會沒問題的（你可能很難確定哪些R算法用於這個流式使用案例，但是這將會產生另一個問題）。另一方面，如果您的過程需要非常低的延遲，遠遠超出以上指定的範圍，可能需要考慮其他類型的工具和流水線（例如使用Apache Flink或考慮ad hoc代碼）。

道歉爲非常羅嗦的解釋。請讓我知道它是否使這個複雜的話題更清晰。