使用node/express/postgresql与heroku搭建可快速搜索文件服务器的最简单方案是什么

核心架构实现要点 #

• 存储层选型：Heroku自带的临时文件系统是dyno重启就会清空，绝对不能用来存用户上传的大文件，需配合对象存储服务使用，禁止在服务器磁盘直接存储大文件，PostgreSQL仅存储文件元数据，存储文件本身完全不可行。
• 大文件上传优化：前端做分片上传，后端用busboy处理流式接收，不要用express-fileupload这类会把文件临时存到磁盘的中间件，大文件场景下内存和磁盘压力都扛不住。上传时直接把文件流推到对象存储，不经过本地落地，减少IO开销。
• 搜索功能实现：PostgreSQL本身的全文搜索能力足够支撑亿级元数据的搜索需求，给文件名称、自定义标签、文件类型这几个高频搜索字段建GIN索引，搜索响应速度可压到百毫秒级。如果需要支持模糊搜索文件名前缀后缀，额外加pg_trgm扩展，建对应的GIN索引即可，不用额外搭ES这类重型服务，减少运维成本。

模拟文件夹/文件层级结构的实现方案 #

• 数据库表结构设计：元数据表加parent_id字段做自关联，根目录的parent_id设为0或者null，区分文件和文件夹加type字段，值为file/folder。如果层级特别深（超过10层），额外加path字段存完整的层级路径，比如/文档/工作/2024/，查询某个目录下的所有内容直接匹配前缀就行，不用递归查询。
• 路径冲突处理：同一个父目录下不允许出现同名的文件/文件夹，插入数据时加联合唯一索引(parent_id, name)自动做冲突校验，不用额外写业务逻辑判断。
• 层级查询优化：如果用PostgreSQL的递归CTE查询整个目录树，10万级以内的节点查询速度完全够用，要是节点量更大，给path字段建B树索引，前缀匹配查询的速度比递归快3倍以上。

Heroku部署注意事项 #

• 调大请求超时时间：大文件上传下载默认的30秒超时肯定不够，把Heroku的路由超时调整到最多120秒，超大文件走分片上传拆成小切片，每个切片请求控制在120秒以内。
• 内存限制优化：Heroku的基础dyno内存只有512M，处理大文件流的时候一定要注意不要把整个文件读到内存里，所有文件操作全部用流式处理，内存占用可稳定压到100M以内。
• 数据库扩容：大文件场景元数据量增长很快，提前给PostgreSQL开自动扩容，不要等存满了再处理，会影响线上服务。

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