---
schema_version: "1"
id: b630cde9f301a4da359c664b2dce3201d5fe227ca72e94e0640a6e65b324e5e0
title: 儲存空間和 API 成本最佳化 - 模式
collection: architect
version: current
locale: zh-tw
portal_url: https://docs.salesforce.com/architect/current/zh-tw/well-architected/guides/resource-and-cost-optimization-storage-api-patterns.md
canonical_url: https://architect.salesforce.com/docs/architect/zh-tw/well-architected/guide/resource-and-cost-optimization-storage-api-patterns.html
source_site: architect.salesforce.com
content_type: documentation
content_hash: 00685608ba0ac7e9e56c25720f972e8d0bd1381202d539803a8030523785b62e
products:
- 結構良好的架構
- Architect Site Content Repo
---
# 儲存空間和 API 成本最佳化 - 模式
深入瞭解結構正確的 [資源和成本最佳化](/docs/architect/zh-tw/well-architected/guide/resource-and-cost-optimization.html) → [資料最佳化](/docs/architect/zh-tw/well-architected/guide/resource-and-cost-optimization.html#data-optimization)
## 資料儲存空間最佳化
**模式**
| 要尋找的位置 | 良好的外觀 |
| --- | --- |
| **資料模型** 啟用資料 | ✅ **啟用中資料會收到頂級儲存空間處理** \- 針對業務作業定期存取的資料會保留在標準 Salesforce 物件中,並具有完整的查詢功能、工作流程自動化和使用者存取權。啟用中的資料是合理的儲存空間投資,因為頻繁存取需要立即可用性
✅ 範例:本年度的機會和啟用個案會保留在具有完整功能的標準物件中 |
| **資料模型** Warm Data | ✅ **熱資料使用中繼儲存策略** \- 有時為了報告或參考而存取的資料可能會保留在 Salesforce 中,且具有啟用篩選檢視的歸檔標記,或移轉至支援以索引為基礎且不具備工作流程功能的大型物件
✅ 範例:標記為已歸檔但仍可供歷程記錄分析查詢的前一年度機會 |
| 冷資料的 **資料模型** | ✅ **歸檔至大型物件或外部系統的冷資料** \- 為了合規性而保留但不常存取的資料會移至大型物件 (不計入標準資料儲存空間限制) 或外部歸檔系統。大型物件適用於大量歸檔,且具有可預測的存取模式。對資料倉庫或物件儲存空間的外部歸檔可提供合規性資料的最低成本保留
✅ 範例:超過 36 個月的個案已封存到大型物件中,並使用以索引為基礎以取得合規性存取權 |
| **資料模型** 過期的資料 | ✅ **透過自動化生命週期流程刪除的過期資料** \- 過去的資料保留需求沒有業務價值應透過自動化流程刪除,而非無限期累積。許多組織永遠不會刪除資料,因為擔心「有時需要什麼」,進而導致儲存空間成長耗用預算,而沒有業務理由
✅ 範例:資料保留原則會根據法規保留需求,在 7 年後自動刪除記錄 |
| **設定** → 系統概觀 → 資料儲存空間
**設定** → 儲存空間用量 | ✅ **模式**:容量顯示面板會依具有成長趨勢的物件顯示儲存空間耗用、透過與峰值模式整合的 API 用量,以及透過預測的處理容量利用率
✅ 在限制造成中斷或非預期超額費用之前啟用主動最佳化 |
| **無儲存空間追蹤** → 年度驚喜 | ⚡️ **反模式**:在續約協商期間發現的儲存超額,需要立即以高級價格購買,而沒有時間評估歸檔策略
⚡️ 組織每年購買額外的儲存空間,而無須分析耗用哪些資料的容量或歸檔是否會減少成長 |
## 檔案儲存空間最佳化
**模式**
| 要尋找的位置 | 良好的外觀 |
| --- | --- |
| **Salesforce Files** 大檔案 | ✅ **外部檔案儲存整合以大規模節省成本** \- 在如 Amazon S3 或 Azure Blob Storage 等服務中儲存檔案,而 Salesforce 會維護連結至外部內容的參考記錄。外部儲存空間的每月成本為每 GB 0.02-0.05 美元,相較於每月每 GB 1-3 美元的 Salesforce 檔案儲存空間 (視版本而定),進而大規模節省 10-20 倍的成本
✅ 範例:契約管理解決方案會將啟用中契約 (過去 24 個月) 儲存在 Salesforce Files 中,以供原生預覽和協同合作,使用 Salesforce 連結自動將舊契約移轉至 S3,同時減少 70% 的檔案儲存空間並維持存取權
✅ 權衡:外部儲存空間整合需要開發努力,並且會對外部服務產生相依性,但可為檔案繁重的使用個案節省 10 到 20 倍的成本,即使在幾個月內也會消失 |
| **內容管理**檔案生命週期 | ✅ **檔案週期管理會封存或刪除舊檔案** \- 實作自動封存,將檔案超過保留值至外部儲存或刪除。初始建立之後極少存取的檔案,包括已結束個案的個案附件和已取代文件版本的主要封存候選項目
✅ 注意:檔案儲存空間包含 Salesforce 檔案、附件、文件和內容。具有大量文件使用個案的組織,包括契約管理、資產庫和個案附件,通常會比資料儲存空間更快達到檔案儲存空間限制 |
## Sandbox 儲存空間最佳化
**模式**
| 要尋找的位置 | 良好的外觀 |
| --- | --- |
| **Sandbox 管理**部分複製範本 | ✅ **選擇性資料範本可最佳化 Sandbox 儲存容量** \- 當測試案例不需要完整資料量時,從「部分複製」範本排除大量物件。實作 Sandbox 特定的資料保留,移除超過測試所需的記錄,釋出額外測試資料的容量
✅ 範例:Partial Copy Sandbox 範本包含過去 12 個月的機會和個案,但不包含已歸檔的資料,提供 5 GB 容量內的代表測試資料,而不需要完整複本
✅ 權衡:定義選擇性資料範本需要分析精力,但透過去除測試案例不需要的資料來啟用低成本 Sandbox 類型 |
| **Sandbox 管理**重新整理步調 | ✅ 符合實際資料更新度需求的 **重新整理步調** \- 讓 Sandbox 重新整理符合實際資料更新度需求,而非任意排程。當每季重新整理足以達到測試模式時,許多組織會每月重新整理「完整複製」Sandbox,因此會浪費可支援其他 Sandbox 的重新整理容量。
✅ 範例:「完整複製 Sandbox」每季重新整理一次,而非每月重新整理一次,以釋出額外「部分複製 Sandbox」的重新整理容量 |
| **Sandbox 管理**暫時 Sandbox | ✅ **具有到期原則的暫時 Sandbox 管理** \- 使用記錄的刪除日期追蹤針對特定專案建立的環境或高峰測試。暫時 Sandbox 擴充是常見的廢棄物來源,因為專案 Sandbox 會轉換為永久狀態而沒有任何理由。實作需要續約理由的到期原則,以維護超出初始範圍的暫時環境
✅ 範例:以 90 天到期建立的專案 Sandbox,需要業務理由才能延伸至專案完成之外 |
## API 呼叫最佳化
**模式**
| 要尋找的位置 | 良好的外觀 |
| --- | --- |
| **整合監視**用量峰值分析 | ✅ **峰值用量分析可識別排程最佳化機會** \- 識別每日和每週耗用模式。在營業時間內集中的整合排程會與使用者起始的 API 呼叫進行競爭。跨離峰時段散佈批次整合可最佳化產能利用率,而不會增加限制
✅ 範例:從上午 9 點重新排程批次整合到上午 2 點,減少峰時 API 衝突並啟用現有容量內的其他整合 |
| **自訂程式碼**大量 API 2.0 | ✅ 針對處理數百筆記錄的任何作業使用 **大量 API 2.0** \- 針對處理數百筆以上記錄的任何作業使用大量 API 2.0。與個別處理記錄相比,大量 API 每個工作最多可處理 150 百萬筆記錄,耗用最少的 API 呼叫
✅ 範例:每晚資料同步化使用大量 API 2.0 處理 100,000 筆記錄,而不需要每個記錄的個別 API 呼叫。 |
| **自訂程式碼**平台快取 | ✅ **平台快取會消除重複查詢參照資料** \- 快取經常存取的參照資料,以消除重複查詢。快取國家/地區代碼、產品型錄或組態資料可減少重複查詢未變更參考資料之整合的 API 耗用
✅ 範例:在平台快取中快取的產品型錄,將 API 呼叫從 1,000 次每日查詢減少到單一快取重新整理 |
| **整合結構** 變更資料 | ✅ **變更資料摘取可消除浪費的輪詢模式** \- 使用變更資料摘取進行資料同步,而非使用輪詢模式。CDC 只會在資料變更時發佈事件,以免浪費 API 呼叫檢查尚未發生的變更
✅ 範例:客戶資料同步化會在客戶更新時使用「變更 資料擷取」發佈事件,僅耗用 API 呼叫來進行實際變更 (200 天),而非每小時輪詢每個客戶記錄 (1.2 萬個每日查詢)
✅ 權衡:以事件為導向的結構需要「平台事件」或 CDC 實作工作,但會降低變更偵測模式的 API 耗用 95% 以上,即使在幾週內也會損毀 |
| **無監視** → 反應性探索 | ⚡️ **反模式**:僅在發生限制例外時監控 API 耗用,在壓力下建立反應性防火和緊急結構變更
⚡️ 缺少主動趨勢分析,在限制限制業務營運之前啟用最佳化 |
## 整合結構成本
**模式**
| 要尋找的位置 | 良好的外觀 |
| --- | --- |
| 同步即時的 **整合模式** | ✅ **同步整合耗用最高的 API 容量** \- 即時整合每個交易耗用一或多個 API 呼叫。大量交易流程會耗用大量 API 容量。當立即資料一致性是必要業務需求,但具有最高 API 耗用成本時,適合的同步模式
✅ 範例:訂單提交需要立即在 ERP 系統中庫存檢查和預留,這可證明同步模式,儘管 API 成本較高 |
| **整合模式**批次處理 | ✅ **批次整合會減少 API 耗用 90% 以上,相較於同步** \- 大量處理記錄,大幅減少每個記錄的 API 呼叫數量。「大量 API 2.0」會在最少的 API 耗用期間處理數百萬筆記錄。與同步模式相比,近乎即時同步符合業務需求並減少 90% 以上 API 耗用時適合
✅ 範例:客戶資料同步會每小時批次執行,而非即時更新,以可接受的 1 小時資料延遲降低 API 耗用量 95% |
| 以事件為導向的 **整合模式** | ✅ **以事件為導向的模式只會在實際變更**時有效調整耗用資源 - 使用「平台事件」或「變更資料」,以有效地散佈事件,而無須輪詢負擔。以事件為導向的模式會有效率地調整規模,因為它們只會在實際發生變更時耗用資源,而不是重複檢查尚未發生變更
✅ 範例:機會階段變更會發佈下游系統耗用的「平台事件」,減少輪詢並減少 API 耗用 98% |
| **整合平台** MuleSoft TCO | ✅ **MuleSoft 可增加平台成本,但可能減少整合總成本** \- MuleSoft Anypoint Platform 可增加平台授權成本 (每年 $20,000-200K 以上),但可透過智慧快取、連線集區、批次最佳化和所有整合模式的統一管理來減少整合總成本
✅ 權衡:當整合計數超過 5-7 個連線時,中間軟體可提供可重複使用性和監管,以降低長期維護成本 |
| **第三方整合** API 定價 | ✅ 根據預測交易量模型化 **第三方 API 成本** \- 根據反映實際使用量的預測交易量,而非假設低交易量的最低層級,來模型化第三方成本。第三方 API 定價會從免費層級到按通話計費到固定價格企業授權而有所不同
✅ 範例:Payment Gateway 的整合 TCO 模型包含 $15,000 年度平台費用 + 每筆交易 $0.10 預估為每年 50,000 筆交易 ($5,000) + $25,000 個整合開發 + $5,000 筆年度維護,第一年總計 $50,000,進行中 $10,000 |
| **整合維護**點對點與中心 | ✅ **點對點整合會以指數方式乘以維護工作** \- 每個整合點包含初始建立、持續維護、錯誤處理進化,以及當任一端點變更時的調整。點對點整合會隨著系統計數的成長,以指數方式乘以維護工作。具有點對點連線的五個系統需要 10 個整合維護串流。10 個系統需要 45 個串流。透過整合平台的中心與對話模式會降低線性規模的指數成長
✅ 範例:具有 8 個已連線系統轉換的組織,從 28 個點對點整合到 8 個中心與發話連線,減少維護串流 71% |
| **整合作業**支援成本 | ✅ 隨著整合計數而增加的 **支援和疑難排解成本** \- 每個整合都會建立潛在失敗點,這需要監視基礎結構、警示組態、執行手冊文件和事件回應功能。在初始開發以外的整合 TCO 中包含進行中的支援成本
✅ 範例:針對持續監視、疑難排解和事件回應,以每年為初始開發成本的 15-20% 建模的整合支援成本 |
## 儲存空間與 API
**反模式**
| 要尋找的位置 | 看起來怎麼壞 |
| ------------ | ------------------- |
| **所有歷程記錄資料會無限期保留在已啟用的儲存空間中** | ⚡️ 不具業務理由的儲存空間成長耗用預算。組織每年購買額外的儲存空間,而不分析資料耗用容量或歸檔策略是否可降低成長率
⚡️ **補救:**使用生命週期階段定義資料保留原則:啟用中 (0-12 個月)、溫暖 (12-36 個月)、冷 (36 個月以上已歸檔) 和已到期 (在監管保留後刪除)。將自動封存實作至大型物件或外部儲存空間 |
| **部分複製範本包含所有物件而不需篩選** | ⚡️ 使用與測試無關的歷程記錄資料耗用 5 GB 容量,強制購買「完整複本」,當策略性資料選取會以明顯更低的成本啟用「部分複製」使用
⚡️ **補救:**分析測試需求並建立選用的「部分複製」範本,其中僅包含過去 12-18 個月的資料,並排除測試案例不需要的大量物件 |
| **整合會每 15 分鐘輪詢所有記錄,檢查是否有變更** | ⚡️ 當 95% 的投票發現沒有變更時,每日耗用 5 萬個 API 呼叫,這會浪費不必要的查詢 API 容量。造成達到 API 限制的風險,並防止合法整合完成
⚡️ **補救:**將輪詢模式取代為只有在實際發生變更時才會耗用 API 呼叫的「Change 資料擷取」或「平台事件」,進而將 API 耗用量減少 95% 以上 |
| **整合會依序針對每個記錄類型進行個別的 API 呼叫** | ⚡️ 相較於批次方法,API 耗用量乘以 5-10。當單一複合呼叫足夠時,每個訂單耗用 8 個 API 呼叫的訂單處理
⚡️ **補救:**將複合 API 批次相關作業實作為單一 API 呼叫,將耗用從每個交易 8 次呼叫減少為每個交易 1 次呼叫 (87% 減少) |
| **為每個開發小組購買的完整複製 Sandbox** | ⚡️ 當「部分複製」符合大多數測試需求時,成本相乘 5 倍。「完整複製」的成本高於「部分複製」的 5-10 倍,且僅每月重新整理一次,相較於每 5 天重新整理一次
⚡️ **補救:**僅保留「完整複本」以進行生產前 UAT 和效能驗證。使用 Developer Pro 進行開發和透過目標資料範本進行部分複製以進行整合測試 |
| **根據「免費 API 層級」而未經大量建模的整合獲得批准** | ⚡️ 預測的交易量超出第 2 個月的免費層級,導致預算或 TCO 分析未包含的意外 $15,000 年度成本
⚡️ **補救:**根據預測的交易量 (包括調整預測) 模型化第三方 API 成本。在整合 TCO 中包含平台費用、個別交易成本和超額費用,再批准 |
| **僅在發生限制例外時監控 API 耗用** | ⚡️ 在壓力下建立反應性防火和緊急結構變更。在找出最佳化機會之前,限制會建立中斷
⚡️ **補救:**使用整合層級歸屬、高峰用量分析和成長預測,實作主動式 API 監視顯示面板。在 70% 和 85% 的範例利用率值設定警示,提供最佳化前置時間 |
| **由於「我們有開發人員可用」,因此建立自訂文件產生** | ⚡️ 以 $80,000 起初建立的自訂開發 + $15,000 年度維護,當 AppExchange 選項每月 $15 為每位使用者 (每年 $18,000 為 100 位使用者) 提供更快的部署、供應商維護和更低的 5 年 TCO
⚡️ **補救:**在為商品功能進行自訂開發之前,請先評估 AppExchange 解決方案。模型 3-5 年 TCO 比較建立與購買 (包括維護、平台相容性和支援成本) |
| **暫時專案 Sandbox 會轉換為永久狀態但沒有理由** | ⚡️ 不具有業務價值的 Sandbox 繁殖耗用預算。當 10 個組織透過適當的生命週期管理滿足實際開發需求時,組織會累積 20 個以上的 Sandbox
⚡️ **補救:**實作需要續約理由的 Sandbox 到期原則。追蹤具有已記錄刪除日期和自動警示的 Sandbox 以供到期審查 |
## 相關資源
- [資源和成本最佳化支柱](https://architect.salesforce.com/docs/architect/zh-tw/well-architected/guides/resource-and-cost-optimization.md)
- [資源和成本最佳化 - 授權模式](https://architect.salesforce.com/docs/architect/zh-tw/well-architected/guide/resource-and-cost-optimization-license-patterns.md)
- [營運傑出支柱](https://architect.salesforce.com/docs/architect/zh-tw/well-architected/guides/operational-excellence.md)
---
**上次更新**:2026-06-08