本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 成本最佳化支柱
<a name="cost-optimization"></a>

 AWS Well-Architected Framework [的成本最佳化支柱](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost-optimization.html)著重於避免不必要的成本，並以成本最佳化的方式建置架構。下列建議可協助您符合 Amazon Timestream for InfluxDB 的成本最佳化設計原則和架構最佳實務。

成本最佳化支柱著重於下列關鍵領域：
+ 了解您的使用案例需求和成本
+ 選取關注成本的資源
+ 擴展以滿足業務需求，而不會過度花費
+ 適當調整資料儲存和傳輸的大小

## 了解您的使用案例需求和成本
<a name="requirements-costs"></a>

在下列使用案例中，我們建議您不要使用 Timestream for InfluxDB：
+ 如果您的資料模型具有關聯式資料，則 Timestream for InfluxDB 不是正確的解決方案。
+ 如果您無法在查詢中使用時間篩選條件，Influx 會掃描所有無效序列。

## 選取關注成本的資源
<a name="select-resources"></a>

[InfluxDB 執行個體](https://aws.amazon.com/timestream/pricing/)成本是根據執行個體執行時數的每小時費率。執行個體平均佔在 上執行資料庫的整體成本的 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 函數](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-run-lambda-schedule.html)。
+ 使用自訂排程器並執行 API 或 SDK，以利用一些緩衝時間[進行擴展和縮減](https://docs.aws.amazon.com/timestream/latest/developerguide/timestream-for-influx-managing-modifying-db.html)。

## 擴展以滿足業務需求，而不會過度花費
<a name="scaling"></a>

若要使用 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效能或負載測試，再進行生產。

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

## 適當調整資料儲存和傳輸的大小
<a name="right-sizing"></a>

若要存放資料，請使用下列最佳實務：
+ 在 Timestream for InfluxDB 中僅儲存時間序列資料。
+ 在 InfluxDB 儲存貯體上設定適當的保留，以便刪除早於保留的資料，並定期壓縮碎片。如需詳細資訊，請參閱 [InfluxDB 文件](https://docs.influxdata.com/influxdb/v2/reference/internals/shards/#shard-compaction)。
+ 針對未來的寫入最佳化磁碟用量。
+ 刪除工作負載不需要的任何 InfluxDB 儲存貯體。InfluxDB 支援刪除。如果符合您的使用案例，您可以執行排定的清除。

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