成本最佳化支柱

AWS Well-Architected Framework 的成本最佳化支柱著重於避免不必要的成本，並以成本最佳化的方式建置架構。下列建議可協助您符合 Amazon Timestream for InfluxDB 的成本最佳化設計原則和架構最佳實務。

成本最佳化支柱著重於下列關鍵領域：

• 了解您的使用案例需求和成本

• 選取關注成本的資源

• 擴展以滿足業務需求，而不會過度花費

• 適當調整資料儲存和傳輸的大小

了解您的使用案例需求和成本

在下列使用案例中，我們建議不要使用 Timestream for InfluxDB：

• 如果您的資料模型具有關聯式資料，則 Timestream for InfluxDB 不是正確的解決方案。

• 如果您無法在查詢中使用時間篩選條件，Influx 會掃描所有無效序列。

選取關注成本的資源

InfluxDB 執行個體成本是根據執行個體執行時數的每小時費率。執行個體平均佔執行資料庫的整體成本的 85% AWS，因此適當調整大小可能會對成本產生重大影響。適當大小執行個體的最佳方法是測試應用程式效能：

• CPUUtilization 和 是MemoryUtilization持續高還是低？

• 價格與效能之間的平衡是什麼？

執行個體成本會線性擴展。db.influx.2xlarge 執行個體的每小時成本是db.influx.xlarge執行個體的兩倍，雖然它也有資源分配的兩倍。db.influx.16xlarge 執行個體是db.influx.xlarge執行個體每小時成本的 16 倍。

估計工作負載在特定時間範圍 （秒、分鐘、小時或天） 的寫入和讀取次數。InfluxDB 執行個體的 Timestream 支援每秒 50，000 到 500，000 個以上的寫入，以及根據執行個體類型每秒 10‒100 個查詢 (QPS)。例如， db.influx.2xlarge通常支援每秒最多 150，000 個寫入和大約 25 個 QPS。透過有效率的資料模型和有效率的查詢，它可以超過該效能。如果您的需求因一天中的時間、週或月而異，您可以執行下列動作來排程向上和向下擴展：

• 建立和排程 AWS Lambda 函數。

• 使用自訂排程器並執行 API 或 SDK，以利用一些緩衝時間進行擴展和縮減。

擴展以滿足業務需求，而不會過度花費

若要使用 Timestream for InfluxDB 進行入門實驗，您可以使用 db.influx.medium和 db.influx.large。在您投資較大的執行個體之前，這些執行個體的大小足以讓您獲得 Timestream for InfluxDB 的體驗。

db.influx.medium 和 db.influx.large執行個體適用於低成本的開發環境。不過，它們具有較小的 RAM (8 GiB 和 16 GiB)、較少vCPUs (1 個 vCPU 和 2 vCPUs)，以及高達 10 GB 的網路效能。並非所有工作負載都適用於這些執行個體類別。監控 CPUUtilization和 MemoryUtilization，並視需要向上或向下擴展。記憶體和 vCPU 之間的比率通常是固定的。db.influx 執行個體類別具有與 Amazon EC2 r7g 執行個體類別類似的memory-to-vCPU 比率。我們強烈建議您先執行end-to-end效能或負載測試，再進行生產。

高效率的資料建模、批次寫入和最佳化查詢需要較少的記憶體和運算用量。當需要的資源較少時，您可以使用較小的執行個體。

適當調整資料儲存和傳輸的大小

若要存放資料，請使用下列最佳實務：

• 僅將時間序列資料儲存在 Timestream for InfluxDB 中。

• 在 InfluxDB 儲存貯體上設定適當的保留，以便刪除早於保留的資料，並定期壓縮碎片。如需詳細資訊，請參閱 InfluxDB 文件。

• 針對未來的寫入最佳化磁碟用量。

• 刪除工作負載不需要的任何 InfluxDB 儲存貯體。InfluxDB 支援刪除。如果符合您的使用案例，您可以執行排定的清除。

對於資料傳輸，我們建議您在與 Timestream for InfluxDB 資料庫執行個體 AWS 區域 相同的 中部署應用程式，以避免跨區域網路額外負荷。也可能會產生資料傳輸費用。如需資料傳輸的詳細資訊，請參閱 定價頁面。