本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
Amazon OpenSearch Service 的成本最佳化技術
以下是在使用 Amazon OpenSearch Service 時最佳化成本的最常見技術：受管叢集和無伺服器。由於每個工作負載都是唯一的，請根據您的特定使用模式評估這些策略，並在測試環境中驗證它們，然後再套用至生產環境。
Amazon OpenSearch Service 受管叢集的成本最佳化
衍生來源 — 略過儲存 _source 欄位
衍生來源是一種儲存最佳化功能，可消除儲存_source欄位的額外負荷：
-
OpenSearch 會儲存每個擷取的文件兩次：一次在
_source欄位中 （原始文件），一次作為索引欄位進行搜尋。 -
光是
_source欄位就可能會耗用大量儲存空間，通常是總索引儲存空間的 30–50%。 -
使用衍生來源時，您可以略過儲存
_source，並在需要時從索引欄位動態重建它 （搜尋、取得、mget、重新索引或更新操作期間）。 -
這是選擇加入，在建立索引時使用複合索引設定啟用。
-
適用於支援 OpenSearch 3.1 或更新版本的所有區域。
最適合：分析和日誌工作負載，您不需要經常擷取原始文件，但仍需要搜尋和彙總欄位。
OR1 / OR2 / OM2 執行個體 — OpenSearch 最佳化執行個體系列
OR1 和更新的 OR2 和 OM2 執行個體透過區段複寫使用 Amazon S3 進行複本儲存：
-
OR2：比 OR1 高出高達 26% 的索引輸送量，比 R7g 執行個體多出 70%。
-
OM2：索引輸送量比 OR1 高出 15%，比 M7g 執行個體多出 66%。
-
兩者都使用相同的架構：用於主要儲存的本機 EBS 和用於耐用性的 S3。
-
消除複本儲存成本 — 存放在 S3 中的複本 (11 九秒耐久性），而不是昂貴的 EBS 磁碟區。
-
比上一代執行個體改善高達 30% 的價格效能。
-
支援淺快照 v2 — 近乎即時的快照，沒有 I/O 額外負荷。
最適合：索引密集型操作分析和日誌分析工作負載。
如需詳細資訊，請參閱 OR2 和 OM2 最新消息公告
索引彙總 — 彙總歷史時間序列資料
索引彙總摘要並將較舊的時間序列資料壓縮為更粗的時間間隔，大幅減少儲存磁碟區：
-
IoT/感應器資料：將每秒資料保存在最近期間的熱儲存中；針對較舊的資料彙總為每小時或每日摘要。
-
系統指標：保留過去 30 天的詳細指標；將較舊的資料彙總為每小時或每日摘要。
-
日誌資料：保留作用中故障診斷時段的完整詳細資訊 （例如 1 週）；維護較舊期間的摘要錯誤模式。
-
結合 ISM 政策，在單一生命週期政策中自動化彙總和層遷移。
-
從秒到小時的彙總與從秒到分鐘的彙總時節省更多。
如需詳細資訊，請參閱索引彙總部落格文章
索引狀態管理 — 自動化完整資料生命週期
ISM 政策會透過儲存層和生命週期動作自動移動索引：
-
自動遷移索引：根據存留期、大小或文件計數，從熱到 UltraWarm 到冷再刪除。
-
在層轉換之前觸發彙總，以減少資料量。
-
設定轉換政策 （例如，當索引達到 50 GB 或 30 天） 以控制索引成長。
-
自動化唯讀索引上的強制合併，以從已刪除的文件回收儲存。
-
結合彙總，可大幅節省大量時間序列資料集的成本。
預留執行個體 — 承諾可預測折扣
對於穩定、可預測的分析工作負載，預留執行個體提供高於隨需定價的大幅折扣：
-
無預付、部分預付或所有預付付款選項的 1 年或 3 年承諾條款。
-
最適合持續執行的熱層資料節點和專用主節點。
-
使用 AWS 定價計算器在遞交之前預估節省成本。
-
預留執行個體是套用至隨需執行個體的帳單折扣，不需要變更基礎設施。
適當大小的執行個體類型和計數
Well-Architected OpenSearch Lens 和適當調整大小最佳實務的重要指導：
-
一律使用最新一代的執行個體 （例如，Graviton3 Graviton2-based 執行個體的效能提升高達 25%)。
-
使用 gp3 EBS 磁碟區而非 gp2 — 以較低的成本提供更好的效能，無需額外付費。
-
將執行個體類型與工作負載配對：針對大量搜尋進行記憶體最佳化、針對大量索引進行運算最佳化。
-
評估專用叢集管理員節點：只需要 3 個以上的資料節點；避免過度佈建主節點大小。
-
監控 CloudWatch 指標以偵測過度佈建：持續 CPU 低於 40%、JVM 低於 50%，以及儲存低於 50% 是浪費的跡象。
-
最佳範圍：持續工作負載的 CPU 60–80%、JVM 65–85%、儲存 70–85%。
如需詳細資訊，請參閱正確調整大小最佳實務部落格文章
碎片最佳化 — 避免過度分片
過度分片是隱藏的成本驅動因素 — 太多小碎片浪費 CPU、記憶體和 JVM 堆積：
-
建議的碎片大小：根據工作負載，每個碎片 10–50 GiB。
-
每個 GiB 的 Java 堆積不超過 25 個碎片，每個資料節點不超過 1，000 個碎片。
-
使用 ISM 輪換政策來控制索引成長，並避免不受限制的碎片擴散。
-
在耐久性允許的情況下減少複本計數 (OR1/OR2 執行個體完全不需要複本）。
-
在唯讀索引上使用強制合併，以減少區段計數並回收儲存。
如需詳細資訊，請參閱我需要多少碎片？
使用 Amazon S3 進行零 ETL/直接查詢
對於極少被查詢但必須保持可存取的資料，直接查詢 （含 S3 的零 ETL) 允許直接從 OpenSearch 查詢 S3 資料，而不擷取資料：
-
沒有擷取成本 — 資料會保留在 S3 中。
-
封存資料沒有熱層儲存成本。
-
Pay-per-query的運算模型。
-
支援 OpenSearch Dashboards 進行視覺化。
-
可接受秒或分鐘的延遲，不適用於即時使用案例。
在擷取時取樣和壓縮
在資料到達 OpenSearch 之前降低成本：
-
取樣：僅擷取大量日誌串流的代表性子集 （例如 10% 的偵錯日誌）。
-
索引壓縮：啟用最佳壓縮轉碼器以減少儲存體使用量。
-
欄位篩選：在編製索引之前捨棄高基數、低值欄位 （例如，舊日誌的原始堆疊追蹤）。
-
保留政策：定義符合合規要求的最大保留時段 — 永遠不會無限期存放資料。
避免延長支援成本 — 在引擎版本上保持最新狀態
Amazon OpenSearch Service 會針對延伸支援中的引擎版本，按標準化執行個體小時收取固定費用：
-
除了執行個體成本之外，繼續使用較舊、不支援的版本會產生額外費用。
-
升級至目前支援的版本，以避免延長支援費用。
成本分配標籤和 CloudWatch 監控
主動成本控管可防止浪費：
-
將成本分配標籤套用至 OpenSearch 網域，以追蹤每個團隊或工作負載的詳細成本。
-
設定儲存使用率、JVM 壓力和 CPU 的 CloudWatch 警示，以提早擷取過度佈建。
-
使用 AWS Cost Explorer 來識別持續低使用率的網域。
-
評估自動調整 — 自動調整 JVM 堆積大小和其他設定，以提高效能並減少資源浪費。
Amazon OpenSearch Service Serverless 的成本最佳化
磁碟最佳化向量搜尋 （向量集合）
磁碟最佳化向量搜尋是向量工作負載最強大的降低成本技術之一。它只會將壓縮向量保留在 RAM 中，並在磁碟上儲存完整精確向量，以記憶體內模式成本的一小部分執行向量搜尋。
運作方式：
-
在標準 (
in_memory) 模式中，完整的 HNSW 圖形會載入 RAM 中，這會大規模變得非常昂貴。 -
在
on_disk模式中，只有壓縮 （量化） 向量會保留在記憶體中，以產生候選項目；完整精確度向量只會從磁碟擷取到最終重新評分階段 （兩階段搜尋）。 -
這可大幅降低 RAM 需求，同時維持高搜尋品質。
-
預設
on_disk模式使用 32 倍二進位量化，相較於記憶體內模式，記憶體需求減少 97%。 -
支援壓縮層級：2x (FP16)、4x （位元組）、8x、16x、32x （二進位）。
-
100–200 毫秒範圍內的 P90 延遲 – 適用於不需要單一位數毫秒回應時間的工作負載。
節省成本基準：
| 資料集 | Recall@100 | P90 延遲 | 降低成本 |
|---|---|---|---|
| Cohere TREC-RAG | 0.94 | 104 毫秒 | 83% |
| Tasb-1M | 0.96 | 7 毫秒 | 67% |
| Marco-1M | 0.99 | 7 毫秒 | 67% |
最適合：RAG 管道、語意搜尋、文件擷取，以及任何接受 P90 延遲 100–200 毫秒且降低成本的向量工作負載。
注意
若要將此變更套用至現有的索引資料，您需要重新索引。您可以使用外部管道工具，例如 將資料重新索引到新的索引。
如需詳細資訊，請參閱磁碟最佳化向量搜尋部落格文章
向量自動最佳化 （向量集合）
自動最佳化會自動評估向量索引組態，並建議搜尋品質、延遲和記憶體成本之間的最佳權衡，而不需要向量專業知識：
-
在一小時內在 中提供最佳化建議。
-
與向量擷取管道整合。
-
可與 GPU 加速索引結合使用，適用於 10 億規模的向量資料庫。
如需詳細資訊，請參閱自動最佳化部落格文章
GPU 加速向量索引 （向量集合）
GPU 加速會將 HNSW 向量索引卸載至無伺服器 GPUs，大幅降低建置大型向量索引的時間和 OCU 成本：
-
相較於僅使用 CPU 的索引，索引建置時間快 6.4 倍到 13.8 倍。
-
高達 75% 的寫入密集型向量工作負載索引 OCU 成本。
-
GPUs 是動態連接，您只需在 GPU 加速作用中時支付 OCUs 的費用。
-
允許在一小時內內建數十億的向量資料庫。
-
以向量加速 OCUs 單獨收費。
最適合：大規模初始向量擷取或頻繁的模型重新訓練案例，其中重建索引的成本很高。
如需詳細資訊，請參閱 GPU Acceleration 部落格文章
設定最大 OCU 限制 （所有集合類型）
Amazon OpenSearch Service Serverless 會根據需求自動擴展 OCUs。如果沒有上限，成本可能會意外激增。在帳戶層級或每個集合群組設定最大 OCU 限制，以防止失控擴展。在尖峰負載期間，系統會擴展至此限制，但不會超過。
允許的值：
-
帳戶層級：任何高達 1，700 個 OCUs 的值 （不限於 16 的倍數）。
-
集合群組：1、2、4、8、16 和 16 到 1，696 個 OCUs。
監控 CloudWatch 指標 (OCUUtilization) 以隨時間調整最大 OCU 設定的大小。
注意
如果使用率達到 OCU 上限，即使包含成本，效能也可能會大幅降低。嵌入上限無法解決 OCU 峰值的根本原因。對於向量集合，根本原因通常是記憶體內向量，應透過最佳化向量索引、減少索引大小或調校取回和準確性權衡來直接解決此問題。
提示
從保守最大 OCU 開始，並只在 CloudWatch 在上限附近顯示持續使用率時增加。如果您持續達到上限，請調查根本原因，特別是向量集合的記憶體內向量使用量，而不只是提高限制。
如需詳細資訊，請參閱管理 Amazon OpenSearch Serverless 的容量限制。
最佳化保留期間 （時間序列集合）
資料生命週期政策會在指定的保留期間後自動刪除時間序列集合中的資料，防止儲存成長不受限制。只有時間序列集合支援資料生命週期政策 — 搜尋和向量集合不支援。
時間序列集合的 OCU 計數直接取決於必須保留在本機儲存中的最近資料量。時間序列集合只會保留本機 OCU 儲存中最近一部分的資料；較舊的資料會卸載至 S3，而 OCUs 的數量也會隨之擴展：
所需的 OCUs = max（最小 OCUs、在保留時段內保留資料所需的 OCUs)
設定資料生命週期政策：
-
將每個索引或索引模式的保留期間從 24 小時設定為 3，650 天。
-
Amazon OpenSearch Service Serverless 會盡力自動刪除資料 （通常在保留期間的 48 小時或 10% 內）。
-
規則可以在集合層級、索引模式層級或個別索引層級套用 — 以更具體的規則為優先。
調整大小範例：
-
1 TiB/天擷取，保留 30 天 = 大約 1 TiB 的熱資料 = 20 個用於索引OCUs + 20 個用於搜尋OCUs。
-
減少 7 天的保留期 = 大約 233 GiB 的熱資料 = 大約 4 個用於索引OCUs + 4 個用於搜尋OCUs。
較短的保留意味著本機儲存體中的熱資料較少、所需的 OCUs較少，以及較低的運算帳單。根據實際業務和合規要求調整保留期 — 預設不會無限期保留資料。
如需詳細資訊，請參閱搭配 Amazon OpenSearch Serverless 使用資料生命週期政策。
避免儲存不必要的資料 （所有集合類型）
減少直接擷取的資料量可同時降低運算 (OCUs和儲存成本：
-
在擷取時篩選欄位：使用管道在欄位到達集合之前捨棄低值欄位。
-
避免擷取重複或備援的資料：在管道層級重複刪除。
-
使用適當的索引映射：在存放但從未搜尋的欄位上停用索引 (
"index": false)。 -
對於搜尋集合：避免儲存大型二進位 Blob 或無需搜尋值即可膨脹儲存體的原始文字。
多租戶工作負載的集合群組 （所有集合類型）
集合群組允許具有不同 KMS 金鑰的多個集合在相同的安全界限內共用 OCU 資源，大幅降低多租戶架構的成本。適用於每個租用戶或每個集合使用多個 KMS 金鑰的客戶：
-
先前，每個唯一的 KMS 金鑰都需要專用 OCUs，使得每個租戶的隔離成本過高。
-
使用集合群組時，具有個別加密金鑰的租用戶可以共用 OCU 容量。
-
為大量小型租戶工作負載節省高達 90% 的成本。
-
支援最小 OCUs（保證基準，無冷啟動） 和最大 OCUs（成本上限）。
-
具有不同網路存取類型的集合 （公有和 VPC) 可以共存在同一群組中。
-
CloudWatch 指標提供每個群組對資源消耗和延遲的可見性。
最適合：SaaS 提供者、多租用戶平台或任何具有許多小型集合的工作負載，每個集合都需要自己的 KMS 金鑰。
如需詳細資訊，請參閱集合群組部落格文章
