一家做影像归档的团队在订机器前算过一笔账：历史素材加起来 800G，按未来两年的增量留出余量，订了一台 1T 数据盘的服务器。上线第一周导入全部素材，第二周磁盘就开始告警。运维上去查，原图目录确实是 800G，问题出在别处——缩略图与预览目录又吃掉了一块，转码后的视频另存了一份且原视频并没有删除，机器学习的人脸与语义索引还在排队跑，模型缓存和数据库的自动备份目录也在默默长大。更要命的还不是容量：素材基本导完之后，前端打开时间线还是慢，滚动到某一天要等好几秒才出图，搜索框输入关键词转圈半天没结果。团队一开始怀疑是磁盘买小了，第二反应是带宽不够，但带宽监控上流量并不高。真正的错位在于，这台机器是按「存 800G 文件」来选的，而它实际承担的是「几百万个小文件的写入、一遍遍重读、再生成一遍派生文件、同时跑计算型索引任务」。容量只是这笔账里最容易算的那一栏。
自建影像库的容量估算里，最常见的一个错误是把「原图总量」当成「磁盘需求总量」。这两者在文件服务器上通常差不了太多，但在一个会自动生成派生文件、会自动抽取元数据、会自动跑机器学习索引的系统里，它们从来不是一回事。原图只是入口，入库之后系统要为每一张照片生成若干尺寸的预览图，为每一个视频生成一份或多份转码副本，为每一个资产抽取元数据并写进数据库，再为人脸和语义检索生成向量并建索引。这些动作没有一个是可选的装饰，它们决定了时间线能不能秒开、搜索能不能用。
于是容量的第一层错位出现了：预算是按「一份数据」做的，落地是「一份原始数据 + 若干份派生数据 + 一份数据库 + 若干份备份」。第二层错位更隐蔽：容量就算算对了，速度也不一定够。因为影像库的性能瓶颈几乎不在「能装多少」，而在首次批量导入那几天的写入与计算峰值，以及之后日常浏览时的随机小文件读取。这两件事分别对应磁盘的 IOPS 与 CPU 的核数，跟容量大小几乎没有关系。
把这个错位讲清楚，选型顺序就会变：先算数据构成，再排导入期的安排，最后才回到盘要多大、机器要几核。
要算容量，得先知道一份素材会变成几份东西。以自建影像库的典型目录结构来看，一个资产至少对应下面几类落盘内容。
这几类的增长曲线并不一致。原图只随新增素材增长；缩略图随资产数量增长，而且每一个新增资产都是「一次性多出好几个小文件」；转码视频随视频素材的数量与目标规格增长；索引随资产数和人脸数增长，并且换模型会导致全量重算。理解这一点很重要：你给未来的自己留余量时，不能只给原图留。
能核实到的官方口径只有一条：Immich 官方的系统要求文档写明，生成缩略图与转码视频平均会让照片库的体积增加 10-20%。这个数字只覆盖派生文件中的一部分，而且是「平均」意义下的区间，官方并未给出按素材类型、分辨率、视频占比拆分的具体系数。
也就是说，除了这一条，其余系数——缩略图占原图的比例、索引与数据库占原图的比例、备份占原图的比例——都必须在你自己的照片量、分辨率结构、视频占比下实测才能确定。不同团队之间差异极大：以 RAW 为主的摄影工作室、以产品图为主的设计素材库、以手机拍摄视频为主的连锁门店素材，三者的派生数据占比完全不在一个量级上。
因此本文不给任何「乘以 1.3 就够」这类结论。给不了的原因是这类系数天生依赖样本，一篇文章里写死的系数只会误导另一个样本的人。正确的做法是：先拿一小批代表性素材跑完整流程，量出派生数据与原图的比值，再把这个比值用到全量估算上。
估算可以拆成四步，每一步都能在你的环境里独立验证。
第一步，采样测比值。取一批能代表整体结构的素材——比例上要覆盖 RAW、JPG、视频、以及你实际会用到的分辨率档位——完整跑一遍导入、缩略图生成、元数据抽取、机器学习索引。跑完后分别统计原始目录、派生目录、数据库目录、备份目录的实际占用，算出「派生 / 原图」「索引与数据库 / 原图」两个比值。这一步花的时间，会在后面省回来。
第二步，按总量外推。用你现有的原图总量乘以实测比值，得到当前时点的总占用。注意视频素材要单独算，因为转码副本意味着它至少是双份。
第三步，叠年增长率。影像库的增长通常来自两个方向：新增拍摄量与分辨率升级。前者可以按过去 12 个月的实际增量推算；后者更麻烦，它意味着同样「一张照片」的体积在变大。建议把这两者分开记，别混成一个笼统的百分比。
第四步，留两类余量。一类是运行余量，用于导入期的临时文件、任务失败重试、以及换模型导致的索引重建；另一类是恢复余量，用于恢复演练时把备份拉回本机、以及重建派生数据时需要的临时空间。文件系统层面的经验是，剩余空间过低会让写入性能与稳定性同时变差，具体阈值需在你的文件系统与监控策略下实测。
把四步算完，你得到的不是「1T 够不够」，而是「当前需要多少、一年后需要多少、导入期峰值需要多少、恢复时需要多少」四个数。这四个数才能拿去选机器。
很多团队的资源规划是按「稳态」做的：平时几个人偶尔上传、偶尔翻一翻，负载很轻。但影像库的负载曲线不是平的，它有一个非常陡的开头。
官方 FAQ 里有一句很直接的描述：初次导入（文档表述为 initial backup）是最密集的阶段，因为同时有大量的任务在跑。这些任务包括库扫描、缩略图生成、元数据抽取、以及机器学习相关的智能搜索与人脸检测。它们不是串行发生的——导入一批素材会同时往这几个队列里塞任务，队列再把任务并发地派给 CPU 和磁盘。
于是导入期会出现四个叠加的压力：
这个窗口的持续时间取决于素材量、CPU 核数、并发设置和磁盘速度，无法用一个通用数字给出，只能实测。但可以确定的是：窗口期内机器不应该同时承担对外服务压力，更不应该被当作「顺便也能跑别的业务」的共享机。
机器学习索引之所以需要单独讨论，是因为它和「上传」这类 IO 型任务的资源画像不一样。智能搜索与人脸检测本质上是计算型任务：模型要在内存里，图片要先解码，推理要占用 CPU 或加速硬件。官方 FAQ 指出，最耗 CPU 的就是转码与机器学习任务（智能搜索、人脸检测），缩略图生成排在其次。
问题在于，这类任务一旦不限流，会和前端服务抢两类资源。抢 CPU 的直接后果是网页响应变慢、上传接口排队；抢 IO 的后果更隐蔽——索引任务要读原图、要写数据库，同时缩略图任务也在读写派生目录，几条队列一起压向同一块盘，随机 IO 的排队深度会被拉满，表现出来的现象就是「整台机器都很慢，但看不出是哪个进程」。
所以索引任务的定位应该是后台批处理，而不是「越快越好」。它的目标是在不影响正常浏览的前提下把队列排完，不是在一个晚上把所有队列冲到底。
关于并发，官方 FAQ 给出了几条很实用的信息，可以直接拿来当削峰的依据：
对应到导入期的操作，一个稳妥的排期是这样的：先在管理界面的任务设置里把这些任务的并发降下来（官方给出的降压手段包括把并发降到 1、把转码线程设为 1 或 2、把人脸识别模型换成更小的模型），先把库扫完、缩略图出完，让时间线能正常浏览；等确认浏览侧没有卡顿之后，再逐步放开机器学习任务的并发，让它在夜间把队列跑完。这样排的好处是，每个阶段只有一个主要瓶颈，出问题容易定位。
如果导入期确实赶时间，另一条路是把机器学习容器拆到更强或独立的机器上跑——官方 FAQ 明确提到可以把机器学习容器放在性能更强的系统上。这意味着索引计算与文件存储可以不在同一台机器上，导入期的 CPU 峰值就不必和磁盘 IO 峰值叠在一起。代价是多一台机器、多一份跨机调用的运维复杂度。
导入期过去之后，机器进入稳态，很多人以为压力结束了。实际上稳态有稳态的瓶颈，而且和容量完全无关。
时间线是怎么工作的？用户滚动页面时，前端按时间分批请求一批资产的预览图；服务端要按数据库里的路径，去磁盘上把对应的那批小文件读出来返回。这个过程的特征是大量、随机、小尺寸的读：一次滚动可能触发几十上百个文件读取，这些文件在物理盘面上彼此不相邻，每个都很小。
随机小文件读的成本，主要取决于单次访问的响应时间与并发处理能力，而不是磁盘能装多少 TB。同一块大容量机械盘，顺序读写可以很漂亮，但随机小文件读的 IOPS 会成为短板；这也正是官方 FAQ 强调「存储速度与延迟会很快成为限制因素，尤其在使用 HDD 时」的原因。对影像库而言，预览图所在的目录放在什么介质上，比整个库放在多大的盘上更影响体验。
另外还有一个容易忽略的点：官方 FAQ 提到，大量资产上传完成后 CPU 占用会回落（文档中的描述是降到 3-5% 左右）。这说明稳态的 CPU 压力其实不大，真正的压力在存储侧。如果你的机器在稳态仍然 CPU 很高，那多半是队列没跑完或者模型反复加载卸载——官方提供了模型空闲卸载时间的配置项（默认 300 秒），模型被卸载后再次请求就会重新加载，频繁切换任务会造成额外的加载开销。
影像库不是「一堆文件加一个目录索引」，它重度依赖数据库。时间线的聚合、按日期与城市的筛选、按相机型号的检索、以及语义搜索与人脸搜索，全都是数据库查询。
数据库在这里承担两类不同的工作。第一类是结构化元数据检索：拍摄时间、位置、相机、文件类型、是否归档、属于哪个相册。这类是常规的关系型查询，靠 B 树索引和足够的缓存就能跑得不错。第二类是向量相似检索：语义搜索把图片和文字映射到同一个向量空间，用户输一句话就能找到内容相近的照片；人脸识别则把人脸映射成向量再做聚类与比对。Immich 用 Postgres 承担搜索数据库，智能搜索依赖向量扩展来提供相似度检索能力（不同版本的文档分别提到 pgvecto.rs 与 VectorChord，且以 pgvector 作为基础依赖），用户可以按需要选择不同的 CLIP 模型——官方说明是，更强的模型结果更准，但更慢、也更吃资源。
为什么它对内存敏感？向量检索的通用工程特征是：向量数据量本身不小，而建立在向量之上的近似索引（常见如 HNSW、IVFFlat 两类）要发挥性能，通常希望索引能尽可能常驻在内存里；pgvector 生态的资料也普遍指出，HNSW 查询更快、召回更高，代价是构建更慢、占用内存更多，IVFFlat 则相反，且索引构建过程会用到专门的构建内存参数。索引一旦装不进内存，就要在查询时反复换入换出，表现就是「搜索偶发性地特别慢」。
Immich 官方给出的相关口径有两条可以直接用：一是 Postgres 数据库文件通常在 1-3 GB 量级，因此推荐把数据库放在本地 SSD 上，官方文档明确说绝不要放在任何形式的网络共享上；二是如果用了容器资源限制，数据库至少需要 2GB 内存。这两条合起来说明：数据库这块对介质和内存都有硬性偏好，不该为了省成本把它挪到慢速共享存储上。同时官方文档也提示，机器学习容器在 amd64 平台上需要 x86-64-v2 微架构级别的支持，选型时如果是较老的机型或虚拟化环境，需要确认微架构是否被支持。
云平台一般都会提供磁盘快照，功能上很好用，于是很多人把快照当成备份。这两者的差别很关键。
快照记录的是某一时刻的磁盘状态，它通常和原盘在同一个存储系统、同一个机房、同一个故障域里。它能很好地解决「手抖改错配置」「升级失败要回滚」这类问题。但它解决不了三类问题：一是误删同步——如果有人删除了资产并且系统随后把该资产从回收站彻底清除，快照在下次拍摄时会忠实记录「删除之后」的状态，你并没有多一份数据；二是逻辑损坏——数据库因为异常写入或者不完整的备份而损坏，损坏状态同样会被快照记录下来；三是机房级故障——快照与源盘同处一地时，它扛不住这一层。
影像库偏偏是这三类风险都容易发生的场景。资产删除是高频操作，数据库是核心依赖，素材本身又是不可再生数据。所以备份必须是独立于快照之外的第二份副本，并且落在不同位置。
官方的备份文档也给出了一个明确的建议：采用 3-2-1 备份思路，同时保留上传的照片视频与数据库。文档还特别强调了一个容易被忽略的事实——系统把文件路径保存在数据库里，并不会通过扫描库目录来更新数据库，因此数据库的备份是必需的，而不是「文件还在就能恢复」。
备份的对象要分清主次。官方备份文档把文件系统里的内容分成两类：原始未修改的资产，与生成出来的内容。文档推荐备份整个上传目录，但同时说明只有原始内容是关键的；如果只备份原始部分，那么恢复之后需要重新跑一遍转码与缩略图生成任务才能恢复完整体验。这个取舍很实用：派生数据可以重算，代价是时间和 CPU。
数据库这一侧要注意一个明确的禁令：官方不建议直接拷贝数据库数据目录来做备份，因为在数据库运行期间拷贝可能得到一个无法恢复的损坏备份。正确做法是用数据库转储工具导出（官方示例用的是 pg_dumpall 并压缩）。Immich 默认也会自动创建数据库备份并存放在上传目录下的 backups 子目录，默认保留最近 14 份、每天凌晨生成一次——但这些自动备份仍然在本机，官方文档的措辞是「你仍然需要自己用真正的备份工具把它们备份出去」。
演练部分同样不能省。建议做的验证至少包括：从异地副本恢复一个抽样目录并校验文件完整性与数量；在一个隔离环境里用导出的数据库转储恢复一遍，确认资产能被正确关联到文件；记录一次完整恢复实际耗时，作为容灾预期的一部分。恢复耗时这个数字必须在你的数据量与线路条件下实测，任何文章里给出的时间都不能直接套用。
下表把各类数据按「由什么产生、随什么增长、能否重建、怎么备份」列在一起，供做备份策略时逐项对照。表中凡是涉及具体比例的单元格，除有官方来源的一栏外，一律标为需实测。
| 数据类别 | 由什么产生 | 体量随什么增长 | 能否重建 | 备份优先级与做法 |
|---|---|---|---|---|
| 原始照片与视频 | 网页端、移动端、命令行上传；外部库导入的既有文件 | 随新增素材量与拍摄分辨率增长；视频类还需叠加转码副本 | 不可重建，丢失即永久损失 | 最高优先级。本机一份 + 异地副本一份，定期做数量与完整性校验，抽查恢复 |
| 缩略图与预览图（含人脸缩略图） | 缩略图生成任务，对每个资产生成多个尺寸 | 随资产数量增长；官方文档称缩略图与转码视频平均使库体积增加 10-20%，具体占比需实测 | 可重建，重跑生成任务即可 | 低优先级。恢复后重跑任务；代价是导入期式的 CPU 与 IO 峰值再次出现 |
| 转码视频 | 为兼容性重新编码产生，官方说明原视频不会被删除 | 随视频数量与目标编码规格增长，实际倍率需实测 | 可重建，重跑转码任务 | 低优先级。与缩略图同理，恢复时统一重跑 |
| 元数据与拍摄信息 | 元数据抽取任务，写入数据库 | 随资产数增长，单条体量小但条目基数大 | 部分可从原文件重新抽取，库内编辑过的描述与相册归属不可重建 | 随数据库一并备份，优先级高 |
| 机器学习索引（人脸向量与语义向量） | 人脸检测与智能搜索任务；换模型会导致全量重算 | 随资产数、人脸数与所选模型的向量维度增长，占比需实测 | 可重建，重跑任务即可 | 低优先级。不备份可省空间，代价是重建期的算力与耗时 |
| 数据库（含文件路径、设置与向量索引） | Postgres 实例持续写入；官方称数据库文件通常 1-3 GB | 随资产数增长；换模型或重建索引时会出现临时增长 | 不可重建，路径与关联关系只存在于库中 | 最高优先级。用数据库转储方式导出并异地保存；官方不建议直接拷贝运行中的数据目录 |
| 数据库自动备份与模型缓存 | 系统自动生成的数据库备份（存于上传目录下）；机器学习模型下载缓存 | 随备份保留份数、已下载模型数量增长；具体占用需实测 | 可重建；模型缓存重新下载即可 | 中优先级。自动备份仍需另行备份到异地；不用的模型建议清理以释放空间 |
同一台机器上，存储可以摆成几种形态，代价各不相同。
摆法一：单盘统一放。系统、上传目录、数据库都在一块盘上。优点是结构简单、容量不浪费、运维最省心；缺点是导入期的写入峰值、日常浏览的随机读、以及数据库的写入全部争抢同一块盘的 IO，且一旦盘出问题，恢复面最大。适合素材量不大、并发浏览少的团队。
摆法二：系统与数据库一块 SSD，原始数据与派生数据一块大容量盘。这是更常见也更合理的分法。官方文档对数据库的介质要求是明确偏向本地 SSD 的，把数据库单独放在快速的本地盘上，能直接改善时间线聚合与搜索的响应；原始与派生数据放大容量盘，承担吞吐与容量。代价是两块盘的容量要分别规划，扩容时也要分别考虑。
摆法三：数据库与热数据在本机 SSD，冷数据走外部库挂载。官方文档允许把图片与视频资产放在网络共享上，但明确不建议把数据库放在网络共享上；外部库的自动文件监听功能在网络驱动器上大概率无法工作，需要依靠周期性重新扫描来发现变更。这条约束意味着：走外部库可以省掉一次大迁移、可以让既有的归档目录原地纳入管理，但代价是变更发现不再实时、且 IO 路径上多了一跳。是否需要这一跳，要用实际的浏览延迟实测来判断。
备份盘则是另一个维度的问题：它可以是本机第二块盘（用于快速回滚与临时落地），但不能替代异地副本。本机第二块盘解决的是「单盘故障」，异地副本解决的是「整机或机房级故障」。两者都要有，才算完整的容灾。
外部库是很多团队会用到的机制：素材已经在一个目录里了，不想再搬一遍，就把目录挂进容器、建立库、设置导入路径、触发扫描。官方文档说明，扫描会产生库扫描、缩略图生成、元数据抽取这几类任务，扫完之后这些素材在时间线里和其它资产表现一致。
这个机制换来的是「不用迁移」，但有几点代价必须提前知道：
换句话说，外部库适合「存量素材先纳入管理、后续增量再走上传」的过渡形态；如果希望元数据长期稳定地跟着文件走，那么把素材正式导入、由系统管理存储位置会更稳妥。
把前面的负载特征翻译回硬件参数，可以得到一份相对清晰的决策顺序。
CPU：官方系统要求给的下限是 2 核、推荐 4 核。但这个下限对应的是「能跑起来」，不是「导入期能按时跑完」。由于官方 FAQ 提到普通机器上 2-3 个并发任务就能吃满 CPU，核数实际上决定了导入期能把并发开到多少、索引队列多久排完。核数怎么选，取决于你对导入期长度的容忍度，而这个对应关系需实测。另外要注意官方的架构要求：amd64 平台上机器学习容器需要 x86-64-v2 微架构级别支持，虚拟机环境需要确认选型。
内存：官方要求最低 6GB、推荐 8GB，并说明只有 4GB 内存的系统可以在关闭机器学习功能的前提下运行；如果使用了容器资源限制，数据库部分至少需要 2GB。选型时还应该把向量索引的内存偏好考虑进去——如果语义检索是核心功能，内存就要留出余量，让索引尽量留在内存里。建议以官方推荐值起步，再根据索引规模与并发浏览人数上调，具体数值需实测。
系统盘：容量需求本身不大，但建议用 SSD，且不要把数据库放在慢速介质上。系统盘还承担容器镜像、日志与临时文件，导入期日志量会明显上升，留出余量。
数据盘：容量按前面四步估出来的结果定，并且一定要问清是否支持在线扩容——影像库的容量预测误差往往比想象中大，扩容能力比初始容量更重要。另一个参数是 IOPS：时间线浏览是随机小文件读，导入期是混合读写，两者都对 IOPS 有要求。选盘时不要只看 TB 数，要看介质类型与 IOPS 能力，具体需要多少 IOPS 需在你的资产数与并发浏览人数下实测。
文件系统：官方推荐使用支持用户与组权限的 Unix 兼容文件系统，例如 EXT4、XFS、ZFS 等。对于海量小文件场景，文件系统的 inode 规划与小文件性能同样值得提前确认，避免素材量上来之后才发现元数据层面的限制。
这里说的不是对外服务的出网带宽，而是素材进入系统的上行通道与时间安排——它决定的是导入期有多长，以及导入期会不会和索引任务撞在一起。
影像库的素材来源通常有两类。一类是一次性历史迁移：体量大、只做一次，可以通过物理方式或一次性长时间传输完成，重点是别让它在白天和正常浏览抢资源。另一类是持续增量上传：多个拍摄点每天回传，重点是稳定和可预期。
对于有多个拍摄点的团队，增量上传的时间窗口要单独规划。如果各地的回传集中在傍晚，而索引任务也安排在夜间跑，那么这两件事会在同一时段叠加——上行通道被占用、CPU 被索引占满、磁盘同时在写新素材和读旧素材。更合理的排法是错峰：让回传在固定时段完成，索引任务的并发按回传结束后的窗口调整，两者不要挤在一起。具体怎么错峰，取决于你的回传量、上行带宽与队列长度，同样需要实测后确定。
顺带一提，移动端上传的文件会先落在上传队列目录，成功后再转入正式存储位置。导入期要留意这个临时目录的占用与清理，避免出现素材传完了但空间没释放的情况。
落到机房与节点选择，影像库真正关心的不是「哪里的机器便宜」，而是下面这几项能力是否明确、是否能在需要时兑现。
这几项里，扩容与异地备份是硬需求，IOPS 是体验分水岭，节点位置是与业务分布相关的条件项。把它们问清楚，比单纯比较配置单价更有意义。
影像库的长期成本大致由五块构成，其中只有前两块会出现在报价单上。
以上各项的价格都属于需要按实际配置与地域确认的项目，一律需询价，或以官网实时报价为准。本文不给出任何价格数字，也不做任何价格区间的推断。
问：我们只有几百 G 素材，也需要按这套方法算吗？
需要，但可以把重点后移。素材量小的时候容量容错高，反而是导入期的体验更影响判断：先确认缩略图出完之前时间线是否有明显卡顿，再决定要不要把机器学习任务拆出去或降低并发。容量估算的四步可以简化成「采样测比值 + 留余量」两步。
问：可以把素材放在网络存储上吗？
官方文档允许图片与视频资产放在网络共享上，但明确不建议把数据库放在网络共享上；同时外部库的自动文件监听在网络驱动器上大概率不可用，需要靠周期性扫描发现变更。是否采用这种摆法，要用实际的浏览延迟与扫描耗时实测后决定。
问：换更强的 CLIP 模型值不值？
官方的说明是更强的模型结果更准，但速度更慢、对服务器资源要求更高，且换模型需要对全部资产重新处理一次。因此这是一个「用一次全量重算的算力换长期检索质量」的取舍，建议在素材量已经稳定之后再决定，避免反复换。
问：索引任务能不能直接关掉？
可以。官方文档说明机器学习是可选功能，资源紧张时可以关闭，也可以把机器学习容器放到更强的机器上。关掉之后语义搜索与人脸识别不可用，但时间线与元数据检索仍然可用。对于只要归档、不做智能检索的团队，这是最直接的降压手段。
问：能不能用 GPU 加速？
官方提供了多种硬件加速相关的配置项与设备选择参数，且 FAQ 提到有 GPU 时可以更舒适地提高并发（但建议多数情况下不超过 16）。是否值得引入加速硬件，取决于你的素材量、索引重建频率与导入期时间要求，需要实测评估；本文不对加速收益做任何量化承诺。
问：数据盘不够了怎么办？
两条路：一是扩容，所以选型时必须确认在线扩容能力；二是清理，派生数据与模型缓存是可以重建的，不需要永久保留。真正的底线是原始素材与数据库，这两块不能靠清理来解决。
一、容量按构成算，不按总量算。原图、派生数据、数据库、备份要分四栏记。代价是估算工作量变大，换来的是不会再出现「算对了还是告警」。
二、官方给的 10-20% 是派生数据的一部分，不是全部。它能用来做 sanity check，不能用来当最终系数。代价是你必须先跑一次采样，才能得出自己的比值。
三、导入期单独排期，不与日常服务重叠。把并发调低、任务分批、峰值错峰，代价是索引跑完的时间变长，换来的是导入期间系统还能正常用。
四、数据库放本地 SSD，并且单独备份。代价是系统盘或 SSD 容量要另外规划，换来的是时间线与搜索的响应，以及唯一无法重建的关联关系有兜底。
五、快照用于回滚，异地副本用于容灾，两者都要。代价是多一份存储成本与一次演练工作量，换来的是误删、逻辑损坏、机房级故障三类场景都有解。
六、扩容能力比初始容量重要。代价是选型时要多问几个问题、可能要接受特定配置，换来的是容量预测失准时不用推倒重来。
本文只讨论自建影像库的存储构成、导入期负载特征、索引资源占用与选型思路，不比较任何具体产品或服务商的优劣，不给出任何未经核实的容量系数、并发数或性能承诺，不指向任何具体客户，也不构成性能或可用性承诺。文中提到的场景均为通用示例，不对应任何真实项目。所有容量、占比、耗时、并发取值均需在自有影像量与硬件条件下实测确定。
文中引用的事实性说法来自 Immich 官方文档的系统要求页、常见问题页、备份与恢复页、外部库页与环境变量页，以及 pgvector 与 PostgreSQL 向量检索相关的公开技术资料；涉及版本差异的部分（例如向量扩展的选择、平台微架构要求）以你实际部署的版本官方文档为准。本文不讨论机器学习模型的原理细节，也不涉及加速硬件的选型比较。
一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。
一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体的机型、机柜、带宽与报价，仍要以官方实时信息或咨询确认为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
