Amazon Timestream for LiveAnalytics の可用性の変更 - Amazon Timestream

Amazon Timestream for LiveAnalytics は、2025 年 6 月 20 日以降、新規のお客様に公開されなくなります。LiveAnalytics に Amazon Timestream を使用する場合は、その日付より前にサインアップします。既存のお客様は、通常どおりサービスを引き続き使用できます。詳細については、「Amazon Timestream for LiveAnalytics の可用性の変更」を参照してください。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon Timestream for LiveAnalytics の可用性の変更

時系列アプリケーションには固有の要件と特性があるため、特定の実装の詳細を調べる前にさまざまな代替案を評価するのに役立つ幅広いフレームワークを提供しています。この大まかなガイダンスは、意思決定プロセスの基盤として機能します。より詳細な手順と実践的な実装については、以降のセクションで説明します。

代替サービスの評価

ユースケースは InfluxDB の Amazon Timestream に適合

Timestream for LiveAnalytics テーブルのカーディナリティ (シリーズキー) が 1,000 万未満の場合、またはテーブルのカーディナリティを 1,000 万未満に減らすことができる場合は、InfluxDB の Timestream をお勧めします。 LiveAnalytics https://docs.influxdata.com/influxdb/v2/reference/key-concepts/data-elements/#series Amazon Timestream for LiveAnalytics の概念 InfluxDB の Timestream では、InfluxDB のオープンソースバージョンの機能にアクセスできます。このパスを選択すると、Flux が提供する時系列分析関数、タスク ( に相当スケジュールされたクエリ)、Timestream for LiveAnalytics が提供するその他の同様の関数など、既存の時系列機能が提供されます。InfluxDB の Timestream は、時系列データのクエリと分析のために InfluxDB とやり取りするための InfluxQL (SQL のようなクエリ言語) も提供します。 InfluxDB

InfluxQL の代わりに SQL を使用する

Amazon Aurora または RDS PostgreSQL を実装することをお勧めします。これらのデータベースは、完全な SQL 機能を提供しながら、効果的な時系列データ管理機能を提供します。時系列分析は、使用可能な場合は組み込みデータベース関数を使用して実装することも、アプリケーションレイヤーで管理することもできます。

大規模なデータ取り込みが必要 (1 秒あたり 100 万レコードを超える)

Amazon DynamoDB または他の AWS NoSQL データベースを使用することをお勧めします。これらのデータベースは、特定のアプリケーションのニーズに基づいて選択できます。時系列分析は、使用可能な場合は組み込みデータベース関数を使用して実装することも、アプリケーションレイヤーで管理することもできます。

選択した代替 AWS サービスへのデータ移行を開始する前に、移行戦略とその最終的な成功に大きな影響を与えるいくつかの重要な要素を評価することが重要です。これらの評価は、アプローチの形成、潜在的な課題の特定、移行プロセス中の移行の円滑化に役立ちます。

データの選択と保持に関する考慮事項

正確な保持要件を定義して、データ移行の範囲を評価します。完全な履歴データセット、最近のデータのみ (過去 30、60、90 日間など)、または特定の時系列データセグメントを移行する必要があるかどうかを検討してください。この決定は、規制コンプライアンス要件、ビジネスの分析ニーズ、移行の複雑さとコストに関する実用的な考慮事項の 3 つの主要な要因に基づいて行う必要があります。

クエリパターンの互換性分析

ソース (Timestream for LiveAnalytics) とターゲットサービス間のクエリの互換性には、時系列データベースによるクエリ言語と機能の処理が異なるため、徹底的な評価が必要です。システム間の構文の違い、機能ギャップ、パフォーマンスの変動を特定するための包括的なテストを実施します。すべてのビジネスクリティカルなクエリをテストするか、可能であれば、アプリケーションが依存するすべてのクエリをテストして、移行後に正しく機能し、パフォーマンスが高いことを確認します。

データ変換計画

移行する前に、スキーママッピングに細心の注意を払って、ソースシステムとターゲットシステム間の適切なデータ整合性と構造整合性を確保し、時系列データ専用の正確なデータ型変換を行います。これらのコンポーネントは連携して、データ品質を確保し、パフォーマンスを最適化し、さまざまなシステムアーキテクチャにわたって機能を維持します。さらに、効率的なデータアクセスと取得を保証するために、特殊なインデックス作成パターンとシステム固有の最適化を検討してください。

継続性とダウンタイムの管理

データ移行は本質的に運用の中断を引き起こすため、包括的なスイッチオーバー戦略を策定することが成功に不可欠です。ダウンタイムを最小限に抑えるために移行計画で考慮すべきベストプラクティスは次のとおりです。

  • ビジネス継続性を維持するために、可能な限り一時的な並列処理システムを実装します。

  • 週末や夜間など、トラフィックが少ない時間帯に移行をスケジュールします。

  • 予期しない問題が発生した場合に迅速に復旧できるように、十分にテストされたロールバック手順を確立します。