内部测试显示，索引速度提升 20 倍以上，网页端删除 100 个文件性能提升超过 2.2 倍

当搜索结果几乎瞬间出现时，背后往往依赖低延迟架构的支撑。Synology 通过技术文章解析 Drive 如何在大规模场景下实现高效、可靠运行，并披露多项底层优化。

一、先建可扩展、可靠的基础

Synology 认为，应用要快，基础必须先稳。在软件层面，这意味着数据库模式、数据完整性机制等架构设计，必须能够承载海量数据，既不能在规模扩大时崩溃，也要始终保护数据安全。

二、移动海量文件：从“胖表”到 ID 树

过去，用户移动包含数十万个文件的大型项目文件夹时，拖放后往往需要长时间等待，系统也会变得迟缓。问题源于旧数据库中的“胖表”：它记录每个父文件夹与每个子项之间的关系，并保存完整文本路径。数据越多，这张表膨胀越严重。

为此，Synology 对 Drive 数据库进行重构，改为精简的、基于 ID 的树结构，并彻底取消胖表。现在，每个文件和文件夹只记录自身名称和直接父级 ID。该改动将原本耗时数分钟、消耗大量资源的操作变成近乎瞬时完成，使 Drive 能应对超大数据集。

三、平衡数据安全与性能：自定义检查点

为确保断电等情况下数据安全，每次文件变更或更新都必须被记录。但持续记录若管理不当，会带来明显性能波动，尤其在高并发更新时。旧方案依赖数据库引擎对预写日志（WAL）的默认自动设置。该机制会在变更永久化前记录操作，但在高强度活动下可能触发过频，造成性能停滞。

Synology 采用自定义检查点策略，将数千次小型写入合并为高效批次。这样既能利用 WAL 的数据持久性和并发处理优势，又能避免默认设置带来的性能开销。内部测试中，这一改动使 Drive 索引速度提升 20 倍或以上。

四、优化核心逻辑：网页端响应更快

基础稳固后，Synology 继续分析应用内部逻辑，寻找影响体验的瓶颈。用户在 Drive 网页门户中选择文件删除或共享时，瓶颈未必在数据库，而可能在于后台任务内部数据的处理方式。Drive 需要“打包”任务信息供内部流程使用，原有序列化方法开销较大，导致界面迟缓。

Synology 重新设计核心数据处理方式，从底层优化流程，显著提升 UI 响应。测试中，从网页门户选择并删除 100 个文件的性能提升超过 2.2 倍。Synology 认为，这不仅意味着删除更快，也说明优化基础内部流程能让整体体验更流畅。

五、平台集成：重启、版本控制更高效

Drive 与 DiskStation Manager（DSM）和 Btrfs 文件系统深度集成，进一步释放性能。

过去，重启 Drive 套件后，服务器需全面重新扫描每个文件夹，以确认离线期间的变化。大型部署中，这可能耗时数十分钟。Synology 改为连接 DSM 中专门的变更跟踪服务。该服务持续运行，即使 Drive 停止也保留所有文件变更日志。Drive 启动时只需向服务获取遗漏变更列表，从而将资源密集型扫描变成快速检查。

在版本控制方面，创意和技术团队常产生同一文件的多个版本。Btrfs 的 reflink 功能可创建指向相同数据块的“克隆”，不额外占用空间。Synology 将版本逻辑改为支持 Btrfs。新版本创建近乎瞬时，且几乎不增加存储。对于每次保存都完全重写的文件类型，如部分加密或视频格式，空间消耗仍会随变化增加，但对大量常见文件类型，该方案带来显著存储和速度优势。

六、可靠性与性能文化

Synology 强调，可信赖产品首先必须可靠。从臃肿数据库到响应式界面，从缓慢启动到节省空间的版本控制，这些改进体现了这一承诺。通过为规模重构数据库、实现 20 倍以上索引加速、借助更智能查询降低 CPU 使用率，并与平台深度集成提升存储效率，Synology Drive 面向现实需求进行了工程优化。

Synology 表示，其文化要求既构建坚实基础，也持续调优应用并掌握平台交互，从而处理复杂性，让用户享受快速、高效、可靠的解决方案。