生产环境下如何更新Streamlit所用DuckDB？规避读写互锁方案

针对文件型DuckDB在Streamlit场景下的读写互锁问题，核心思路是分离读写操作的目标文件或借助中间层管理并发，以下是几种可落地的最优方案：

一、双文件原子切换策略 #

这是最轻量化且无需额外依赖的方案，核心是用两个数据库文件实现读写隔离：

• 维护两个DuckDB文件：prod.db（供Streamlit只读访问）和staging.db（同步程序写入用）
• 同步流程：
  1. 每次同步前，复制当前prod.db到staging.db（如果是增量同步，可基于prod.db的快照直接拉取新数据，避免全量复制）
  2. 在staging.db中执行数据同步（插入/更新遗留数据库的新记录）
  3. 同步完成后，原子替换prod.db为staging.db（Linux用mv staging.db prod.db，Windows用MoveFileEx API，确保替换操作无中间状态）
• Streamlit端：始终以只读模式连接prod.db，现有连接会基于旧文件的快照继续提供服务，新会话会自动加载替换后的新文件，完全无中断。

二、DuckDB服务器模式 #

如果可以接受额外维护一个服务，用DuckDB的服务器模式能彻底解决并发问题：

• 启动DuckDB服务器：duckdb -h 0.0.0.0 -p 5439 prod.db（默认端口5439）
• Streamlit和同步程序都通过客户端连接服务器：con = duckdb.connect('host=localhost port=5439 database=prod.db')
• 服务器会统一处理所有读写请求，自动管理并发锁，无需再担心互锁问题，同时支持多客户端同时读写。

三、快照式增量同步 #

利用DuckDB的快照功能，在不影响主库读取的前提下完成同步：

• 同步程序先对prod.db创建快照：CREATE SNAPSHOT OF prod AS 'sync_snapshot.db';
• 在sync_snapshot.db中同步增量数据
• 完成后，将sync_snapshot.db原子替换为prod.db
• 此方案和双文件切换逻辑类似，但借助DuckDB的快照机制减少了文件复制的开销（快照是写时复制，仅复制变更部分）

最佳实践 #

• 强制只读连接：Streamlit连接DuckDB时必须指定read_only=True，即con = duckdb.connect('prod.db', read_only=True)，避免意外占用写锁，同时提升读取性能。
• 增量同步优先：在同步程序中记录上次同步的时间戳/最大主键ID，从遗留数据库仅拉取新增数据，大幅缩短写入时间，降低冲突概率。
• 复用Streamlit连接：用st.cache_resource缓存DuckDB连接，避免每次请求新建连接（注意：DuckDB连接非线程安全，需为每个会话单独缓存）：

  @st.cache_resource
  def get_duckdb_conn():
      return duckdb.connect('prod.db', read_only=True)
  

• 拆分大写入：如果单次同步数据量过大，拆分为多个批次插入，减少单批次写入的锁占用时间。
• 监控同步健康：给同步程序添加失败告警（如邮件、企业微信通知），并记录同步日志，确保数据更新的可靠性。
• 用户主动刷新：在Streamlit仪表盘添加“刷新数据”按钮，允许用户手动触发连接重建，获取最新数据。

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