为Shiny应用供数的高频更新数据应如何存储与访问？

ArcGIS Online 托管要素服务更新解决方案 #

• 可直接使用官方{arcgis}R生态工具包实现托管要素服务的更新：先通过arcgisutils包完成ArcGIS Online账号认证，获取目标托管要素服务的端点URL，调用update_layer()函数做增量更新，仅传输变更的要素行即可大幅降低更新耗时，也能规避全量上传的接口限流问题。
• 若全量数据体积过大导致更新接口超时，可采用分块更新逻辑：先调用truncate_layer()清空服务内旧数据，再按每批次1000-5000条要素的粒度分批次上传，避免单次请求超时。
• 针对Shiny加载慢的问题，可在ArcGIS Online后台为托管要素服务开启访问缓存，给常用查询字段、空间字段添加索引；Shiny端请求时不要拉取全量数据，通过arc_select()指定仅返回需要的字段，配合arc_filter()添加业务筛选、空间范围筛选条件，通常可将加载速度提升5倍以上。

非ArcGIS Online场景下Shiny高频更新数据最佳存储方案 #

根据数据体量、使用场景可选择以下方案：

• 数据量级<10G、无复杂多条件查询需求：优先选择云对象存储（如OSS、COS、S3等），将数据存储为parquet/geoparquet列式压缩格式，压缩率是CSV的3-5倍，且支持按字段、按筛选条件分片读取。Shiny端通过{arrow}包直接按需读取对象存储上的文件，不需要全量下载到本地；数据更新时仅需用更新脚本覆盖对象存储上的对应文件即可，无需重新发布Shiny应用，成本低且维护简单。
• 数据量级>10G、有复杂筛选/空间查询/多并发需求：选择支持PostGIS扩展的PostgreSQL云数据库，更新时通过{RPostgres}包写入增量数据，Shiny端按需编写SQL语句拉取对应数据，避免全量加载，性能远高于文件存储方案。
• 个人开发小项目、单表数据<100M：可直接用私有Git仓库存储数据，更新时推送最新数据文件到仓库，Shiny端通过{piggyback}包拉取对应文件即可，无需额外付费，维护成本极低。

内容的提问来源于stack exchange，提问作者romanceline