闪亮的服务器：在服务器上更新数据的最佳做法是什么

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)
}

重新加载以 shiny 加载的文件的最佳做法是什么？

感谢您的任何意见！

Answer 1

让我尝试重新构建您的问题，定位您所指的一些论文/示例代码。

在非常高的水平上（即不必太担心反应性），R + shiny与将数据作为 ETL 过程的一部分的标准方式没有区别（例如）。

即您可以将以下类型的外部数据之一加载到闪亮的服务器中：

加载静态数据，即驻留在文件中的数据文件系统，或执行 RDBMS 查询。这是标准案例涵盖了大部分用法。
加载动态数据。这通常指的是数据流您正在尝试分析的某种类型（即不坚持将其放入文件或 RDBMS table).

先说说第一种情况的不同变种，静态数据:

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

上面的代码将运行查询每次反应函数被执行。

这就是反应性大有帮助的地方：例如，在没有其他更改的情况下，上面的代码将为每个连接到应用程序的用户执行一次。

如果外部进程频繁更新基础数据，则不同用户的结果可能不同。

此外，任何导致反应式构造重新执行的操作，都会重新执行查询（例如，只需刷新浏览器，查询就会重新执行，因为每次浏览器刷新都会生成不同的会话）。

你应该从任何闪亮的培训中知道，接下来的步骤可能是 link 上面的响应式结构到其他一些 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 中看到或实施过的那样，您的数据经常发生变化。假设文件（或 table）由外部进程不断更新。

请注意，这个用例通常仍然被认为是静止的，即使更新频繁（您正在通过批次处理数据，或者如果间隔真的很小，则为小批次）。

这是您的第一个示例，其中 reactiveFileReader 和 reactivePoll 的不同结构开始发挥作用。

如果您有一个文件（例如日志文件）经常被外部进程更新，您可以使用 reactiveFileReader.

如果您有数据库 table，您可以使用 reactivePoll.

每 x 秒轮询一次

在这里您的代码可以享受反应性的全部好处：自动代码将每 x 秒为您执行一次，并且所有其他依赖于它的反应性代码也将执行精神焕发。

现在，假设您尝试减小闪亮检查数据的 *批量大小"（即 window）。您能走多远？

如果我没记错的话，前一段时间与 Joe Cheng 的讨论，他相信 shiny 每秒能够处理高达 50,000 events（想象一下轮询您的数据库或读取您的文件高达每秒多次）。

假设我没记错的话，无论如何我会考虑 50,000 events 一个理论限制（你必须扣除在 RBMS 中查询数据所花费的时间，可能是通过 LAN 等），所以对于文件访问，我会使用 > 1 毫秒的时间（即每秒 <1,000 个文件读取），而 RDBMS 的时间间隔要大得多。

因此，上述函数的时间单位是毫秒也就不足为奇了。

我认为通过上述构造，可以使用 R + shiny 非常雄心勃勃的 micro-batch 管道来实现。

甚至可以想象使用 Apache Kafka 将数据发布到 R + shiny（也许使用具有负载平衡的 Shiny Server Pro 的多个实例为 Kafka 提供服务：太棒了！）`

那么，动态数据呢？

好吧，如果您以 R and shiny 可管理的速率从消防站获取数据，您就可以了（您可能很难确定将哪种 R 算法用于此流式处理用例，但是这值得另一个问题）。

另一方面，如果您的流程需要非常低的延迟，远远超出上面指定的延迟，您可能需要考虑其他类型的工具和管道（例如使用 Apache Flink 或考虑 ad hoc代码）。

对于非常冗长的解释深表歉意。如果它能让这个复杂的话题变得更清晰，请告诉我。

闪亮的服务器：在服务器上更新数据的最佳做法是什么

shiny server: what is the best practice to update data on the server

shiny

shiny-server