把多维表格搬回自己的机器：NocoDB 与 Baserow 的资源账到底该怎么算

三个人顺滑、三十个人卡顿，CPU 却一直闲着

一台看起来配置并不寒酸的机器，装上一套自托管的多维表格，最开始只有三个人在用：录入客户、改改状态、传几张图，一切顺滑。半年后团队扩到三十人，同几张表被同时打开，抱怨就集中爆发了——保存要转圈，筛选半天不出结果，协作光标时断时续。运维登上机器看监控，却发现 CPU 使用率并不高，内存也还有富余，磁盘更是只用了小半。这种"资源没吃满却慢得离谱"的落差，是自托管表格类应用最典型的误会现场。

问题出在估算方式上。多数人在决定要不要自托管时，只问了一个问题：这台机器能撑多少行记录？于是容量规划被压缩成一个数字，配置单也是照着"记录数"这一个维度填的。但表格类应用的真实负载至少来自三个互不相干的源头：字段与视图带来的读写放大、附件与历史版本吃掉的存储、以及实时协作维持的长连接与消息推送。这三笔账的计量单位都不一样——一个是每秒写入次数，一个是字节，一个是并发连接数——把它们混在一起算，得到的结论自然是错的。更要命的是它们会相互放大：字段多了，一次编辑的写入次数翻倍；在线人数多了，同一次编辑的推送扇出也翻倍；附件多了，备份窗口被拉长，恢复演练就更容易被跳过。所以这篇要做的，是把这三笔账分开算清楚，再谈叠加。

先分清两类自托管方案：映射已有库的 NocoDB 与自带后端的 Baserow

动手估算之前，得先确认你在算谁的账。NocoDB 与 Baserow 都能给你一个像在线表格一样的操作界面，但它们在架构上的位置完全不同，这决定了资源瓶颈最终落在哪一层。NocoDB 的思路是"映射"：它把已经存在的关系型数据库——SQLite、MySQL、PostgreSQL、SQL Server 等——映射成表格界面，并对外提供 API。它自己并不替代数据库，也不重新发明存储引擎。因此当它变慢时，你看到的往往是底下那个数据库在变慢：连接数被占满、某个排序字段没有索引、一次更新触发了连锁的写放大。上限由底库决定，优化手段也得到底库那一层去找。

Baserow 则是另一条路：它自带后端（Django 加 PostgreSQL）与前端，装好就是一整套。它提供网格、看板、表单、日历等多种视图，支持文件字段与实时协作，附件可以落到本地卷，也可以落到 S3 兼容的对象存储。好处是开箱即用的协作、视图与权限体系比较完整；代价是你要独立运维这一整套后端——应用进程、数据库、可能的异步任务队列与对象存储，每一层都会成为容量表上的一行。简单说，前者是给已有数据库套一层表格外衣，后者是引入一个新的业务系统。这个差别会贯穿后面三笔账的每一笔。

第一笔账：字段、视图与一次单元格修改背后的多次写入

把"一次单元格修改"理解成"一次写"，是这套估算里最容易出错的一步。在表格类应用里，用户在界面上改了一个格子，通常不会只产生一次写操作：行本身的更新是一次，变更或审计记录是一次，还要把这次变更推送给同一张表上在线的其他协作者。也就是说，一次人工编辑的写入量与"字段数 + 视图数 + 当前这张表的在线人数"近似成正比，而不是与行数成正比。

字段数的影响常被低估。一张三十个字段的表和一张八个字段的表，即便行数相同，单行更新的成本也差得远：公式字段要重算，关联字段要维护引用关系，某些字段类型还会触发额外的校验与索引维护。当团队习惯性地把所有信息堆进一张宽表时，每一次编辑都在为整张表的所有字段买单。视图数同理，每个视图本质上是一组查询条件，变更发生后需要判断这条记录是否影响各视图的结果集，视图越多，判断与推送的分支就越多。

所以第一笔账的正确算法不是"行数乘以人均编辑次数"，而是"单次编辑的写入放大系数 × 编辑频次"。放大系数由字段结构、视图数量、在线人数共同决定。这也是为什么同一套系统在小团队手里轻松、在中等团队手里吃力——行数可能只涨了三倍，但字段、视图与在线人数各自涨了几倍，乘起来就是几十倍。

视图的排序、分组、筛选最终会落到 ORDER BY、GROUP BY 与 WHERE

"记录数不多但很慢"这个现象，八成能在视图这一层找到答案。用户在界面上点一下"按截止日期排序""按负责人分组""只看未完成"，这些操作会被翻译成 SQL 里的 ORDER BY、GROUP BY 与 WHERE。如果对应的字段上没有合适的索引，数据库只能做全表扫描：五万行和五百万行在全表扫描下的体感差距，远小于"有索引"和"没索引"之间的差距。于是就出现了那种让人困惑的局面——表不大，却每次打开都要等。

跨表关联会让情况更复杂。一张表通过关联字段引用另一张表，视图里再引用关联表的字段做筛选，实际执行的就可能是多表 JOIN 加排序。层数一多，查询计划会变得难以预测，原本很快的视图在数据量增长到某个点之后突然变慢，而且往往不是线性变慢。判断方法不复杂：把视图对应的查询拿出来看执行计划，确认是否走了索引、是否有意料之外的临时表与文件排序。这一步在 NocoDB 这类映射式方案里尤其重要，因为查询最终由底层数据库承担，优化空间也全在底层。

还有一个容易被忽略的来源是 API 消费。当表格同时被脚本、自动化流程或外部系统写入时，写入的来源就不再只是人工编辑。人工编辑有天然节奏，API 批量写入没有。两者撞在一起时，短时写入量可能是平时均值的很多倍，而此时在线协作者还在接收推送，几股负载叠加在同一个时间窗口里。这也是为什么在估算时必须把"API 写入占比"单独列成一个变量，而不是笼统地算"日均操作数"。

第二笔账：附件、历史版本与备份体积的膨胀方式

第二笔账的单位是字节，但它的麻烦不在"占了多少"，而在"涨得多快、以及怎么备份"。附件是典型的大对象：一张产品图、一份扫描件、一段录屏，体积可以是普通文本字段的几千倍。当一张表里有一半的行携带附件时，表的"行数"这个指标就彻底失去了参考价值——一千行带图的表和十万行纯文本的表，存储压力可能相当。

历史版本是另一个 quietly 膨胀的来源。多维表格通常保留记录的变更历史，以便回滚与审计。开启版本保留后，每一次编辑都会留下痕迹，高频编辑的表在几个月内积累的版本数据可能超过原始数据本身。如果附件字段也纳入版本管理，副本会成倍增长。这一项在容量估算里最常被整段跳过，因为它在安装后的头几个月几乎看不出来，等到备份窗口被拖长、磁盘告警响起时，才被发现已经是个主要占用者。

正确的做法是给第二笔账单独列四个变量：单文件平均体积、携带附件的行占比、单位时间的附件新增量、以及版本保留策略。这四个变量乘出来才是存储的增长曲线。有了这条曲线，才能回答"多久需要扩一次卷""备份窗口会不会超出可接受时间"这类真正影响运维节奏的问题。

为什么不建议把附件直接写进数据库字段

把文件以二进制形式存进数据库字段，在数据量小的时候最省事——一个字段搞定，备份也只需要备数据库。但它的代价会随着数据增长迅速显现：数据库体积被大对象撑大，备份体积与恢复时间同步膨胀，而恢复时间的膨胀往往比体积更难受，因为在故障现场，恢复慢一分钟就是业务停一分钟。此外，大对象会挤占数据库缓存，把本该用来缓存索引与热数据的内存吃掉，间接拖慢所有查询。

更常见的做法是把文件放到对象存储或独立卷，数据库里只保存路径与元信息。这样做有三个直接收益：数据库体积保持在可控范围，备份可以分层做；附件可以走独立的生命周期策略，比如设保留期、做冷热分层、按需生成缩略图；恢复时也能按需选择"先恢复结构再补齐附件"。Baserow 支持把附件落到本地卷或 S3 兼容的对象存储，正是为这种分层准备的。代价是多一个组件要运维，路径失效与孤儿文件的风险需要靠规范来兜住——这也引出后面备份那一节的顺序问题。

第三笔账：实时协作的长连接数与推送扇出

第三笔账的单位是连接数，它和前两笔几乎没有换算关系。实时协作依赖 WebSocket 长连接：每个打开表格的浏览器都会维持一条连接，用于接收他人变更的推送。这条连接在空闲时几乎不消耗 CPU，也不产生查询，但它会一直占着一个文件描述符、一个进程或线程的槽位、以及反向代理上的一条连接记录。这就解释了开篇那个现象——CPU 不高，但新用户连不上、老用户频繁掉线。

推送的扇出是这一笔账的核心变量。一次单元格修改要推送给同一张表上在线的所有协作者，因此单次变更的消息量与在线人数近似成正比。十个人的表，一次编辑产生十条推送；五十个人的表，同一次编辑产生五十条。再叠加编辑频次，消息总量是"编辑次数 × 在线人数"的乘积关系，这是二次增长，不是线性增长。当团队反馈"人一多就卡"时，真正卡住的往往就是这个乘积，而不是磁盘或算力。

影响这一笔账的变量有四个：同时在线人数、平均每人打开的表数、单表的变更广播范围、以及服务端的连接上限与代理层配置。前三个来自业务使用方式，第四个来自部署。很多团队只调了第四个里的应用参数，却没有动反向代理，结果问题依旧。这就到了下一节。

反向代理那一层：WebSocket 掉线的三个常见诱因

WebSocket 连接要穿过反向代理才能到达应用，中间任何一环没配好，表现都是同一个：过一会就掉线，或者不断重连、光标闪烁。最常见的三个诱因是超时设置、连接头透传、以及文件描述符上限。

第一个是超时。反向代理默认的读超时通常按普通 HTTP 请求来设，而长连接的特点恰恰是长时间没有数据传输。代理在超时后主动断开，客户端表现为"每隔一段时间就重连一次"。解决方式是为 WebSocket 路径单独放宽读超时，而不是全局放宽所有请求。第二个是 Upgrade 头没有正确透传。WebSocket 的建立依赖 HTTP 协议升级，代理必须显式转发 Upgrade 与 Connection 头，否则升级失败，连接会在轮询与长连接之间来回退化。第三个是文件描述符与连接数上限。操作系统层面和代理层面各有一处限制，任何一处先到顶，后面的连接就会被拒绝或排队，表现为"一部分人能连上，一部分人连不上"。

这一层的排查有个简单顺序：先用浏览器开发者工具看连接是否被频繁关闭与重建，再看代理日志里是否有超时或升级失败的记录，最后核对系统级的文件描述符与代理的连接上限。三层都确认过，再回头看应用本身的参数。跳过顺序直接调应用参数，是最常见的无效优化。

备份与恢复：三层分别怎么备，恢复时按什么顺序

自托管表格系统的备份至少分三层：数据库、附件存储卷、配置与密钥。这三层的变化频率、体积、恢复难度都不同，应该分开制定策略，而不是用一个脚本全量打包。数据库层体积小、变化频繁，适合高频增量备份；附件层体积大、多为不可变文件，适合低频全量加增量同步；配置与密钥层体积最小但最关键，包括环境变量、密钥文件、反向代理配置、对象存储的访问凭据，这一层应该纳入版本管理并加密保存。

恢复的顺序比备份本身更容易出错，也更容易被忽略。推荐顺序是：先恢复配置与密钥，确保服务知道该去哪里找数据、用什么凭据访问对象存储；再恢复数据库，把表结构与记录还原到目标时间点；然后恢复附件卷或确认对象存储中的文件可用；最后做一致性校验，检查数据库里记录的附件路径是否都能对应到实际文件。如果顺序反过来，先恢复附件再恢复数据库，就可能出现路径对不上、附件成为孤儿文件的情况；如果先恢复数据库但配置里的存储路径或凭据还是旧的，服务起来之后会读不到附件，表现为"记录都在，图全是裂的"。

还有一件必须写进流程的事：定期做恢复演练。没有被验证过的备份，在统计意义上等同于没有备份。演练的频率可以按数据变化速度定，重点不是跑通，而是记录耗时——因为真正决定你能不能在可接受时间内恢复业务的，是"全链路恢复耗时"这个数字，而不是"备份有没有成功"这个状态。第二笔账里提到的附件与版本膨胀，最终就是在这个耗时上体现出来的。

本文只讨论自托管多维表格这一层的资源账，不展开具体服务器型号与采购价格

需要说明的边界是：上表讨论的是应用这一层的资源结构与估算方法，不涉及具体服务器型号，也不涉及采购价格与费用测算。不同版本的实现差异客观存在，同一套软件在不同版本间的索引策略、附件处理方式、协作推送机制都可能有调整，因此上表给出的是变量关系与排查方向，任何具体阈值都应以官方文档说明与自身压测结果为准。换句话说，这张表的用途是告诉你"该去量哪些变量"，而不是替你填数字。实际部署时，成本相关的部分需实时询价，机型与带宽以官网实时报价或咨询确认为准。

六步把容量估算落到纸面

第一步，清点表结构。把每张表的字段数、公式与关联字段占比、视图数量、是否带附件字段列成清单。这一步的输出是"写入放大系数"的定性判断：哪些表是重的，哪些是轻的。

第二步，统计编辑行为。区分人工编辑与 API 写入，分别记录单位时间的操作次数与峰值时段的集中度。人工编辑看工作时段分布，API 写入看任务调度时间，两者的峰值是否重叠是这一阶段的关键结论。

第三步，量附件。统计单文件平均体积、携带附件的行占比、月度新增量，并确认历史版本的保留策略。这一步的输出是未来若干个月的存储增长曲线，而不是一个当前的占用数字。

第四步，点人数。记录同时在线人数的峰值、人均打开的表数、以及热点表是哪几张。用"峰值在线人数 × 单表编辑频次"估算推送扇出的量级，判断协作这一层是否需要拆分。

第五步，查配置。核对反向代理的超时与升级头透传、系统与应用的文件描述符上限、数据库连接池上限。这一步不需要压测，只需要对照部署清单逐项确认，但它能排除掉相当一部分"莫名掉线"的问题。

第六步，做一次带恢复的演练。按前面说的三层备份与四步恢复顺序完整跑一遍，记录全链路耗时，并把耗时与业务可接受的中断时间做对比。这一步的结论会直接回头修正第三、四步的估算——如果你发现恢复时间已经超出可接受范围，那么存储增长曲线和附件策略就需要重新设计。

一万网络在整合自营节点与 BGP 多线资源过程中，为这类自托管业务系统做服务器配置参考时的做法，就是不先看核数与内存，而是先让对方把数据库、附件与长连接这三项负载分开列出来，再叠加成一份配置清单。

关于记录数、附件与协作人数的七个具体问题

记录数到多少才需要考虑扩容？单看记录数无法回答这个问题。同样的记录数，八个字段和三十个字段、带附件和不带附件、三个人在线和三十个人在线，结论完全不同。真正需要盯的是三个派生指标：单次编辑的写入放大系数、存储的增长曲线、以及峰值时段的消息扇出量。建议按上面六步把这三组数字量出来，再对照当前配置判断余量，而不是等行数到了某个整数才行动。不同版本的实现有差异，阈值需以自身压测为准。

附件能不能直接存进数据库字段？技术上可以，但不建议在中长期运行的系统里这么做。直接存进字段会让数据库体积、备份体积与恢复时间同步膨胀，还会挤占本该用于索引与热数据的缓存。更稳妥的做法是文件放对象存储或独立卷，数据库只存路径与元信息，代价是多一个组件要运维，并且需要规范来避免路径失效与孤儿文件。Baserow 支持本地卷与 S3 兼容对象存储两种落盘方式，正是为这种分层准备的。

同时在线协作的人数上限由什么决定？它由链条上最窄的一环决定，通常不是应用本身。依次为：服务端能维持的连接数、操作系统的文件描述符上限、反向代理的连接数与超时设置、以及消息推送的扇出能力。此外还要看业务侧的变量——人均打开的表数与热点表的集中度。判断方法是从这四层逐项核对，而不是只看某一层的参数。具体上限需以压测结果为准，不同部署环境下的差异可能很大。

视图和筛选条件变多为什么会拖慢整张表？因为视图的排序、分组、筛选会被翻译成 SQL 的 ORDER BY、GROUP BY 与 WHERE。缺少合适索引时会退化为全表扫描，于是"记录数不多但很慢"。跨表关联会进一步放大：每层关联都可能引入 JOIN 与临时表，让查询计划难以预测。处理方式是为常用排序与筛选字段建索引、减少层层叠加的关联视图、把重的视图改为定期物化结果。这也是"记录数不多却慢"最常见的原因。

API 写入和人工编辑撞在一起怎么处理？这两类写入的节奏完全不同：人工编辑有天然间歇，API 批量写入可能在短时间内产生远高于均值的量。处理方式是把它们当成两股独立负载分别计量，在 API 入口设置写入上限，并把批量任务排到在线人数低谷的时段。同时要意识到此时在线协作者仍在接收推送，几股负载会叠加在同一时间窗，因此错峰比单纯限流更有效。

备份要分成几层、恢复时按什么顺序？至少分三层：数据库、附件存储卷、配置与密钥。三层的体积与变化频率不同，应分别制定备份频率与保留策略。恢复顺序是配置与密钥、数据库、附件、一致性校验。先恢复配置是因为服务需要知道数据在哪里、用什么凭据访问；先恢复数据库再补附件，是为了避免路径对不上、附件变成孤儿。最后一步的校验重点是确认库里记录的附件路径都能对应到实际文件。

NocoDB 与 Baserow 的取舍标准到底是什么？核心看两件事：你是否已有可复用的关系型数据库，以及你的主要消费方式是 API 还是人工协作界面。已有数据库、以 API 消费为主的场景，更适合 NocoDB 这类映射式方案，因为它不替代数据库，瓶颈与优化手段都落在底库那一层，索引与连接数的经验可以直接复用。需要开箱即用的协作、视图与权限体系，且愿意独立运维一套后端的场景，更适合 Baserow。若选后者，就要把应用进程、数据库、异步任务与对象存储都列进容量表。

多维表格之外，自托管业务系统还有哪些账本文没有展开

本文围绕的是内部业务数据的多人协作与表单结构化这一类需求，因此三笔账都落在表格应用内部。但一套完整的自托管业务系统，账目远不止这些。身份认证与单点登录是独立的一笔：用户目录、会话存储、令牌刷新都会产生自己的连接与查询负载，而且它通常在所有业务之前被调用，故障影响面最大。审计与留痕是另一笔，它与正文提到的变更记录不同，后者服务于协作回滚，前者服务于合规与追溯，保留周期往往由外部要求决定，不能按业务需要随意清理。

还有几类账本文只提了边界：全文检索与报表导出会产生与在线人数无关的突发负载，通常在月底或季度末集中出现；消息通知与定时任务队列有自己的积压与重试语义，积压一旦形成，恢复时间不由数据量决定，而由消费速度决定；多环境（开发、预发、生产）的配置漂移会让容量估算在环境之间失去可比性。此外，对外内容交付是另一条完全不同的链路——它的瓶颈在缓存命中率与回源量，属于无头 CMS 那一类主题的讨论范围，与本文的协作写入模型基本不重叠。实时地理围栏、流式增量视图、容器成本分摊等主题也各有各的计量口径，不能套用这里的三笔账。

回到 NocoDB 与 Baserow：把三笔账分开写进容量表

回到最初那个冲突：同一台机器，三个人用很顺，三十个人用就卡，而 CPU 并不高。现在可以给出完整的解释——卡的不是算力，是三笔没分开算的账。字段与视图带来的写入放大，让一次单元格编辑变成多次写；附件与历史版本吃掉的存储，把备份窗口悄悄拉长；实时协作的长连接与推送扇出，按"编辑次数乘以在线人数"二次增长。它们各自独立，又互相放大：宽表增加单次写入，在线人数增加推送扇出，附件膨胀增加恢复耗时，而恢复耗时一旦超出可接受范围，又会反过来限制你对前两项的容忍度。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。在估算这类自托管业务系统的容量时，可把数据库、附件与长连接三笔账并入服务器租用与机柜托管的配置清单一起核。

因此，真正要落到纸面上的不是"能撑多少行"，而是一张三列的容量表：写入这一列记放大系数与峰值频次，存储这一列记增长曲线与保留策略，连接这一列记峰值在线人数与代理层上限。三列各自有余量判断，再叠加出整体结论。不同版本的实现存在差异，具体参数与阈值以官方文档说明与自身压测结果为准；涉及机型、带宽与费用，需以官网实时报价或咨询确认为准。把这张表写清楚，下次有人问"要不要扩容、先扩哪一档"时，答案就在表里，而不是在机器监控的平均使用率里。