文章目录每日一句正能量1. 背景与问题2. 环境与数据2.1 关系与文档表2.2 向量表2.3 时序表3. 复现过程3.1 统计当前数据规模3.2 复现向量维度变化的容量影响3.3 复现时序数据保留过长问题4. 方案实施4.1 建立容量估算公式4.2 以业务指标驱动估算4.3 关系表的分区和索引4.4 文档存储策略4.5 时序数据分层保留4.6 向量容量与索引规划4.7 压测模型4.8 容量监控 SQL4.9 容量告警阈值5. 结果对比6. 风险与复盘6.1 常见风险6.2 上线检查清单6.3 复盘结论每日一句正能量生命的境界山海在心从容于行“心有山海静而无边。”内心拥有山海般的壮阔与深度因而能获得无边无际的宁静。1. 背景与问题快速增长业务在早期最容易出现一种错觉数据库当前还能运行所以容量暂时没有问题。这种判断只适用于数据量和访问量都比较稳定的系统。对于同时包含关系、文档、时序和向量数据的平台容量增长通常不是线性的也不是只增加几张表那么简单。以企业知识库和智能问答平台为例一篇文档可能经历如下处理原始文件 - 文档正文 - 文档分段 - 多个知识块 - 每个知识块一个向量 - 向量索引 - 查询日志和访问审计如果一篇文档平均切分为 12 个知识块那么新增 10 万篇文档可能产生 120 万条向量记录。与此同时向量索引、WAL、备份文件和查询日志还会产生额外空间。平台中不同数据的增长特点不同数据类型主要增长来源典型增长特点关系数据客户、权限、任务、订单行数稳定增长索引较多文档数据PDF、HTML、工单、附件单行大小差异大时序数据指标、日志、访问事件高频写入按时间增长向量数据文档块、会话摘要与分块数量和模型维度相关索引数据B-tree、GIN、HNSW通常大于表本身的预期WAL 与备份写入、归档、快照受更新峰值和保留周期影响容量规划需要回答未来 6 个月需要多少磁盘 向量维度从 768 升到 1536 后增加多少 时序数据保留 30 天还是 180 天 索引重建是否需要额外临时空间 高峰导入和在线查询是否争抢 CPU、IO 和内存 备份保留策略是否会耗尽对象存储本文建立一个可执行的估算模型并结合压测验证误差。2. 环境与数据测试环境组件用途PostgreSQL 15关系、文档元数据和向量表pgvector向量存储与 HNSW 索引TimescaleDB指标、日志和访问事件JSONB标签、扩展属性和动态字段对象存储原始文档、附件和备份压测工具模拟写入、检索和混合负载监控系统CPU、内存、IO、WAL 和延迟2.1 关系与文档表CREATETABLEknowledge_document(document_id UUIDPRIMARYKEY,tenant_idTEXTNOTNULL,titleTEXTNOTNULL,contentTEXTNOTNULL,content_hashTEXTNOTNULL,version_noINTNOTNULLDEFAULT1,statusTEXTNOTNULLDEFAULTpublished,metadata JSONBNOTNULLDEFAULT{}::jsonb,created_at TIMESTAMPTZNOTNULLDEFAULTnow(),updated_at TIMESTAMPTZNOTNULLDEFAULTnow());CREATEINDEXidx_document_tenant_statusONknowledge_document(tenant_id,status,updated_atDESC);CREATEINDEXidx_document_metadataONknowledge_documentUSINGGIN(metadata);2.2 向量表CREATEEXTENSIONIFNOTEXISTSvector;CREATETABLEknowledge_chunk(chunk_id UUIDPRIMARYKEY,document_id UUIDNOTNULLREFERENCESknowledge_document(document_id),tenant_idTEXTNOTNULL,version_noINTNOTNULL,chunk_noINTNOTNULL,contentTEXTNOTNULL,embedding_modelTEXTNOTNULL,embedding_dimensionINTNOTNULL,embedding VECTOR(768)NOTNULL,metadata JSONBNOTNULLDEFAULT{}::jsonb,statusTEXTNOTNULLDEFAULTactive,UNIQUE(document_id,version_no,chunk_no));CREATEINDEXidx_chunk_embedding_hnswONknowledge_chunkUSINGhnsw(embedding vector_cosine_ops);CREATEINDEXidx_chunk_tenant_statusONknowledge_chunk(tenant_id,status,document_id);2.3 时序表CREATETABLEplatform_metric(ts TIMESTAMPTZNOTNULL,tenant_idTEXTNOTNULL,metric_nameTEXTNOTNULL,entity_idTEXTNOTNULL,valueDOUBLEPRECISIONNOTNULL,labels JSONBNOTNULLDEFAULT{}::jsonb);SELECTcreate_hypertable(platform_metric,by_range(ts),if_not_existsTRUE);3. 复现过程3.1 统计当前数据规模SELECTdocumentASdata_type,count(*)ASrow_count,pg_total_relation_size(knowledge_document)AStotal_bytesFROMknowledge_documentUNIONALLSELECTchunk,count(*),pg_total_relation_size(knowledge_chunk)FROMknowledge_chunk;统计向量索引SELECTindexrelname,pg_size_pretty(pg_relation_size(indexrelid))ASindex_sizeFROMpg_stat_user_indexesWHERErelnameknowledge_chunk;统计时序数据SELECTmetric_name,count(*)ASrow_count,min(ts)ASmin_ts,max(ts)ASmax_tsFROMplatform_metricGROUPBYmetric_nameORDERBYrow_countDESC;3.2 复现向量维度变化的容量影响768 维单精度向量的理论数据部分约为768 × 4 字节 3072 字节1536 维时1536 × 4 字节 6144 字节实际占用还包括行头 可变字段 TOAST 索引项 HNSW 图结构 WAL 备份副本因此向量维度翻倍后最终存储不一定只增加两倍索引和写放大可能让实际增幅更高。3.3 复现时序数据保留过长问题假设系统每秒写入 5000 条指标每日行数 5000 × 86400 432,000,000 行如果每行平均占用 120 字节仅数据部分就是432,000,000 × 120 ≈ 51.8 GB / 天加上索引、WAL、压缩前副本和备份后实际容量可能达到数据部分的 1.5 到 3 倍。因此时序表不能只按“每天多少行”规划还要计算保留周期 压缩比例 索引数量 写入峰值 备份保留 查询窗口4. 方案实施4.1 建立容量估算公式总容量可以拆分为总容量 关系表容量 文档容量 向量表容量 向量索引容量 时序热数据容量 时序归档容量 WAL 保留空间 备份空间 临时维护空间 安全余量关系数据估算relation_size row_count × avg_row_bytes btree_index_size gin_index_size向量数据估算vector_data_size vector_count × (dimension × 4 row_overhead)向量索引估算不能完全依赖理论公式应使用小规模样本测量比例vector_index_size vector_data_size × observed_index_ratio时序数据估算daily_ts_size events_per_second × 86400 × avg_row_bytes × index_factor最终容量planned_capacity current_size monthly_growth × planning_months backup_retention_size maintenance_headroom建议保留至少 25% 至 35% 的安全余量重建 HNSW 或大规模排序时则需要更多临时空间。4.2 以业务指标驱动估算不应只用“数据库总行数”规划。应从业务变量出发每日新增文档数 平均文档字数 平均切块数 Embedding 维度 每日用户查询数 每次查询候选数 每秒指标写入量 时序保留天数 文档版本保留数量 向量模型并存数量示例每日新增文档20,000 平均每篇切块8 每日新增向量160,000 向量维度768 时序写入3,000 行/秒 时序保留90 天 模型并存2 个版本年度向量数量160,000 × 365 58,400,000 条如果模型升级后新旧版本并存一段时间峰值向量量可能接近58,400,000 × 2 116,800,000 条模型升级和灰度阶段必须单独规划容量不能只看稳定运行时的单模型规模。4.3 关系表的分区和索引大表可以按租户、业务域或时间进行分区。文档和向量表通常更适合按租户或业务域拆分时序表适合按时间分区。关系索引示例CREATEINDEXidx_document_domain_statusONknowledge_document(tenant_id,status,updated_atDESC);CREATEINDEXidx_chunk_active_tenantONknowledge_chunk(tenant_id,document_id,version_no)WHEREstatusactive;不要为所有字段建立索引。每个索引都会增加存储空间 写入成本 WAL VACUUM 成本 备份体积4.4 文档存储策略文档正文和原始附件可以分层数据库 标题、正文摘要、content_hash、权限、版本、状态和检索字段。 对象存储 原始 PDF、图片、Office 文件、压缩包和大附件。 向量表 文档块正文、Embedding、模型版本和块级元数据。对于超长文档数据库中可以保存搜索所需的规范化文本原始文件放入对象存储。这样既能保证检索又能减少数据库膨胀。4.5 时序数据分层保留推荐把时序数据分为热数据最近 7 至 30 天在线查询 温数据最近 90 至 180 天压缩保存 冷数据更早数据归档到对象存储或低成本数据库。压缩统计SELECTtime_bucket(1 day,ts)ASday,metric_name,count(*)ASrows,avg(value)ASavg_value,max(value)ASmax_valueFROMplatform_metricWHEREtsnow()-interval30 daysGROUPBYday,metric_nameORDERBYday,metric_name;归档前需要确认业务是否仍需要原始粒度。故障复盘常常需要秒级数据不能因为容量压力直接全部聚合成小时级。4.6 向量容量与索引规划向量容量估算单条向量理论大小 维度 × 4 字节例如 768 维768 × 4 3072 字节1000 万条向量理论数据量10,000,000 × 3072 ≈ 30.72 GB实际还要加上行开销 文档块正文 JSONB 元数据 HNSW 索引 WAL 备份 旧模型并存如果向量表同时保存较长的content实际容量可能远高于理论向量大小。因此可以考虑向量表只保存必要的块文本和元数据 完整正文放在文档表或对象存储 查询阶段通过 document_id 回表 模型升级期间使用独立向量表。4.7 压测模型压测要同时模拟写入和查询写入负载 - 每秒新增文档 - 每秒新增向量 - 文档更新比例 - 删除比例 查询负载 - 关键词查询 - 向量 Top-K - 带 JSONB 过滤 - 关系与向量联合查询 - 时序窗口查询 维护负载 - VACUUM - 索引构建 - 备份 - WAL 归档真实联合查询WITHeligible_docsAS(SELECTd.document_id,d.title,d.metadataFROMknowledge_document dWHEREd.tenant_idtenant_aANDd.statuspublishedANDd.metadata {domain:database}),vector_candidatesAS(SELECTc.document_id,c.chunk_id,1-(c.embedding$1::vector)ASsemantic_scoreFROMknowledge_chunk cJOINeligible_docs dONd.document_idc.document_idWHEREc.tenant_idtenant_aANDc.statusactiveORDERBYc.embedding$1::vectorLIMIT100)SELECTv.chunk_id,v.document_id,d.title,d.metadata,v.semantic_scoreFROMvector_candidates vJOINeligible_docs dONd.document_idv.document_idORDERBYv.semantic_scoreDESCLIMIT10;关联时间序列指标SELECTts,metric_name,valueFROMplatform_metricWHEREtenant_idtenant_aANDentity_id$1ANDtsnow()-interval15 minutesORDERBYts,metric_name;4.8 容量监控 SQL数据库和索引空间SELECTrelname,pg_size_pretty(pg_total_relation_size(relid))AStotal_size,pg_size_pretty(pg_relation_size(relid))AStable_size,pg_size_pretty(pg_indexes_size(relid))ASindex_sizeFROMpg_catalog.pg_statio_user_tablesORDERBYpg_total_relation_size(relid)DESC;表增长趋势CREATETABLEcapacity_metric(ts TIMESTAMPTZNOTNULL,asset_nameTEXTNOTNULL,metric_nameTEXTNOTNULL,metric_valueDOUBLEPRECISIONNOTNULL,labels JSONBNOTNULLDEFAULT{}::jsonb);SELECTcreate_hypertable(capacity_metric,by_range(ts),if_not_existsTRUE);查询近 30 天容量趋势SELECTtime_bucket(1 day,ts)ASday,asset_name,metric_name,max(metric_value)ASmax_valueFROMcapacity_metricWHEREtsnow()-interval30 daysGROUPBYday,asset_name,metric_nameORDERBYday,asset_name;4.9 容量告警阈值建议设置分层阈值指标观察告警紧急数据库磁盘使用率65%75%85%WAL 保留空间10 GB30 GB60 GB向量索引增长率基线 10%基线 25%基线 50%时序写入延迟100 ms300 ms800 ms向量查询 P95150 ms300 ms600 ms备份窗口目标 10%目标 25%超过恢复窗口阈值不能脱离磁盘总容量和业务增长速度。75% 使用率在小磁盘上可能很危险在大磁盘上则可能仍有充足时间扩容。5. 结果对比以下为示例压测结果模拟每日新增 2 万篇文档、平均每篇 8 个知识块、每秒 3000 条时序写入。方案6 个月预计容量向量查询 P95备份窗口扩容复杂度所有正文和附件放数据库14.8 TB210 ms8 小时高正文入库、附件对象存储9.6 TB175 ms5 小时中文档分层 时序压缩 向量分表6.4 TB128 ms3.2 小时中分层 旧模型清理 冷数据归档4.9 TB135 ms2.4 小时可控示例只用于说明估算方式不能作为具体资源采购依据。压测需要比较以下场景1. 只有关系查询。 2. 只有向量 Top-K 查询。 3. 关系过滤 向量排序。 4. 关系过滤 JSONB 标签 向量排序。 5. 向量查询后关联时序窗口。 6. 导入、备份和在线查询同时运行。真实查询执行计划EXPLAIN(ANALYZE,BUFFERS)SELECTc.chunk_id,d.title,1-(c.embedding$1::vector)ASsimilarityFROMknowledge_chunk cJOINknowledge_document dONd.document_idc.document_idWHEREc.tenant_idtenant_aANDc.statusactiveANDd.statuspublishedANDd.metadata {domain:database}ORDERBYc.embedding$1::vectorLIMIT20;结果评估不应只看平均延迟还应观察P50、P95、P99 导入期间延迟 索引构建期间延迟 磁盘增长 WAL 峰值 备份窗口 恢复耗时 Top-K 结果稳定性。容量规划建议至少预留25% 至 35% 常规安全余量 一次索引重建所需临时空间 一次全量备份所需空间 模型升级期间新旧向量并存空间 故障恢复和临时导入空间。6. 风险与复盘6.1 常见风险风险表现应对只按当前数据量规划数月后空间耗尽使用增长模型和峰值模型忽略向量索引表空间够但索引空间不足单独统计向量索引忽略模型并存模型升级时磁盘翻倍提前计算双版本容量时序无限保留写入稳定但空间持续增长热温冷分层和压缩备份占用未计算备份仓库先耗尽规划保留周期和副本数只压测查询导入和备份影响线上采用混合负载压测JSONB 过度使用过滤性能不稳定核心字段结构化估算不含临时空间索引重建失败预留维护余量只看平均值长尾请求超时重点监控 P95/P996.2 上线检查清单[ ] 已拆分关系、文档、时序、向量、索引和备份容量 [ ] 已记录每日新增文档、文档块和向量数量 [ ] 已计算向量维度、模型并存和索引增长 [ ] 已计算时序写入速率、保留周期和压缩比例 [ ] 已计算 WAL、备份、副本和恢复临时空间 [ ] 已完成关系、向量、时序混合负载压测 [ ] 已观察导入、备份、索引构建期间的在线延迟 [ ] 已设置磁盘、WAL、P95 和增长率告警 [ ] 已定义热温冷数据分层和归档策略 [ ] 已定义扩容、降级、清理和回滚流程 [ ] 已验证真实联合查询和权限过滤 [ ] RTO、RPO 和未来六个月资源预算已确认6.3 复盘结论多模场景下的容量规划不能只把数据库容量理解成“数据行数乘以平均行大小”。真正的容量模型应包括业务数据 文档正文 向量字段 向量索引 关系索引 JSONB 索引 时序热数据 时序归档 WAL 备份副本 索引重建临时空间 模型升级并存空间 安全余量。关系、文档、时序和向量数据的规划重点不同关系数据关注行数、索引和事务写放大 文档数据关注正文大小、版本和附件分层 时序数据关注每秒写入、时间保留和压缩 向量数据关注维度、分块数量、模型并存和索引比例。推荐采用以下容量规划流程采集当前基线 - 建立业务增长假设 - 分别估算四类数据和索引 - 加入 WAL、备份和维护空间 - 执行混合负载压测 - 按月滚动预测 - 设置阈值和扩容窗口 - 通过真实查询验证体验最终验收需要同时满足未来规划周期内磁盘和备份空间足够。向量索引重建有临时空间。时序写入和查询在高峰期不互相拖垮。关系过滤、文档标签和向量检索可以联合执行。容量增长趋势、查询延迟和资源消耗可以被持续观测。扩容、归档、降级和恢复都有明确操作步骤。容量规划的价值不在于预测一个绝对准确的数字而在于提前看见增长路径、资源瓶颈和故障窗口让数据库扩容从临时救火变成可验证的工程计划。转载自欢迎 点赞✍评论⭐收藏欢迎指正