如需與 Amazon Timestream for LiveAnalytics 類似的功能，請考慮使用 Amazon Timestream for InfluxDB。它提供簡化的資料擷取和單一位數毫秒查詢回應時間，以進行即時分析。[在這裡](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html)進一步了解。 本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 建立資料模型 Amazon Timestream for LiveAnalytics 旨在從應用程式和裝置收集、存放和分析具有時間戳記的一系列資料。為了獲得最佳效能，傳送至 Timestream for LiveAnalytics 的資料必須具有時間特性，且時間必須是資料的基本元件。 Timestream for LiveAnalytics 可讓您彈性地以不同的方式建立資料模型，以符合應用程式的需求。在本節中，我們涵蓋多種模式，並提供指導方針，讓您最佳化成本和效能。熟悉 索引鍵，[Amazon Timestream for LiveAnalytics 概念](concepts.md)例如維度和量值。在本節中，您將在決定是否建立單一資料表或多個資料表來存放資料時，進一步了解下列事項： + 當您想要跨多個資料表和資料庫分隔資料時，要放在相同資料表中的資料與 。 + 與單一度量記錄相比，如何在 Timestream for LiveAnalytics 多重度量記錄之間進行選擇，以及使用多重度量記錄建立模型的好處，特別是當您的應用程式同時追蹤多個度量時。 + 要建模為維度或量值的屬性。 + 如何有效地使用度量名稱屬性來最佳化查詢延遲。 **Topics** + [單一資料表與多個資料表](#data-modeling-singleVmultitable) + [多度量記錄與單一度量記錄](#data-modeling-multiVsinglerecords) + [維度和量值](#data-modeling-dimensionsmeasures) + [搭配多度量記錄使用度量名稱](#data-modeling-measurenamemulti) + [分割多度量記錄的建議](#data-modeling-multi-measure-partitioning) ## 單一資料表與多個資料表 當您在應用程式中建立資料模型時，另一個重要的層面是如何將資料建模為資料表和資料庫。Timestream for LiveAnalytics 中的資料庫和資料表是存取控制的抽象概念，指定 KMS 金鑰、保留期間等。LiveAnalytics 的 Timestream 會自動分割您的資料，旨在擴展資源以符合應用程式的擷取、儲存和查詢負載和需求。 Timestream for LiveAnalytics 中的資料表可以擴展至儲存的 PB 資料，以及每秒數十 GB 的資料寫入。查詢每小時可以處理數百 TB。Timestream for LiveAnalytics 中的查詢可以跨越多個資料表和資料庫，提供聯結和聯集，以跨多個資料表和資料庫無縫存取您的資料。因此，決定如何在 Timestream for LiveAnalytics 中組織資料時，資料或請求磁碟區規模通常不是主要考量。以下是決定要與不同資料表或不同資料庫中的資料表共同放置哪些資料時的一些重要考量。 + 資料表的精細程度支援資料保留政策 （記憶體存放區保留、磁性存放區保留等）。因此，需要不同保留政策的資料必須位於不同的資料表中。 + AWS KMS 用於加密資料的金鑰是在資料庫層級設定。因此，不同的加密金鑰需求表示資料需要位於不同的資料庫中。 + Timestream for LiveAnalytics 支援資料表和資料庫精細程度的資源型存取控制。決定寫入相同資料表與不同資料表的資料時，請考慮您的存取控制需求。 + 在決定要存放在哪個資料表中的資料時，請注意維度、度量名稱和多度量屬性名稱[的限制](https://docs.aws.amazon.com/timestream/latest/developerguide/ts-limits.html)。 + 在決定如何組織資料時，請考慮您的查詢工作負載和存取模式，因為查詢延遲和撰寫查詢的難易度取決於此。 + 如果您將經常查詢的資料儲存在相同的資料表中，這通常會簡化您撰寫查詢的方式，因此您通常可以避免撰寫聯結、聯集或常見資料表表達式。這通常也會降低查詢延遲。您可以在維度和度量名稱上使用述詞來篩選與查詢相關的資料。 例如，假設您從位於六大洲的裝置存放資料。如果您的查詢經常從各洲存取資料以取得全域彙總檢視，則將來自這些洲的資料儲存在相同資料表中將更容易寫入查詢。另一方面，如果您將資料存放在不同的資料表上，您仍然可以在相同的查詢中結合資料，不過，您將需要撰寫查詢來跨資料表將資料聯集。 + LiveAnalytics 的 Timestream 會在您的資料上使用自適應分割和索引，因此查詢只會針對與您的查詢相關的資料收費。例如，如果您有一個資料表存放來自六大洲上百萬個裝置的資料，如果您的查詢具有 `WHERE device_id = 'abcdef'`或 的述詞`WHERE continent = 'North America'`，則查詢只會針對裝置或 大洲的資料收費。 + 在可能的情況下，如果您使用度量名稱來分隔相同資料表中未同時發出或未經常查詢的資料，則使用查詢`WHERE measure_name = 'cpu'`中的 等述詞，不僅可以獲得計量優勢，Timestream for LiveAnalytics 還可以有效地消除沒有查詢述詞中使用的度量名稱的分割區。這可讓您將具有不同度量名稱的相關資料存放在相同資料表中，而不會影響查詢延遲或成本，並避免將資料分散到多個資料表。量值名稱基本上用於分割資料，以及刪除與查詢無關的分割區。 ## 多度量記錄與單一度量記錄 LiveAnalytics 的 Timestream 可讓您寫入每個記錄具有多個度量的資料 （多度量） 或每個記錄具有單一度量的資料 （單一度量）。 **多度量記錄** 在許多使用案例中，您要追蹤的裝置或應用程式可能會同時發出多個指標或事件。在這種情況下，您可以將相同時間戳記發出的所有指標存放在相同的多度量記錄中。也就是說，儲存在相同多度量記錄中的所有度量都會在相同資料列中顯示為不同的資料欄。 例如，假設您的應用程式正在從同時即時測量的裝置發出指標，例如 cpu、記憶體和 disk\$1iops。以下是此類資料表的範例，其中同時發出的多個指標會儲存在相同的資料列中。您將看到兩個主機每秒發出一次指標。 | Hostname (主機名稱) | measure\$1name | 時間 | cpu | 記憶體 | disk\$1iops | | --- | --- | --- | --- | --- | --- | | host-24Gju | 指標 | 2021-12-01 19：00：00 | 35 | 54.9 | 38.2 | | host-24Gju | 指標 | 2021-12-01 19：00：01 | 36 | 58 | 39 | | host-28Gju | 指標 | 2021-12-01 19：00：00 | 15 | 55 | 92 | | host-28Gju | 指標 | 2021-12-01 19：00：01 | 16 | 50 | 40 | **單一度量記錄** 當您的裝置在不同時段發出不同的指標，或您使用自訂處理邏輯在不同時段發出指標/事件時 （例如，當裝置的讀取/狀態變更時），單一度量記錄是合適的。由於每個量值都有唯一的時間戳記，因此可以在 Timestream for LiveAnalytics 中將量值存放在自己的記錄中。例如，假設 IoT 感應器會追蹤土壤溫度和濕度，只有在偵測到先前回報項目的變更時才會發出記錄。下列範例提供使用單一量值記錄發出此類資料的範例。 | device\$1id | measure\$1name | 時間 | measure\$1value::double | measure\$1value::bigint | | --- | --- | --- | --- | --- | | sensor-sea478 | 溫度 | 2021-12-01 19：22：32 | 35 | NULL | | sensor-sea478 | 溫度 | 2021-12-01 18：07：51 | 36 | NULL | | sensor-sea478 | 濕度 | 2021-12-01 19：05：30 | NULL | 21 | | sensor-sea478 | 濕度 | 2021-12-01 19：00：01 | NULL | 23 | **比較單一度量和多度量記錄** Timestream for LiveAnalytics 可讓您根據應用程式的需求和特性，靈活地將資料建模為單一度量或多度量記錄。如果您的應用程式需要，單一資料表可以同時儲存單一測量和多重測量記錄。一般而言，當您的應用程式同時發出多個度量/事件時，通常建議將資料建模為多度量記錄，以用於效能資料存取和符合成本效益的資料儲存。 例如，如果您考慮 [DevOps 使用案例追蹤指標和](https://github.com/awslabs/amazon-timestream-tools/tree/mainline/tools/python/perf-scale-workload)來自數十萬個伺服器的事件，每個伺服器會定期發出 20 個指標和 5 個事件，其中事件和指標會同時即時發出。該資料可以使用單一度量記錄或使用多度量記錄建立模型 （請參閱[開放原始碼資料產生器](https://github.com/awslabs/amazon-timestream-tools/tree/mainline/tools/python/perf-scale-workload)以取得產生的結構描述）。在此使用案例中，使用多度量記錄與單一度量記錄建立資料的模型會導致： + *擷取計量* - 多度量記錄會導致寫入*的擷取位元組減少約 40%*。 + *擷取批次處理* - 多度量記錄會導致傳送的資料批次較大，這表示用戶端需要較少的執行緒和較少的 CPU 來處理擷取。 + *儲存計量* - 多度量記錄可*降低約 8X的儲存*體，大幅節省記憶體和磁性儲存體的儲存體。 + *查詢延遲* - 與單一度量記錄相比，多度量記錄會導致大多數查詢類型的查詢延遲較低。 + *查詢計量位元組* - 對於掃描小於 10 MB 資料的查詢，單一測量和多重測量記錄都是相當的。對於存取單一量值和掃描 > 10 MB 資料的查詢，單一量值記錄通常會產生較低的位元組計量。對於參考三個或更多度量的查詢，多度量記錄會產生較低的位元組計量。 + *易於表達多度量查詢* - 當您的查詢參考多個度量時，使用多度量記錄建立資料模型會導致更易於寫入和更精簡的查詢。 先前的因素會根據您追蹤的指標數量、資料擁有的維度等而有所不同。雖然上述範例提供一個範例的一些具體資料，但我們在許多應用程式案例和使用案例中看到 ，如果應用程式同時發出多個度量，則將資料儲存為多度量記錄會更有效率。此外，多度量記錄可為您提供資料類型的彈性，並將多個其他值儲存為內容 （例如，儲存請求 IDs 和其他時間戳記，稍後會討論）。 請注意，多度量記錄也可以建立稀疏度量的模型，例如先前的單一度量記錄範例：您可以使用 `measure_name` 來存放度量名稱，並使用一般多度量屬性名稱，例如`value_double`存放`DOUBLE`度量、`value_bigint`存放`BIGINT`度量、`value_timestamp`存放其他`TIMESTAMP`值等。 ## 維度和量值 Timestream for LiveAnalytics 中的資料表可讓您存放*維度* （識別您要存放之裝置/資料的屬性） 和*量*值 （您正在追蹤的指標/值）；如需詳細資訊[Amazon Timestream for LiveAnalytics 概念](concepts.md)，請參閱 。當您在 Timestream for LiveAnalytics 上建立應用程式模型時，將資料映射到維度和度量的方式會影響您的擷取和查詢延遲。以下是如何將資料建模為適用於使用案例的維度和措施的指導方針。 **選擇維度** 識別傳送時間序列資料之來源的資料是維度的自然擬合，這些維度是不會隨時間變更的屬性。例如，如果您有伺服器發出指標，則識別伺服器的屬性，例如主機名稱、區域、機架和可用區域，都是維度的候選項目。同樣地，對於具有多個感應器回報時間序列資料的 IoT 裝置，裝置 ID 和感應器 ID 等屬性是維度的候選項目。 如果您要將資料寫入為多度量記錄，當您在資料表上執行 `DESCRIBE`或執行 `SELECT` 陳述式時，維度和多度量屬性會在資料表中顯示為資料欄。因此，撰寫查詢時，您可以在相同的查詢中自由使用維度和量值。不過，當您建構寫入記錄以擷取資料時，當您選擇哪些屬性指定為維度，以及哪些屬性指定為度量值時，請謹記下列事項： + 維度名稱、維度值、度量名稱和時間戳記可唯一識別時間序列資料。LiveAnalytics 的 Timestream 使用此唯一識別符自動刪除重複資料。也就是說，如果 Timestream for LiveAnalytics 收到兩個具有相同維度名稱、維度值、度量名稱和時間戳記值的資料點，且值具有相同的版本編號，則 Timestream for LiveAnalytics 會取消重複。如果新的寫入請求版本低於 Timestream for LiveAnalytics 中已存在的資料，則會拒絕寫入請求。如果新的寫入請求具有較高的版本，則新值會覆寫舊值。因此，您選擇維度值的方式會影響此重複資料刪除行為。 + 維度名稱和值無法更新，但度量值可以更新。因此，任何可能需要更新的資料，都會以更好的模型做為度量值。例如，如果您的機器位於工廠樓層，其顏色可以變更，則可以將顏色建模為度量值，除非您也想要將顏色用作去重複所需的識別屬性。也就是說，度量值可用來存放屬性，這些屬性只會隨著時間緩慢變更。 請注意，Timestream for LiveAnalytics 中的資料表不會限制維度名稱和值的唯一組合數量。例如，您可以在資料表中存放數十億個這類唯一值組合。不過，如以下範例所示，仔細選擇維度和量值可以大幅最佳化您的請求延遲，尤其是查詢。 **維度中的唯一 IDs ** 如果您的應用程式案例需要您為每個資料點存放唯一識別符 （例如，請求 ID、交易 ID 或關聯 ID)，則將 ID 屬性建模為度量值將可大幅改善查詢延遲。使用多度量記錄建立資料模型時，ID 會與您的其他維度和時間序列資料顯示在相同的資料列中，因此您的查詢可以繼續使用它們。例如，考慮 [DevOps 使用案例](https://github.com/awslabs/amazon-timestream-tools/tree/mainline/tools/python/perf-scale-workload)，其中伺服器發出的每個資料點都有唯一的請求 ID 屬性，將請求 ID 建模為度量值會導致不同查詢類型的查詢延遲降低高達 4 倍，而不是將唯一請求 ID 建模為維度。 您可以對不是每個資料點完全唯一的屬性使用類似的比喻，但具有數十萬或數百萬個唯一值。您可以將這些屬性建模為維度或度量值。如果先前討論的寫入路徑上需要重複的值，或者您經常在查詢中使用它做為述詞 （例如，在 `WHERE`子句中，具有該屬性值的等式述詞，例如您的應用程式正在追蹤數百萬個裝置`device_id = 'abcde'`的位置），則您想要將其建模為維度。 **具有多度量記錄的資料類型的豐富度** 多度量記錄可讓您靈活地有效地建立資料模型。您在多度量記錄中存放的資料會在表格中顯示為類似於維度的資料欄，因此可同樣輕鬆地查詢維度和度量值。您在先前討論的範例中看到其中一些模式。您可以在下面找到其他模式，以有效使用多度量記錄來滿足應用程式的使用案例。 多度量記錄支援資料類型 `DOUBLE`、`BIGINT`、`BOOLEAN`、 `VARCHAR`和 的屬性`TIMESTAMP`。因此，它們自然適合不同類型的屬性： + *位置資訊*：例如，如果您想要追蹤位置 （以緯度和經度表示），則將其建模為多度量屬性會導致查詢延遲低於將它們儲存為`VARCHAR`維度，特別是當您在緯度和經度上有述詞時。 + *記錄中的多個時間戳記*：如果您的應用程式案例要求您追蹤時間序列記錄的多個時間戳記，您可以將它們建模為多度量記錄中的其他屬性。此模式可用來存放具有未來時間戳記或過去時間戳記的資料。請注意，每個記錄仍會使用時間欄中的時間戳記來分割、編製索引和唯一識別記錄。 特別是，如果您在查詢中具有述詞的數值資料或時間戳記，將這些屬性建模為多度量屬性，而不是維度，將導致較低的查詢延遲。這是因為當您使用多度量記錄中支援的豐富資料類型來建立此類資料的模型時，您可以使用原生資料類型來表達述詞，而不必在將此類資料建模為維度時將值從 轉換為`VARCHAR`其他資料類型。 ## 搭配多度量記錄使用度量名稱 Timestream for LiveAnalytics 中的資料表支援稱為*度量名稱*的特殊屬性 （或資料欄）。您可以為寫入 Timestream for LiveAnalytics 的每個記錄指定此屬性的值。對於單一度量記錄，自然會使用指標的名稱 （例如伺服器指標的 CPU 或記憶體，或感應器指標的溫度或壓力）。使用多度量記錄時，多度量記錄中的屬性會命名，這些名稱會成為資料表中的資料欄名稱。因此，cpu、記憶體、溫度和壓力可能會成為多度量屬性名稱。自然問題是如何有效地使用度量名稱。 LiveAnalytics 的 Timestream 使用量值名稱屬性中的值來分割和索引資料。因此，如果資料表有多個不同的度量名稱，而且如果查詢使用這些值做為查詢述詞，則 LiveAnalytics 的 Timestream 可以使用其自訂分割和索引來剔除與查詢無關的資料。例如，如果您的資料表具有 `cpu`和 `memory` 度量名稱，且您的查詢具有述詞 `WHERE measure_name = 'cpu'`，則 LiveAnalytics 的 Timestream 可以有效地刪除與查詢無關的度量名稱的資料，例如，此範例中具有度量名稱記憶體的資料列。即使將度量名稱與多度量記錄搭配使用，也會套用此剔除。您可以有效地使用量值名稱屬性做為資料表的分割屬性。測量名稱以及維度名稱和值，以及時間用於分割 Timestream for LiveAnalytics 資料表中的資料。請注意 Timestream for LiveAnalytics 資料表中允許的唯一度量名稱數量[限制](https://docs.aws.amazon.com/timestream/latest/developerguide/ts-limits.html)。另請注意，度量名稱也與度量值資料類型相關聯。例如，單一量值名稱只能與一種量值類型相關聯。該類型可以是 `DOUBLE`、`BIGINT`、`VARCHAR`、 `BOOLEAN`或 之一`MULTI`。使用度量名稱存放的多度量記錄將具有 的資料類型`MULTI`。由於單一多度量記錄可以存放具有不同資料類型 (`DOUBLE`、`BIGINT`、`VARCHAR`、 和 `TIMESTAMP`) 的多個指標`BOOLEAN`，因此您可以在多度量記錄中關聯不同類型的資料。 下列各節說明幾個不同的範例，說明如何有效地使用量值名稱屬性，將相同資料表中不同類型的資料分組在一起。 **IoT 感應器報告品質和價值** 假設您有一個來自 IoT 感應器的應用程式監控資料。每個感應器都會追蹤不同的量值，例如溫度和壓力。除了實際值之外，感應器還會報告測量的品質，這是測量讀數準確度的指標，以及測量的單位。由於品質、單位和值會一起發出，因此它們可以建模為多度量記錄，如以下範例資料所示，其中 `device_id`是維度，而 `quality`、 `value`和 `unit`是多度量屬性： | device\$1id | measure\$1name | 時間 | 品質 | Value | 單位 | | --- | --- | --- | --- | --- | --- | | sensor-sea478 | 溫度 | 2021-12-01 19：22：32 | 92 | 35 | c | | sensor-sea478 | 溫度 | 2021-12-01 18：07：51 | 93 | 34 | c | | sensor-sea478 | pressure | 2021-12-01 19：05：30 | 98 | 31 | psi | | sensor-sea478 | pressure | 2021-12-01 19：00：01 | 24 | 132 | psi | 此方法可讓您使用度量名稱的值，結合多度量記錄的優點，以及分割和刪除資料。如果查詢參考單一量值，例如溫度，則您可以在查詢中包含`measure_name`述詞。以下是此類查詢的範例，該查詢也會針對品質高於 90 的測量投影單位。 ``` SELECT device_id, time, value AS temperature, unit FROM db.table WHERE time > ago(1h) AND measure_name = 'temperature' AND quality > 90 ``` 在查詢上使用 `measure_name` 述詞可讓 Timestream for LiveAnalytics 有效地刪除與查詢無關的分割區和資料，從而改善您的查詢延遲。 如果在同一時間戳記發出所有指標和/或在同一個查詢中同時查詢多個指標，也可以將所有指標存放在相同的多度量記錄中。例如，您可以建構具有諸如 temperature\$1quality、tempor\$1value、tempor\$1unit、 pressure\$1quality、 pressure\$1value 和 pressure\$1unit 等屬性的多度量記錄。您決定如何建立資料的模型時，會套用有關使用單一度量與多重度量記錄建立資料的許多討論重點。請考慮您的查詢存取模式以及資料的產生方式，以選擇可最佳化成本、擷取和查詢延遲，以及輕鬆撰寫查詢的模型。 **相同資料表中的不同指標類型** 另一個您可以結合多度量記錄與度量名稱值的使用案例，是建立從相同裝置獨立發出的不同資料類型的模型。請考慮 DevOps 監控使用案例，其中伺服器會發出兩種類型的資料：定期發出指標和不規則事件。此方法的範例是[建立 DevOps 使用案例模型的資料產生器](https://github.com/awslabs/amazon-timestream-tools/tree/mainline/tools/python/perf-scale-workload)中所討論的結構描述。在此情況下，您可以使用不同的度量名稱，將從相同伺服器發出的不同資料類型存放在相同資料表中。例如，同時發出的所有指標都會與量值名稱指標一起存放。所有在與指標不同時間立即發出的事件，都會與量值名稱事件一起存放。資料表的量值結構描述 （例如`SHOW MEASURES`查詢的輸出） 為： | measure\$1name | data\$1type | 維度 | | --- | --- | --- | | events | 多重 | 【\$1"data\$1type"："varchar"，"dimension\$1name"："availability\$1zone"\$1，\$1"data\$1type"："varchar"，"dimension\$1name"："microservice\$1name"\$1，\$1"data\$1type"："varchar"，"dimension\$1name"："instance\$1name"\$1，\$1"data\$1type"："varchar"，"dimension\$1name"："process\$1name"\$1，\$1"data\$1type"："varchar"，"dimension\$1name"："jdk\$1version"\$1，\$1"data\$1type"："varchar"，"dimension\$1name"：" | | 指標 | 多重 | 【\$1"data\$1type"："varchar"，"dimension\$1name"："availability\$1zone"\$1，\$1"data\$1type"："varchar"，"dimension\$1name"："microservice\$1name"\$1，\$1"data\$1type"："varchar"，"dimension\$1name"："instance\$1name"\$1，\$1"data\$1type"："varchar"，"dimension\$1name"："os\$1version"\$1，\$1"data\$1type"："varchar"，"dimension\$1name"："cell"\$1，\$1"data\$1type"："varchar"，"dimension\$1name""："" | 在這種情況下，您可以看到事件和指標也有不同的維度集，其中事件具有不同的維度`jdk_version`，`process_name`而指標具有維度 `instance_type`和 `os_version`。 使用不同的量值名稱可讓您使用述詞撰寫查詢`WHERE measure_name = 'metrics'`，例如只取得指標。同時，從相同資料表中的相同執行個體發出所有資料，表示您也可以使用`instance_name`述詞撰寫更簡單的查詢，以取得該執行個體的所有資料。例如，`WHERE instance_name = 'instance-1234'`沒有述詞的表單`measure_name`述詞將傳回特定伺服器執行個體的所有資料。 ## 分割多度量記錄的建議 **重要** **本節已棄用！** 這些建議已過期。現在可以使用[客戶定義的分割區索引鍵更好地控制分割區](customer-defined-partition-keys.md)。 我們看到時間序列生態系統中的工作負載數量不斷增加，需要擷取和儲存大量資料，同時在透過高基數維度組值存取資料時需要低延遲查詢回應。 由於這種特性，本節中的建議對於具有下列內容的客戶工作負載很有用： + 採用或想要採用多度量記錄。 + 預期有大量資料傳入系統會長期儲存。 + 主要存取 （查詢） 模式需要低延遲回應時間。 + 了解最重要的查詢模式涉及述詞中某種篩選條件。此篩選條件是以高基數維度為基礎。例如，考慮依 UserId、DeviceId、ServerID、host-name 等的事件或彙總。 在這些情況下，所有多度量測量的單一名稱將沒有幫助，因為我們的引擎使用多度量名稱來分割資料，並且具有單一值會限制您取得的分割區優勢。這些記錄的分割主要是根據兩個維度。假設時間在 x 軸上，以及維度名稱的雜湊，而 `measure_name`是在 y 軸上。`measure_name` 在這些情況下， 的運作方式幾乎與分割金鑰類似。 我們的建議如下： + 為類似我們提及的使用案例建立資料模型時，請使用`measure_name`直接衍生主要查詢存取模式的 。例如： + 您的使用案例需要從最終使用者的觀點追蹤應用程式效能和 QoE。這也可能是追蹤單一伺服器或 IoT 裝置的測量。 + 如果您要依 UserId 查詢和篩選，則需要在擷取時間找到`measure_name`與 UserId 建立關聯的最佳方法。 + 由於多度量資料表只能保留 8，192 個不同的度量名稱，因此採用的任何公式都不應產生超過 8，192 個不同的值。 + 我們成功套用字串值的一個方法是將雜湊演算法套用至字串值。然後使用雜湊結果的絕對值和 8，192 來執行模數操作。 ``` measure_name = getMeasureName(UserId) int getMeasureName(value) { hash_value = abs(hash(value)) return hash_value % 8192 } ``` + 我們也新增了 `abs()` 以移除符號，消除了值從 -8，192 到 8，192 的可能性。這應該在模數操作之前執行。 + 透過使用此方法，您的查詢可以在未分割資料模型上執行所需的一小部分時間上執行。 + 查詢資料時，請確定您在使用 新衍生值的述詞中包含篩選條件`measure_name`。例如： + ``` SELECT * FROM your_database.your_table WHERE host_name = 'Host-1235' time BETWEEN '2022-09-01' AND '2022-09-18' AND measure_name = (SELECT cast(abs(from_big_endian_64(xxhash64(CAST('HOST-1235' AS varbinary))))%8192 AS varchar)) ``` + 這將最大限度地減少掃描的分割區總數，以取得資料，以隨著時間的推移更快地轉換查詢。 請注意，如果您想要從此分割區結構描述中取得優勢，則需要在用戶端計算雜湊，並將雜湊傳遞給 Timestream for LiveAnalytics 做為查詢引擎的靜態值。上述範例提供一種方法來驗證產生的雜湊是否可以在需要時由引擎解決。 | time | host\$1name | location | server\$1type | cpu\$1usage | available\$1memory | cpu\$1temp | | --- | --- | --- | --- | --- | --- | --- | | 2022-09-07 21：48：44 .000000000 | 主機 1235 | us-east1 | 5.8xl | 55 | 16.2 | 78 | | R2022-09-07 21：48：44 .000000000 | host-3587 | us-west1 | 5.8xl | 62 | 18.1 | 81 | | 2022-09-07 21：48：45.000000000 | host-258743 | eu-central | 5.8xl | 88 | 9.4 | 91 | | 2022-09-07 21：48：45 .000000000 | host-35654 | us-east2 | 5.8xl | 29 | 24 | 54 | | R2022-09-07 21：48：45 .000000000 | host-254 | us-west1 | 5.8xl | 44 | 32 | 48 | 若要`measure_name`依照我們的建議產生相關聯的 ，有兩個路徑取決於您的擷取模式。 1. *對於歷史資料的批次擷取*—如果您將自己的程式碼用於批次程序，您可以將轉換新增至您的寫入程式碼。 在上述範例之上建置 。 ``` List hosts = new ArrayList<>(); hosts.add("host-1235"); hosts.add("host-3587"); hosts.add("host-258743"); hosts.add("host-35654"); hosts.add("host-254"); for (String h: hosts){ ByteBuffer buf2 = ByteBuffer.wrap(h.getBytes()); partition = abs(hasher.hash(buf2, 0L)) % 8192; System.out.println(h + " - " + partition); } ``` Output ``` host-1235 - 6445 host-3587 - 6399 host-258743 - 640 host-35654 - 2093 host-254 - 7051 ``` 產生的資料集 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/timestream/latest/developerguide/data-modeling.html) 1. *對於即時擷取* - 您需要在資料傳入時產生傳輸`measure_name`中。 在這兩種情況下，我們建議您測試兩端的雜湊產生演算法 （擷取和查詢），以確保您獲得相同的結果。 以下是根據 產生雜湊值的一些程式碼範例`host_name`。 **Example Python** ``` >>> import xxhash >>> from bitstring import BitArray >>> b=xxhash.xxh64('HOST-ID-1235').digest() >>> BitArray(b).int % 8192 ### 3195 ``` **Example Go** ``` package main import ( "bytes" "fmt" "github.com/cespare/xxhash" ) func main() { buf := bytes.NewBufferString("HOST-ID-1235") x := xxhash.New() x.Write(buf.Bytes()) // convert unsigned integer to signed integer before taking mod fmt.Printf("%f\n", abs(int64(x.Sum64())) % 8192) } func abs(x int64) int64 { if (x < 0) { return -x } return x } ``` **Example Java** ``` import java.nio.ByteBuffer; import net.jpountz.xxhash.XXHash64; public class test { public static void main(String[] args) { XXHash64 hasher = net.jpountz.xxhash.XXHashFactory.fastestInstance().hash64(); String host = "HOST-ID-1235"; ByteBuffer buf = ByteBuffer.wrap(host.getBytes()); Long result = Math.abs(hasher.hash(buf, 0L)); Long partition = result % 8192; System.out.println(result); System.out.println(partition); } } ``` **Example Maven 中的相依性** ``` net.jpountz.lz4 lz4 1.3.0 ```