本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 效能效率支柱
AWS Well-Architected Framework [的效能效率支柱](https://docs.aws.amazon.com/wellarchitected/latest/framework/performance-efficiency.html)著重於如何在擷取或查詢資料時最佳化效能。效能最佳化是下列的增量和持續程序：
+ 確認業務需求
+ 測量工作負載效能
+ 識別效能不佳的元件
+ 調校元件以符合您的業務需求
效能效率支柱提供可協助您選擇高效能資料模型的指導方針。效能效率支柱包含查詢和寫入最佳化最佳實務。
效能效率支柱著重於下列關鍵領域：
+ 流入資料建模和查詢最佳化
+ 寫入最佳化
## 流入資料建模和查詢最佳化
設計有效的結構描述對於最佳化 InfluxDB 中時間序列資料的效能和查詢功能至關重要。從選擇正確的標籤和欄位開始。InfluxDB 索引標籤，因此查詢引擎不需要掃描測量中的每個記錄來尋找標籤值。這表示查詢標籤比查詢欄位更有效率。若要壓縮和存放資料，儲存引擎會依序列索引鍵將欄位值分組，然後依時間排序這些欄位值。系列索引鍵是由測量、標籤索引鍵和值，以及欄位索引鍵定義。如需資料設計的詳細資訊，請參閱 [InfluxDB 文件](https://docs.influxdata.com/influxdb/v2/reference/key-concepts/data-elements/)。
儲存引擎使用時間結構化合併樹狀結構 (TSM) 資料格式。如需 TSM 資料格式的詳細資訊，請參閱 [InfluxDB 文件](https://docs.influxdata.com/influxdb/v2/reference/internals/storage-engine/#time-structured-merge-tree-tsm)。
假設您正在收集資料 (`timestamp`、`host_id`、`region`、`cpu`、`memory``network_in_bytes`、`network_out_bytes`、`disk_io`) 作為 DevOps 使用案例的一部分。標籤，包括記錄時間戳記，提供內容以協助識別記錄的對象、內容、時間和位置。標籤用於組織和分類資料，並在查詢中篩選資料。
`host_id` 和 `region`標籤是組織和分類 DevOps 使用案例的理想標籤。這些資料欄有助於篩選特定主機的資料，或根據區域資料欄執行分析。
指標提供對資料執行數學計算 （例如運算總計、平均值和變化率差異） 和量化分析的基礎。因此，`cpu`、`memory`、`network_out_bytes`、 `network_in_bytes`和 會`disk_io`擷取與 DevOps 相關的重要指標，這些指標會隨著時間而變更。您可以使用這些指標來執行各種分析，例如計算不同主機的 CPU 和記憶體。您可以使用這些指標值來制定資料驅動型決策，以協助避免生產中斷和執行基礎設施規劃。
基數是唯一標籤值的組合。目標是盡可能降低基數，如果您的應用程式需要每個資料點的唯一識別符，請使用欄位值，而不是標籤值。這將產生明顯更佳的查詢延遲。良好的結構描述設計可以防止高序列基數，從而更好地執行查詢。如果您注意到資料讀取和寫入速度變慢，或想要了解基數如何影響效能，請參閱 [Timestream for InfluxDB 文件](https://docs.aws.amazon.com/timestream/latest/developerguide/timestream-for-influxdb.html#timestream-for-influx-getting-started-security-best-practices)。
如果您的應用程式發出 JSON 物件，請將它們轉換為個別資料欄 （標籤或欄位），並將資料欄載入 InfluxDB。InfluxDB 專為時間序列資料而設計，因此使用個別資料欄組織資料是充分利用服務功能的最佳實務。
單一 InfluxDB v2.7 OSS 執行個體支援在所有組織中主動寫入或查詢大約 20 個 InfluxDB 儲存貯體。超過 20 個儲存貯體可能會對效能造成負面影響。某些 InfluxDB 組態選項有限制，而且您可以根據使用案例設定一些選項。在測試階段根據應用程式工作負載驗證組態。資料保留是在儲存貯體層級設定，因此具有不同資料保留要求的資料應存放在不同的儲存貯體中。如需組態選項的詳細資訊，請參閱 [Timestream for InfluxDB 文件](https://docs.aws.amazon.com/timestream/latest/developerguide/timestream-for-influx-db-connecting.html#timestream-for-influx-parameter-groups)。
將資料儲存在標籤值或欄位值中，而不是標籤索引鍵、欄位索引鍵或度量中。如果您設計結構描述以將資料存放在標籤和欄位值中，您的查詢將更容易寫入且更有效率。如需資料建模的更多最佳實務，請參閱[設計效能](https://docs.aws.amazon.com/timestream/latest/developerguide/timestream-for-influxdb.html#timestream-for-influx-getting-started-security-best-practices-design-for-performance)。
使用 [InfluxDB 任務](https://docs.influxdata.com/influxdb/cloud/process-data/get-started/)預先彙總資料、將資料載入不同的測量或儲存貯體，並從中產生儀表板和視覺化資料。
InfluxDB OSS 公開端點`/metrics`[https://docs.influxdata.com/influxdb/v2/reference/internals/metrics/](https://docs.influxdata.com/influxdb/v2/reference/internals/metrics/)，傳回以** **Prometheus 純文字表達格式格式化的效能、資源和用量指標。使用 InfluxDB 範本來設定[監控和提醒](https://docs.influxdata.com/influxdb/v2/monitor-alert/templates/)，以主動偵測問題，例如高查詢延遲、寫入輸送量降級或資源用量尖峰。
InfluxDB 的 Timestream 提供 Influx IO 包含儲存。選取適當的 IOPS 大小可大幅加速查詢執行。這對於需要掃描大量資料或處理大量請求的查詢特別有用。在某些情況下，可能需要擴展執行個體和增強 IOPS 的組合，才能實現您想要的效能改善。
我們建議比對開發和生產環境 （執行個體類別、儲存類型、組態）。在移至生產環境之前，先測試每個版本的較低環境中的變更。在 Influx IO 包含儲存磁碟區上，InfluxDB 的 Timestream 提供三種儲存層，這些儲存層已預先設定最佳 IOPS (3，000、12，000、16，000) 和不同類型的工作負載所需的輸送量。大多數使用案例需要低於 3，000 IOPS。只有在效能測試指出需要高 IOPS 時，才選擇 12，000 或 16，000。如需詳細資訊，請參閱 Timestream for InfluxDB 文件中的[設定一節](https://docs.aws.amazon.com/timestream/latest/developerguide/timestream-for-influxdb.html#timestream-for-influx-dbi-setting-up)。
## 最佳化寫入
為了最佳化對 InfluxDB 的寫入，我們建議每次請求以 5，000 行的線路通訊協定批次寫入資料，以將網路額外負荷降至最低。為了獲得更好的效能，請在寫入資料點之前，依字彙順序依索引鍵排序標籤。使用時間戳記可能的最粗時間精確度，而不是奈秒，也可以改善效能。啟用 gzip 壓縮是加速寫入並降低網路頻寬的另一種方式。在您`telegraf.conf`檔案中的`influxdb_v2`輸出外掛程式組態中，將 `content_encoding`選項設定為 `gzip`。實作這些最佳化可以大幅提升將資料寫入 InfluxDB 的效能和效率。如需 InfluxDB 寫入最佳實務的詳細資訊，請參閱[最佳化 InfluxDB 的寫入](https://docs.influxdata.com/influxdb/v2/write-data/best-practices/optimize-writes/)。
InfluxDB 的寫入效能通常與可用的 IOPS 密切相關。寫入資料時，InfluxDB 需要執行大量 I/O 操作來存放資料。當您增加 IOPS 時，InfluxDB 每秒可以處理更多寫入。