如需與 Amazon Timestream for LiveAnalytics 類似的功能，請考慮使用 Amazon Timestream for InfluxDB。它提供簡化的資料擷取和單一位數毫秒查詢回應時間，以進行即時分析。[在這裡](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html)進一步了解。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# Amazon Timestream for LiveAnalytics 可用性變更
由於時間序列應用程式具有獨特的需求和特性，我們提供廣泛的架構，協助您在深入了解特定實作詳細資訊之前評估各種替代方案。此高階指引是決策程序的基礎，後續章節將涵蓋更詳細的步驟和實際實作。
## 替代服務評估
**適用於 InfluxDB 的 Amazon Timestream 的使用案例**
如果您的 Timestream for LiveAnalytics 資料表基數少於 1，000 萬個 ([系列金鑰](https://docs.influxdata.com/influxdb/v2/reference/key-concepts/data-elements/#series))，則建議使用 [Timestream for InfluxDB](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html)，這表示 的唯一組合，[Amazon Timestream for LiveAnalytics 概念](concepts.md)或者您可以將資料表基數減少至 1，000 萬個以下。InfluxDB 的 Timestream 可讓您存取 InfluxDB 開放原始碼版本的功能。選擇此路徑可提供現有的時間序列功能，例如 [Flux](https://docs.influxdata.com/influxdb/v2/query-data/flux/) 提供的時間序列分析函數、任務 （相當於 [排程查詢](scheduled-query.md))，以及 Timestream for LiveAnalytics 提供的其他類似函數。InfluxDB 的 Timestream 也提供 [InfluxQL](https://docs.influxdata.com/influxdb/v2/query-data/influxql/) （類似 SQL 的查詢語言） 與 InfluxDB 互動，以查詢和分析您的時間序列資料。
**偏好使用 SQL 而非 InfluxQL**
我們建議您實作 Amazon Aurora 或 RDS PostgreSQL。這些資料庫提供完整的 SQL 功能，同時提供有效的[時間序列資料管理](https://docs.aws.amazon.com//AmazonRDS/latest/UserGuide/PostgreSQL_Partitions.html)功能。時間序列分析可以使用可用的內建資料庫函數實作，或在應用程式層進行管理。
**需要大規模的資料擷取 （超過每秒 100 萬筆記錄）**
建議使用 Amazon DynamoDB 或其他 AWS [NoSQL](https://aws.amazon.com/nosql/) 資料庫。您可以根據您的特定應用程式需求選取這些資料庫。時間序列分析可以使用可用的內建資料庫函數實作，或在應用程式層進行管理。
在開始將資料遷移到選擇的替代 AWS 服務之前，評估幾個關鍵因素將顯著影響遷移策略及其最終成功至關重要。這些評估將有助於塑造您的方法、識別潛在的挑戰，並確保在遷移過程中進行更順暢的轉換。
**資料選擇和保留考量**
透過定義確切的保留要求來評估您的資料遷移範圍。考慮是否需要遷移完整的歷史資料集、僅最近的資料 （例如過去 30、60 或 90 天） 或特定的時間序列資料區段。此決策應該由三個關鍵因素引導：法規合規要求、業務的分析需求，以及有關遷移複雜性和成本的實際考量。
**查詢模式相容性分析**
來源 (Timestream for LiveAnalytics) 與目標服務之間的查詢相容性需要徹底評估，因為時間序列資料庫處理查詢語言和功能的方式不同。進行全面測試，以識別系統之間的語法差異、功能差距和效能變化。測試所有業務關鍵查詢，或可能的話，您的應用程式所依賴的所有查詢，以確保它們在遷移後可正常運作且效能良好。
**資料轉換規劃**
在遷移之前，請密切注意結構描述映射，以確保來源和目標系統之間的資料一致性和結構一致性，以及專為時間序列資料量身打造的準確資料類型轉換。這些元件可共同運作，以確保資料品質、最佳化效能，並維護不同系統架構的功能。此外，請考慮任何專門的索引模式和系統特定的最佳化，以確保有效率的資料存取和擷取。
**持續性和停機時間管理**
由於資料遷移本質上會造成營運中斷，因此制定全面的切換策略對於成功至關重要。遷移計畫中要考慮的幾個最佳實務，可將停機時間降至最低：
+ 盡可能實作暫時平行處理系統，以維持業務連續性。
+ 在低流量期間排程遷移，例如週末或夜間。
+ 建立經過良好測試的轉返程序，以便在發生非預期問題時快速復原。