2026 实验室信息管理服务器租用测评：LIMS 样本链路与仪器数据 8 项对比 + 避坑大全

2026 实验室信息管理服务器租用测评：LIMS 样本链路与仪器数据 8 项对比 + 避坑大全

LIMS 的资源账从样本链路开始

给实验室配 LIMS 服务器，最常听到的算法是「我们有四十个检验员，按每人半核两 GB 往上加」。这个算法在几乎任何一套 LIMS 上都会给出偏小的答案，而且偏小的部分不在 CPU，在磁盘。原因很直接：LIMS 的资源消耗不跟着人走。一个检验员一天点几百次鼠标，写进去的字节数还不如一台液相色谱跑一个批次的原始数据文件大。人是链路的操作者，负载长在链路上。

把账重新拆开，自变量只有三个：样本链路的日吞吐、仪器原始文件的体量、审计轨迹要留多少年。三者性质完全不同。吞吐是每天重复、有峰有谷的流量，决定 CPU 与内存；文件是单向累积的存量，只增不减，决定磁盘与备份窗口；审计跟着业务动作复利增长，条目比业务行还多，决定数据库的写入形态与索引体积。三项要分别算完再相加，任何一项按「今年够用」估，十年后都是缺口。

粗糙的估算式可以写成：磁盘总量约等于业务行年增量乘行宽再乘索引系数乘留存年数，加审计行年增量乘审计行宽乘留存年数，加仪器文件年增量乘留存年数乘副本系数。取一个中型实验室的量级：每天三百到八百个样本、每个样本十几项检测，业务行一年百万级，含索引也就几十 GB（经验区间）；审计按三到十倍条目、单条字段更多更宽，能落到几百 GB（估算）；仪器原始文件一年一到三 TB（经验区间）。三项摆在一起，前两项的合计数还不到第三项的一个零头，这个比例关系才是容量规划的真正起点。

所以问题不是「买多大的机器」，而是「这台机器后面挂多少存储、存储怎么分层、十年后还能不能打开一份 2026 年的原始谱图」。CPU 与内存只决定白天的响应速度，存储决定的是三五年后审计来查记录时你能不能拿出证据。全文按八项拆：样本链路写入形态、审计轨迹增速、仪器文件年增量、内存归属（对象缓存还是缓冲池）、仪器接口与时钟、报告签发的 CPU 突发、十年留存的冷热分层、部署形态与故障域。顺序上先拆链路，再拆审计，再拆文件，最后才谈硬件与形态。

一条样本走七步，每一步都要留痕

一条样本在 LIMS 里要走完七步：样本登记（Sample Login）、任务分派、前处理、仪器检测、结果录入或自动采集、复核审批、报告（COA）签发，签完之后还有留样与归档。每一步都要落三样东西：时间戳、操作人、原始值。这三样不是日志，是记录本体的一部分——复核人签字时看的是这三样，审计来查时看的也是这三样。把它们当附加日志处理，系统在第一次内审时就会露馅。

按状态机数一遍写入量。登记写样本主记录加若干检测项；分派改状态加写分派记录；前处理每做一步（称量、离心、稀释、过滤）可能各写一条；仪器检测阶段写采集任务与原始文件引用；结果录入写检测值与单位；复核写审批记录与电子签名；签发写报告记录与版本号。一条样本从进门到出门，落在数据库上的写操作在十五到三十次之间（经验区间），碰上返工复检要翻倍。

把这个数字乘上日吞吐：五百个样本一天就是一万次上下的写（估算），摊到八小时工作时段，平均每秒不到半次。这个吞吐对任何一台现代服务器都是噪声，所以「LIMS 写入扛不住」这种说法基本不成立。真正会出问题的是时间分布：登记集中在上午八点半到十点，复核与签发集中在下午三点到五点，两段各占全天写入的六成以上（经验区间）。峰值时段每秒三到五次写，仍然很低，但它和批量的数据库维护任务、报表查询撞在一起时，响应时间会突然变难看。

比吞吐更值得担心的是事务边界。复核界面通常要一次性打开这个样本的全部检测项、历史版本、仪器原始文件引用，如果应用层把「加载、比对、写审批、写审计」包在同一个事务里，事务会跨越用户思考的那几十秒。一个样本占着行锁几十秒不可怕，可怕的是批量复核：勾选两百个样本点一次通过，一条长事务持有两百行锁几分钟，其他检验员的录入全部排在后面等。这类卡顿在监控上表现为活跃连接数飙升、CPU 却不高，典型的锁等待。可执行的做法是把批量操作拆成单样本事务加队列，界面立刻返回，后台逐条提交，失败的单条单独报出来重做。

审计轨迹比业务数据长得快

审计轨迹（Audit Trail）是 LIMS 里最不像功能、却最不能省的一块。它的规则只有三条：只追加、不修改、不删除。样本状态改一次记一条，检测值改一次记一条，复核通过记一条，报告重签记一条，连「查看了原始数据」这种动作在严格场景下也要记。记录内容包含表名、记录标识、字段名、改前值、改后值、操作人、角色、终端标识、时间戳，制药场景还要加变更原因与电子签名。字段多、文本长，单条在三百到八百字节之间是常态（经验区间），比业务表里的一行还宽。

条目数上，业务动作的每一步往往带出多条审计：录入一个检测结果，可能同时记「值写入」「单位换算」「超出规格标记」三条。经验上审计条目是业务行的三到十倍（经验区间），把条目倍数与行宽倍数相乘，审计表占用的空间常常是业务表的十到三十倍（估算）。这就是为什么一套「只有百万行业务数据」的 LIMS，数据库能长到几百 GB——业务数据是零头，审计才是主体。反过来说，任何按业务数据量报出来的配置单，都在这一项上少算了一个数量级。

索引还要再算一遍。审计表的查询方式很固定：按记录标识查某个样本的全部变更、按操作人加时间段查谁动过什么、按时间段导出某次内审范围内的全部记录。这三条查询对应至少三个索引，而审计表的索引列（操作人、表名、字段名、时间戳）都不窄，索引体积经常与数据本身持平甚至更大（经验区间）。分区是必须做的：按月或按季度分区，超过热期的分区转成只读，查询计划能直接跳过，物理上也能整块搬到慢盘。不做分区的审计表，五年后单表过亿行，一次按时间的范围扫描就能把缓冲池冲干净，随后整个系统的响应都跟着抖。

这也解释了为什么审计的落点不能与仪器文件抢同一块盘。审计要的是低延迟随机写与可预期的刷盘，仪器文件要的是大容量顺序写，两种 IO 形态放在一块盘上互相拖累。把数据库放在本地 NVMe、把原始文件放到独立的存储节点，是这类系统最朴素的正确做法。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。落在 LIMS 这个场景里，这句话的实际含义是：数据库节点要低延迟本地盘，文件节点要能加盘位、能扩容量，两类机器最好在同一机房内网互通，避免跨城同步把审计写入拖慢。

仪器原始文件才是磁盘黑洞

业务数据不大，仪器原始文件才是黑洞。一台液相或气相的色谱图，一次进样一个数据目录，里面有采集方法、通道数据、积分结果，几 MB 到几十 MB；质谱单次采集能到几百 MB；显微图像按视野切片存，一次切片扫描下来几个 GB 也不稀奇；再加上仪器软件导出的 PDF 原始报告、扫描的纸质记录影印件，品种非常杂。共同点是三个：不能压缩（原始数据要保真，压过的谱图在审计上等同于改过数据）、不能去重（每次检测都是独立事件，哪怕样本完全相同）、不能删（要与记录保存同样年限）。这三点决定了它只能靠买容量解决，不能靠优化解决。

按每天三百次检测、单次平均二十 MB 算，一天六 GB，一年二百五十个工作日就是一点五 TB（估算）；检测频次高、质谱与影像多的实验室，一年三到五 TB 也属常见（经验区间）。十年就是十五到五十 TB，再乘一点三的副本与临时文件系数，存储规划要按二十到六十五 TB 报。这个量级已经不能用「服务器自带几块盘」解决，必须在上项目时就把存储当成独立资源来规划，而不是等第二年磁盘报警再去加盘。

文件数量比容量更容易出事。二十 MB 一个文件，一点五 TB 就是七万多个，十年七十万个。全堆在一个目录里，目录项超过十万之后，任何一次目录遍历都会明显变慢，备份软件的扫描阶段会被拖成几小时；放在 NAS 上更糟，SMB 或 NFS 的元数据操作是网络往返，十万次状态查询就是十万次往返。对策是按日期或按仪器分目录，把每层目录的文件数压到几千以内，备份也能按目录做增量。这一条不需要花钱，只需要在建库的第一天就定下来，晚了就得停机搬文件，而搬文件期间的链路连续性是审计要问的。

还有一个被低估的指标：写入带宽。一台液相跑序列，每小时往共享目录写二到六 GB（经验区间），十台仪器同时跑，持续写入就是二十到六十 MB/s，全天不断。这不是公网带宽的问题，是存储侧内网带宽与磁盘持续写能力的问题。千兆内网的理论上限是一百二十五 MB/s，实际跑满也就一百一十 MB/s 上下，几台仪器加一台备份同时压上去就会排队，仪器软件那边表现为「保存失败」或者「文件被占用」，检验员只会觉得系统不稳定。所以仪器网段至少千兆独享，仪器多的实验室直接上万兆到存储节点，这一条比给服务器加 CPU 有效得多。

两种技术形态：对象库与关系库的内存差异

主流开源 LIMS 分两类技术形态，内存的用法几乎相反。一类是 Plone/Zope 系（Python，SENAITE 是代表），后端用对象数据库 ZODB，业务对象直接以 Python 对象形式持久化，对象缓存常驻内存，数据落在 Data.fs 这个持续增长的文件里。另一类是关系库系（PostgreSQL 或 MySQL，Java 系的 OpenELIS 一类再叠一层 JVM 堆），内存主要给连接池、共享缓冲与排序哈希这类查询工作区。选型时如果只问「支持多少并发用户」，两类都会回答一个漂亮的数字，真正的问题在内存被谁吃掉了。

对象库的内存曲线跟活跃对象数走，不跟行数走。ZODB 的缓存大小决定常驻内存的上限，命中时读一个对象是纯内存操作，毫秒级；未命中就要回 Data.fs 里按位置随机读，文件越大、随机读越散。经验上的临界点：Data.fs 涨到缓存容量的三到五倍之后（估算），对象加载开始频繁触盘，列表页与样本详情页的响应从几百毫秒爬到两三秒，而且加 CPU 完全没用，只有加缓存或者做数据归档才有效。这跟关系库「加内存就快」的直觉不一样，最容易误判成软件本身有问题。

关系库的坑在 work_mem。这个参数是每个排序或哈希节点可用的内存，不是每个连接的总量；一条带多个分组、多个关联的报表查询，执行计划里可能同时存在三四个这样的节点。五十个连接、work_mem 设八 MB，名义上是四百 MB，实际并发十个复杂查询就能吃掉两三 GB（估算）。反过来把它压到二 MB，内存安全了，代价是排序落盘，报表慢两三倍。正确的做法是按「并发重查询数乘每查询节点数乘 work_mem」反算，而不是拍一个看起来保守的数字。Java 系还要再加一层：堆四 GB 起步时批量导入结果集的停顿能到几百毫秒，堆开到十六 GB 又会让单次完整回收变长，八到十二 GB 通常是较稳的区间（经验区间）。

判断规则可以简化成一句：选对象库，预算优先给内存缓存与数据归档；选关系库，预算优先给共享缓冲与 NVMe，同时压住 work_mem 的并发乘积。两类都不要指望靠加核解决问题——LIMS 的查询形状是大量短查询加少量重查询，核数过了十六之后，边际收益主要落在报告渲染上，不在日常录入上。真正该花钱的地方，一类是缓冲，一类是存文件的盘。

仪器对接：串口、文件落盘与时钟同步

仪器对接决定系统的入口稳定性，这块出问题不会宕机，但会让数据链断在第一步。三条路：串口或 ASTM 协议直连、文件落地目录监听、中间件转发。老仪器多用串口，RS-232 或者 TCP 封装的 ASTM 帧协议，一条连接一个方向，文本帧带校验；新一点的仪器软件支持导出文件到指定目录，LIMS 侧监听目录变化再解析；更规范的厂商提供中间件，由 broker 统一接收再分发给 LIMS 与归档系统。选型时先盘仪器清单，不是先看软件支持哪些协议。

串口这条路现在多半靠串口服务器把 RS-232 转成以太网。要留意三件事：一台仪器占一个串口，八台老仪器就是八口，算口数而不是算机器数；串口转网的缓冲很小，网络一抖就丢帧，丢帧之后仪器不会重发，只能靠人工重采；协议层有确认与重传，超时参数配错会表现为「采了一半就断」。这类故障排查成本很高，因为根因不在服务器上，在仪器旁边那台转了三次协议的盒子。

文件落地监听是最常见的做法，也最容易踩共享目录的坑。仪器工作站是 Windows，共享目录走 SMB；LIMS 服务器在另一台机器上读同一个目录。SMB 的元数据操作是网络往返，一次目录列举在本地是微秒级，跨网就是毫秒级；监听如果用轮询，间隔三十秒意味着结果延迟半分钟，用 inotify 又要处理「文件还在写」的问题——事件先到，文件字节数还在涨，解析出来就是半截。稳妥的做法是事件触发加稳定窗口：发现新文件后等它连续若干秒大小不变再读，读完写一个标记文件避免重复入库。跨网段时优先 NFS 而不是 SMB，状态查询开销小一些，但要注意锁与权限映射。

时钟同步是这一节里最容易被忽略、后果最严重的一条。仪器工作站跑 Windows，默认时间同步周期偏长，不在域里或者域策略没配好的机器，一天漂几秒到几十秒很正常。LIMS 用采集时间构建样本链路的时间轴，如果仪器时钟比服务器慢四十秒，结果入库时间会早于样本登记时间，链路出现时间倒挂；审计看到一条「检测早于收样」的记录，第一反应是数据被改过。这不是理论风险，是每年内审都能查出来的高频问题。对策很具体：所有仪器工作站强制指向内网时钟源，同步周期压到分钟级；LIMS 侧同时保存「仪器采集时间」与「服务器入库时间」两个字段，链路排序用后者，前者只作为原始值保留，这样即便仪器时钟漂了，链路仍然是单调的。

LIMS 的硬件六维：样本吞吐、原始文件与留存年限

CPU。核数的估算式是：常驻并发用户数除以四，加报告渲染并发数乘二，加数据库排序核二到四，再加一到二核给系统。中型实验室三十个并发、下午同时签发五份 COA，算下来八加四加二约等于十四，取十六核。COA 渲染是典型的 CPU 突发：模板渲染、电子签名、PDF 合成串起来，单份零点五到二秒（估算），批量签发一百份就是一两分钟的连续占用，这时候录入界面会明显变慢。这不是故障，是资源竞争，把签发放到队列里跑就能解决，不需要加核。

内存。关系库的下限：共享缓冲按库体积的百分之二十五到四十给，库二百 GB 就该给四十八到八十 GB；再加连接数的 work_mem 乘积、操作系统二到四 GB、应用层四到八 GB。对象库的下限：ZODB 缓存给到 Data.fs 的百分之二十到三十，加 Python 进程本身与 OS 页缓存。经验区间：中型实验室的数据库节点六十四 GB 是舒适起点，一百二十八 GB 能撑到日千样本级别；低于三十二 GB 时，审计表的范围查询会开始频繁触盘，表现为「翻历史记录特别慢」。

SSD。容量按四块算：库体积（含审计与索引）、近九十天仪器文件的热层、备份暂存、百分之三十余量。库三百 GB、热层四百 GB、备份暂存五百 GB，加起来一点二 TB，落到两块一点九二 TB 的 NVMe 做镜像。IOPS 需求主要来自审计的随机写与对象库的随机读，前者是持续的小块写，后者是随机四 K 到十六 K 读，经验区间在几千到两万 IOPS（估算），企业级 NVMe 足够，SATA 盘在审计高峰时会排队。临时目录一定要放本地盘，放在网络盘上时，一条大报表的排序能把整台仪器的入库写入拖住。

带宽。分内外两条。内网是仪器到存储的持续写入，二十到六十 MB/s 打底，备份窗口内的读取能到几百 MB/s，仪器网段建议千兆独享起步，存储节点上万兆。公网是 KB 级的页面请求加 MB 级的 COA 下载，真正受限的是远程访问用户的本地线路而不是服务器；给到五十到一百 Mbps 独享就能覆盖几十人的日常使用。需要单独评估的是跨站点同步——如果集团要求异地实验室的数据汇总到中心库，审计与文件的同步会成倍放大出口压力，这部分要按同步的数据量算，不是按人数算。

电力。单节点三百五十到五百五十瓦（估算，十六核、内存满配、四块盘），存储节点按盘数走，十二盘位满配四百到七百瓦，双机热备再加一台备份机，整组一点五到二点五千瓦。机柜申报建议按三到四千瓦留余量，因为存储是逐年加盘，功率曲线往上走，而机柜的功率档位一旦签下来，后面改起来很麻烦。这一项在小实验室里最常被跳过，最后变成「机器买回来了，机柜装不下」。

机位。这一项和留存年限直接挂钩。十年二十到六十五 TB 的原始文件，靠服务器本地盘位放不下：1U 机箱四个盘位，2U 八到十二个，4U 能到二十四到三十六个。按单盘十六 TB 算，六十五 TB 需要五块盘做单副本、十块做双副本，再留增长空间，2U 十二盘位是底线，4U 或者独立存储节点才是舒适解。机位要按十年后的盘数申请，不是按今天买的四块盘申请；机柜空间是唯一一项事后无法用钱临时补的东西。

实验室系统五类部署形态对比

下面这张表是全篇唯一的横向对比。表里的六行按资源落点分，其实是五类：单机一体化、应用与数据库分离、数据库加独立文件存储、容器化加外部库、私有云整柜托管。双机热备单列成第六行，不是因为它多出了一种落点，而是因为它把前面任意一类做成两份之后，失败模式完全变了——从「慢」变成「切换过去之后数据对不对」，这件事值得单独看一行。

读表的方法：先看适用样本量确认自己落在哪一行，再看主要资源瓶颈判断加钱能不能解决问题，然后看合规与留存风险——这一列是 LIMS 特有的，前几列在任何系统上都成立，只有这一列决定三年后审计能不能过。最后一列是拿来决策的：如果某一行的用处对你没有意义，说明你还没到那个规模，不必为它付钱。表里的样本量与配置都是经验区间与估算，不是任何厂商公布的最低要求。

有一件事表里装不下：文件存储的选择会反过来改变数据库的负载形态。把原始文件从数据库所在机器挪走之后，数据库的 IO 压力会降一个量级，但同时多了一条「文件引用是否存在」的校验路径，样本详情页每打开一次就要去存储侧确认一次对象是否存在。这条路径如果没做缓存，页面响应会被存储的元数据延迟拖住。所以第三行那种形态，配套要做的是引用缓存加异步校验，而不是简单地「把文件搬走」就完事。

留存十年：冷热分层与可还原性怎么设计

容量必须按十年后算，这一条在别的系统里可以商量，在 LIMS 里不行。制药的 GLP/GMP 场景常按产品生命周期要求保存十年以上，临床、食品与环境检测按各自行业规范往往更长。这意味着今天买的存储要能装下十年后的数据，或者能在十年内平滑扩三次而不停机。按「今年够用」买，第三年就要做一次迁移，而迁移期间审计链的连续性是要写进变更记录、并且会被审计追问的。

冷热分层是唯一现实的解法。热层放最近九十天的原始文件与全部业务库，必须是 NVMe，因为这层被随机访问的概率最高，检验员查昨天的谱图、复核当周的批次都在这层；温层放一到三年的文件，大容量 SATA 或带缓存的 NAS，顺序读为主，几百毫秒的延迟可以接受；冷层放三年以上的，对象存储、磁带库或者离线盘柜，检索一次要几分钟到几小时，但单位容量成本最低。经验比例：热层占总量百分之五到十，温层百分之二十到三十，剩下都在冷层（估算）。按三十 TB 总量算，热层两 TB 的 NVMe、温层八 TB 的机械盘、冷层二十 TB 的对象存储，这个结构比一块三十 TB 的大盘合理得多，也便宜得多。

备份的目标不是「有备份」，是「能还原到某一天某个样本的完整链路」。这句话在 LIMS 上意味着三样东西必须同时对得上：业务库、审计表、原始文件。只还原数据库，文件引用全是断链；只还原文件，没有审计记录证明这些文件属于哪次检测；两者都还原了但时间点差一天，链路就有一天的缺口。做法是把三者的备份打上同一个时间标记，还原演练时按标记整体恢复，并且演练必须抽查「某样本从登记到签发」的全链路能不能在还原后的环境里完整走一遍。演练频率建议每季度一次，它比任何监控都更能说明备份是否可用。

数量级上还要算备份窗口。三十 TB 每周做一次全备、每天增量，全备按二百 MB/s 的有效吞吐要跑四十多个小时（估算），根本塞不进一个周末，而且会与白天的仪器写入抢带宽。所以到 TB 级之后必须换成首次全备加永久增量，或者快照加合成全备，把每周的实际写入量压到增量的规模。另一条是防篡改：审计与原始文件的备份要写到不可变介质上，否则一次勒索软件加密就能把主库和备份一起带走，而这类事件的入口通常是某台能上网的仪器工作站。

实验室系统落单前的六个核对项

第一项，十年容量是否落在纸面。要的不是「够用」两个字，而是一张表：业务库第几年到多少 GB、审计第几年到多少 GB、仪器文件第几年到多少 TB、热温冷各占多少、三年后靠加盘还是换机扩容。这张表算不准没关系，但必须存在，因为它决定了机箱盘位、机柜功率和存储上联端口这三样事后难改的东西。

第二项，仪器清单与接口盘点。多少台仪器、几种协议、需要几个串口、哪些只能导出文件、哪些厂商提供中间件、每台每天产生多少数据。把这张清单和第一项的表对一遍，能立刻看出文件体量的估算有没有漏掉质谱或者影像设备——漏掉一台切片扫描仪，容量估算就能差三倍。

第三项，审计的留存年限与查询方式。要问清楚三件事：留几年、谁有权限查、查的时候要多快。三年内随时要查的记录放热层，十年才查一次的可以进冷层，但「能查」不等于「能等」，如果监管现场要求当场调阅，冷层就必须有预热机制，否则现场等待的每一分钟都是压力。

第四项，验证与权限分离。录入与复核不能是同一人，系统时间谁能改，原始文件谁能删，管理员能不能看检测值——这些要在配置层面就有明确开关，而不是靠流程约定。要提醒的是，任何软件的功能清单都不构成合规结论，这类要求最终需通过供应商与使用方共同完成的验证流程来满足，验证的范围、脚本与结论由使用方确认。

第五项，故障域与扩容路径。数据库与文件是不是同一台机器、同一块盘、同一个机柜，加盘要不要停机，切换之后审计序列号能否延续。这些问题的答案决定了第七节那六维里哪一维要先花钱。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；实际可选机型、存储盘位与带宽档位随时段变化，落单前建议按官网实时信息核对。对实验室来说，这句话里最该核对的是盘位与功率两项，因为它们决定三年后能不能原地扩，而不是决定今天跑得多快。

第六项，备份可还原性演练的排期。写进运维日历，每季度一次，覆盖数据库、审计、文件三者的时间对齐，抽查一条样本的全链路。没有排期的演练等于没有演练，而这一项恰恰是六个核对项里唯一无法在采购阶段用参数弥补的。

LIMS 自建的边界：什么实验室不该自己搭

日样本量长期在五十以下、没有专职信息化人员、也没有验证资源的实验室，不适合自建。原因不是技术门槛，是成本结构：自建要一次性买机器、买存储、买备份介质，还要在十年里持续投入运维、打补丁、做升级、写验证文档。这套固定成本摊到每天几十个样本上，单样本成本会高到不合理，而 SaaS 的订阅费在这个量级上是可控的。更关键的是，小实验室通常没有人能在凌晨处理一次数据库崩溃，也没有人能回答审计「你们的审计轨迹怎么保证不可篡改」这个问题。

第二类不该自建的是需要多站点强协同的机构。仪器在工作站上、数据在本地、复核在总部，中间要跨城同步审计与原始文件，这条链路的稳定性、时钟一致性、断线重连后的补传逻辑，复杂度远超单点部署。如果协同是核心需求，选一个已经把这层做好的平台，比自建一套再补协同要省得多。

反过来，有三种情况自建是合理的。数据不能出内网（涉及未公开配方、临床隐私、监管明确要求本地留存）；仪器接口高度定制，市面产品对接不了那几台老设备；样本量大到订阅费超过自建的年化成本，并且已经有现成的机房与运维能力。这三种情况共同的前提是：有人能对这套系统负责十年，而不只是负责上线那三个月。

把判断收敛成一句：先算三个数——十年后的存储总量、每天的真实写入次数、审计要留多少年。前两个数字小、第三个数字短的实验室，买服务比搭系统划算；三个数字里只要有一个大到让「今年够用」失效，就得按本文的顺序重新规划：链路、审计、文件、内存形态、接口与时钟、硬件、形态、分层，一项一项落到纸面。顺序错了，钱一定花在不需要的地方，而真正会出事的那一项，往往一分钱都没花。