Amazon Timestream for LiveAnalytics 可用性變更 - Amazon Timestream
替代服務評估

如需與 Amazon Timestream for LiveAnalytics 類似的功能，請考慮使用 Amazon Timestream for InfluxDB。它提供簡化的資料擷取和單一位數毫秒查詢回應時間，以進行即時分析。在這裡進一步了解。

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

Amazon Timestream for LiveAnalytics 可用性變更

由於時間序列應用程式具有獨特的需求和特性，我們提供廣泛的架構，協助您在深入了解特定實作詳細資訊之前評估各種替代方案。此高階指引是決策程序的基礎，後續章節將涵蓋更詳細的步驟和實際實作。

替代服務評估

適用於 InfluxDB 的 Amazon Timestream 的使用案例

如果您的 Timestream for LiveAnalytics 資料表基數少於 1，000 萬個 （系列索引鍵），則建議使用 Timestream for InfluxDB，這表示 的唯一組合，Amazon Timestream for LiveAnalytics 概念或者您可以將資料表基數減少至 1，000 萬個以下。 LiveAnalytics https://docs.influxdata.com/influxdb/v2/reference/key-concepts/data-elements/#series InfluxDB 的 Timestream 可讓您存取 InfluxDB 開放原始碼版本的功能。選擇此路徑可提供現有的時間序列功能，例如 Flux 提供的時間序列分析函數、任務 （相當於 排程查詢)，以及 Timestream for LiveAnalytics 提供的其他類似函數。InfluxDB 的 Timestream 也提供 InfluxQL （類似 SQL 的查詢語言） 與 InfluxDB 互動，以查詢和分析您的時間序列資料。

偏好使用 SQL 而非 InfluxQL

我們建議您實作 Amazon Aurora 或 RDS PostgreSQL。這些資料庫提供完整的 SQL 功能，同時提供有效的時間序列資料管理功能。時間序列分析可以使用可用的內建資料庫函數實作，或在應用程式層進行管理。

需要大規模的資料擷取 （超過每秒 100 萬筆記錄）

建議使用 Amazon DynamoDB 或其他 AWS NoSQL 資料庫。您可以根據您的特定應用程式需求選取這些資料庫。時間序列分析可以使用可用的內建資料庫函數實作，或在應用程式層進行管理。

在開始將資料遷移到所選的替代 AWS 服務之前，評估幾個關鍵因素將顯著影響遷移策略及其最終成功至關重要。這些評估將有助於塑造您的方法、識別潛在的挑戰，並確保在遷移過程中進行更順暢的轉換。

資料選擇和保留考量

透過定義確切的保留要求來評估您的資料遷移範圍。考慮是否需要遷移完整的歷史資料集、僅最近的資料 （例如過去 30、60 或 90 天） 或特定的時間序列資料區段。此決策應該由三個關鍵因素引導：法規合規要求、業務的分析需求，以及有關遷移複雜性和成本的實際考量。

查詢模式相容性分析

來源 (Timestream for LiveAnalytics) 與目標服務之間的查詢相容性需要徹底評估，因為時間序列資料庫會以不同的方式處理查詢語言和功能。進行全面測試，以識別系統之間的語法差異、功能差距和效能變化。測試所有業務關鍵查詢，或如果可能，您的應用程式所依賴的所有查詢，以確保它們在遷移後可正常運作且效能良好。

資料轉換規劃

在遷移之前，請密切注意結構描述映射，以確保來源和目標系統之間的資料一致性和結構一致性，以及專為時間序列資料量身打造的準確資料類型轉換。這些元件可共同運作，以確保資料品質、最佳化效能，並維護不同系統架構的功能。此外，請考慮任何專門的索引模式和系統特定的最佳化，以確保有效率的資料存取和擷取。

持續性和停機時間管理

由於資料遷移本質上會造成營運中斷，因此制定全面的切換策略對於成功至關重要。遷移計畫中要考慮的幾個最佳實務是：

  • 盡可能實作暫時平行處理系統，以維持業務連續性。

  • 在低流量期間排程遷移，例如週末或夜間。

  • 建立經過良好測試的轉返程序，以便在發生非預期問題時快速復原。