存储和 API 成本优化 - 模式

了解有关架构良好的资源和成本优化 → 数据优化的更多信息

模式

何处查看好样的
数据模型活动数据✅ 有效数据优先存储 - 定期为业务运营访问的数据保留在标准 Salesforce 对象中，具有完整的查询功能、工作流自动化和用户访问权限。活动数据证明存储投资合理，因为频繁访问需要立即可用
✅ 示例：当年业务机会和活动个案保留在具有完整功能的标准对象中
数据模型温暖数据✅ 温暖数据使用中间存储策略 - 偶尔访问用于报告或参考的数据可能会保留在 Salesforce 中，带有启用筛选视图的归档标记，或者迁移到支持基于索引的检索的大对象，而没有工作流功能
✅ 示例：上一年标记为已归档但仍可查询的历史分析业务机会
数据模型冷数据✅ 归档到大对象或外部系统的冷数据 - 为合规性保留但很少访问的数据会移动到大对象（不计入标准数据存储限制）或外部归档系统。适用于高用量归档的大对象，具有可预测的访问模式。对数据仓库或对象存储的外部归档为合规性数据提供了成本最低的保留
✅ 示例：超过 36 个月的个案归档到大对象，具有基于索引的检索，以便进行合规访问
数据模型过期数据✅ 通过自动化生命周期流程删除的过期数据 - 没有业务价值的数据过去保留要求应通过自动化流程删除，而不是无限期累积。许多组织出于“如果我们有一天需要它”的考虑而从不删除数据，导致存储增长在没有业务理由的情况下消耗预算
✅ 示例：根据法规保留要求，数据保留策略会在 7 年后自动删除记录
设置 → 系统概览 → 数据存储
设置 → 存储空间使用情况		✅ 模式:容量仪表板按增长趋势的对象显示存储消耗，按与峰值模式的集成显示 API 使用情况，以及按预测显示处理能力利用率
✅ 在限制导致停机或意外超额费用前启用主动优化
无存储跟踪 → 年度惊喜反模式:在续订协商期间发现的存储过量，需要立即以保费价格购买，而没有时间评估归档策略
⚏ 组织每年购买额外的存储，而没有分析哪些数据消耗容量，或者归档是否会降低增长

模式

何处查看好样的
Salesforce Files 大文件✅ 外部文件存储集成，大规模节省成本 - 将文件存储在 Amazon S3 或 Azure Blob Storage 等服务中，Salesforce 会维护链接到外部内容的参考记录。外部存储每月每 GB 成本为 0.02-0.05 美元，相比之下，Salesforce 文件存储每月每 GB 成本为 1-3 美元，这取决于版本，从而大规模节省了 10-20 倍的成本
✅ 示例：合同管理解决方案将有效合同（过去 24 个月）存储在 Salesforce Files 中，以便进行本机预览和协作，使用 Salesforce 链接自动将旧合同迁移到 S3，在保持访问权限的同时将文件存储减少 70%
✅ 权衡：外部存储集成需要开发工作量，并引入了对外部服务的依赖，但为文件繁重的用例节省了 10-20 倍的成本，在几个月内甚至达到了平衡
内容管理文件生命周期✅ 文件生命周期管理 - 实施自动归档，将超过保留阈值的文件移动到外部存储或删除。初始创建后很少访问的文件，包括已完结个案和已替换文档版本的个案附件，是主要归档候选项
✅ 备注：文件存储包括 Salesforce Files、附件、文档和内容。具有大量文档用例的组织（包括合同管理、资产库和个案附件）接近文件存储限制的速度往往比数据存储更快

模式

何处查看好样的
Sandbox 管理部分复制模板✅ 选择性数据模板优化 Sandbox 存储容量 - 当测试场景不需要完整数据量时，从部分复制模板中排除大量对象。实施特定于 Sandbox 的数据保留，删除超过测试要求的记录，为其他测试数据释放容量
✅ 示例：部分复制 Sandbox 模板包括过去 12 个月的业务机会和个案，但不包括归档的数据，提供 5 GB 容量内的代表性测试数据，而不是要求完整复制
✅ 权衡：定义选择性数据模板需要分析工作，但通过消除测试场景不必要的数据，可以使用成本更低的 Sandbox 类型
Sandbox 管理刷新节奏✅ 刷新节奏符合实际数据新鲜度要求 - 使 Sandbox 刷新符合实际数据新鲜度要求，而不是任意计划。许多组织每月刷新一次完全复制 Sandbox，而每季度刷新一次就足够他们的测试模式了，这就浪费了可以支持其他 Sandbox 的刷新容量
✅ 示例：完全复制 Sandbox 每季度刷新一次，而不是每月刷新一次，为额外的部分复制 Sandbox 释放了刷新容量
Sandbox 管理临时 Sandbox✅ 具有到期策略的临时 Sandbox 管理 - 通过记录的删除日期跟踪为特定项目创建的环境或峰值测试。临时 Sandbox 扩散是常见的废物来源，因为项目 Sandbox 毫无道理地转变为永久状态。实施需要续订理由的到期策略，以维护超出初始范围的临时环境
✅ 示例：创建的具有 90 天到期时间的项目 Sandbox，需要业务理由，才可以延伸到项目完成之后

模式

何处查看好样的
集成监控峰值使用情况分析✅ 峰值使用分析确定计划优化机会 - 确定每日和每周消耗模式。集中在工作时间的集成计划与用户发起的 API 调用竞争。在非高峰时段分发批处理集成优化了容量利用率，而不会增加限制
✅ 示例：从上午 9 点重新安排到凌晨 2 点的批量集成，减少了高峰时间 API 竞争，并实现了现有容量内的其他集成
自定义代码批量 API 2.0✅ 批量 API 2.0 适用于任何处理数百条记录的操作 - 使用批量 API 2.0 适用于任何处理数百条记录的操作。与单独处理记录相比，每个作业最多可以处理 1.5 亿个记录，消耗的 API 调用最少
✅ 示例：夜间数据同步使用批量 API 2.0，以最少的 API 消耗处理 100,000 个记录，而不是每个记录的单个 API 调用
自定义代码平台缓存✅ 平台缓存消除参考数据的重复查询 - 缓存频繁访问的参考数据，消除重复查询。缓存国家/地区代码、产品目录或配置数据减少了重复查询未更改参考数据的集成的 API 消耗
✅ 示例：产品目录缓存在平台缓存中，将 API 调用从每天 1000 次查询减少到单次缓存刷新
综合架构变更数据捕获✅ 变更数据捕获消除了浪费的轮询模式----使用变更数据捕获进行数据同步,而不是轮询模式。CDC 仅在数据更改时发布事件，消除了浪费的 API 调用来检查未发生的更改
✅ 示例：客户数据同步在客户更新时使用变更数据捕获发布事件，仅消耗实际变更的 API 调用（每天 200 次），而不是每小时轮询每条客户记录（每天 120 万次查询）
✅ 权衡：事件驱动的架构需要平台事件或 CDC 实施工作，但将变更检测模式的 API 消耗减少 95% 以上，并在几周内达到平衡
无监控 → 反应式发现反模式:仅在出现限制异常时监控 API 消耗，在压力下创建反应性消防和紧急架构更改
缺少在限制约束业务运营之前启用优化的主动趋势分析

模式

何处查看好样的
集成模式同步实时✅ 同步集成消耗最高 API 容量 - 实时集成消耗每个事务的一个或多个 API 调用。高用量事务流会消耗大量 API 容量。当即时数据一致性是强制性业务需求，但 API 消耗成本最高时，同步模式适用
✅ 示例：尽管 API 成本较高，但订单提交需要在 ERP 系统中立即进行库存检查和预订，证明同步模式是正确的
集成模式批处理✅ 批量集成与同步相比，减少了 90% 以上的 API 消耗 - 批量处理记录，显著减少了每个记录的 API 调用。批量 API 2.0 在最少的 API 消耗内处理数百万条记录。与同步模式相比，当接近实时的同步满足业务需求并消除 90% 以上的 API 消耗时适用
✅ 示例：客户数据同步每小时批量运行一次，而不是实时更新，通过可接受的 1 小时数据延迟将 API 消耗降低了 95%
集成模式事件驱动✅ 事件驱动模式仅根据实际变化有效扩展消耗资源 – – 使用平台事件或变更数据捕获实现高效的事件分发，无需轮询开销。事件驱动的模式可以高效扩展，因为它们仅在实际发生更改时消耗资源，而不是重复检查未发生的更改
✅ 示例：业务机会阶段更改会发布下游系统消耗的平台事件，从而消除轮询，并将 API 消耗降低 98%
集成平台 MuleSoft TCO✅ MuleSoft 增加了平台成本，但可能会降低总集成 TCO - MuleSoft Anypoint 平台增加了平台许可成本(每年 2 万到 20 万美元以上),但可以通过智能缓存、连接池、批量优化和所有集成模式的统一治理来降低总集成 TCO
✅ 权衡：当集成计数超过 5-7 个连接时，中间件证明了投资的合理性，提供了可重用性和治理，从而降低了长期维护成本
第三方集成 API 定价✅ 基于预测交易量的第三方 API 成本 - 基于反映实际使用的预测交易量而不是假设低用量的最低层来建模第三方成本。第三方 API 定价从免费等级到按通话计费到统一费率企业许可证不等
✅ 示例：付款网关的集成 TCO 模型包括 15000 美元的年平台费 + 每个交易 0.10 美元，估计每年 5 万个交易（5000 美元） + 25000 美元的集成开发 + 5000 美元的年度维护，第一年总计 5 万美元，持续 10000 美元
集成维护点对点与中心✅ 点对点集成成倍增加维护工作量 - 每个集成点都包含初始构建、持续维护、错误处理演变以及任一端点更改时的适应。随着系统数量的增加，点对点集成使维护工作量成倍增加。五个具有点对点连接的系统需要 10 个集成维护流。十个系统需要 45 个流。通过集成平台的轮辐模式将指数增长缩减为线性增长
✅ 示例：具有 8 个连接的系统的组织从 28 个点对点集成过渡到 8 个轮辐连接，将维护流减少了 71%
集成运营支持成本✅ 支持和故障排除成本随集成数量的增加而增加 - 每个集成都会产生潜在的故障点，需要监控基础设施、警报配置、Runbook 文档和事件响应功能。在初始开发之后的集成 TCO 中包含持续支持成本
✅ 示例：集成支持成本按每年初始开发成本的 15-20% 建模，用于持续监控、故障排除和事件响应

反模式

何处查看什么不好的样子
所有历史数据会无限期保留在活动存储中存储增长消耗预算，没有业务理由。组织每年购买额外的存储，而没有分析哪些数据消耗容量，或者归档策略是否会降低增长率
**补救：**定义具有生命周期阶段的数据保留策略：有效（0-12 个月）、温暖（12-36 个月）、冷（归档 36 个月以上）和过期（在监管保留后删除）。实施到大对象或外部存储的自动归档
部分复制模板包含所有对象，无需筛选消耗 5 GB 的容量，历史数据与测试无关，当战略数据选择将以更低的成本启用部分复制使用时，迫使购买完全复制
**补救：**分析测试要求并创建选择性部分复制模板，仅包含过去 12-18 个月的数据，不包括测试场景不需要的大量对象
集成每 15 分钟轮询一次所有记录，检查更改当 95% 的轮讯发现没有变化时，每天消耗 5M API 调用，将 API 容量浪费在不必要的查询上。产生达到 API 限制并阻止合法集成完成的风险
**补救：**使用变更数据捕获或平台事件替换轮讯模式，仅在实际变更时消耗 API 调用，将 API 消耗减少 95% 以上
集成按顺序为每个记录类型进行单独的 API 调用与批处理方法相比，API 消耗增加了 5-10 倍。当单个复合调用足够时，订单处理消耗每个订单 8 次 API 调用
**补救：**将复合 API 批处理相关操作实施为单个 API 调用，将消耗从每个事务 8 次调用减少到每个事务 1 次调用（减少 87%）
为每个开发团队购买的完全复制 Sandbox当部分复制满足大多数测试要求时，乘法的成本是原来的 5 倍。完全复制的成本比部分复制高 5-10 倍，并且仅每月刷新一次，而不是每 5 天刷新一次
**补救：**保留完全复制，仅用于生产前 UAT 和性能验证。将 Developer Pro 用于开发和部分复制与集成测试的目标数据模板一起使用
基于”免费 API 层”批准的集成，无需体积建模⚠ 预计交易量在第 2 个月超过免费层，导致意外的 15000 美元年度成本未包含在预算或 TCO 分析中
**补救：**根据预测的交易量对第三方 API 成本进行建模，包括按比例预测。在批准前，在集成 TCO 中包含平台费用、每笔交易费用和超额费用
仅在出现限制异常时监控 API 消耗在压力下创建反应式消防和应急架构更改。限制会在确定优化业务机会之前创建停机
**补救：**通过集成级属性、峰值使用情况分析和增长预测，实施主动 API 监控仪表板。在示例利用率阈值（例如 70% 和 85%）设置警报，为优化提供提前期
构建自定义文档生成，因为“我们有开发人员可用”当 AppExchange 选项以每个用户每月 15 美元的价格（对于 100 个用户，每年 18 万美元）提供更快的部署、供应商维护和更低的 5 年总拥有成本时，初始构建费用为 8 万美元 + 年度维护费用为 1 万美元进行自定义开发
**补救：**在商品功能的自定义开发之前，评估 AppExchange 解决方案。模型 3-5 年 TCO，比较构建与购买，包括维护、平台兼容性和支持成本
临时项目 Sandbox 无正当理由地过渡到永久状态⚏ Sandbox 扩散消耗预算，没有业务价值。当 10 个 Sandbox 通过适当的生命周期管理满足实际开发需求时，组织会累积 20 多个 Sandbox
**补救：**实施需要续订理由的 Sandbox 到期策略。通过记录的删除日期和到期审查的自动提醒跟踪 Sandbox

上次更新:2026-06-08