Amazon Timestream for LiveAnalytics に類似した機能をご希望の場合は Amazon Timestream for InfluxDB をご検討ください。リアルタイム分析に適した、シンプルなデータインジェストと 1 桁ミリ秒のクエリ応答時間を特徴としています。詳細については、[こちら](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html)を参照してください。

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

# Amazon Timestream for LiveAnalytics の可用性の変更
<a name="timestream-availability-update"></a>

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

## 代替サービスの評価
<a name="alternative-services"></a>

**Amazon Timestream for InfluxDB に適したユースケース**  
Timestream for LiveAnalytics テーブルのカーディナリティ ([系列キー](https://docs.influxdata.com/influxdb/v2/reference/key-concepts/data-elements/#series)) が 1,000 万未満の場合 (つまり、[Amazon Timestream for LiveAnalytics の概念](concepts.md) の一意の組み合わせである場合)、またはテーブルのカーディナリティを 1,000 万未満に減らすことができる場合は、[Timestream for InfluxDB](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html) をお勧めします。Timestream for InfluxDB では、InfluxDB のオープンソースバージョンの機能を利用できます。この方法を選択すると、[Flux](https://docs.influxdata.com/influxdb/v2/query-data/flux/) が提供する時系列分析関数、タスク ([スケジュールされたクエリ](scheduled-query.md) に相当)、Timestream for LiveAnalytics が提供する他の同様の関数など、既存の時系列機能が提供されます。Timestream for InfluxDB は、時系列データのクエリと分析のために InfluxDB とやり取りするための [InfluxQL](https://docs.influxdata.com/influxdb/v2/query-data/influxql/) (SQL のようなクエリ言語) も提供しています。

**InfluxQL ではなく SQL を使用したい場合**  
Amazon Aurora または RDS PostgreSQL を実装することをお勧めします。これらのデータベースには、効果的な[時系列データ管理](https://docs.aws.amazon.com//AmazonRDS/latest/UserGuide/PostgreSQL_Partitions.html)機能の他に、完全な SQL 機能が搭載されています。時系列分析は、使用可能な場合は組み込みのデータベース関数を使用して実装することも、アプリケーションレイヤーで管理することもできます。

**大規模なデータインジェストが必要な (秒あたり 100 万レコードを超える) 場合**  
Amazon DynamoDB または他の AWS [NoSQL](https://aws.amazon.com/nosql/) データベースを使用することをお勧めします。これらのデータベースは、特定のアプリケーションのニーズに基づいて選択してかまいません。時系列分析は、使用可能な場合は組み込みのデータベース関数を使用して実装することも、アプリケーションレイヤーで管理することもできます。

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

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

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

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

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

**データ変換計画**

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

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

データ移行には運用の中断がつきものであるため、包括的なスイッチオーバー戦略を策定することが成功に不可欠となります。ダウンタイムを最小限に抑えるために移行計画で考慮すべきベストプラクティスは次のとおりです。
+ ビジネス継続性を維持するために、可能な限り一時的な並列処理システムを実装する。
+ 週末や夜間など、トラフィックが少ない時間帯に移行を予定する。
+ 予期しない問題が発生した場合に迅速に復旧できるよう、十分にテストされたロールバック手順を確立する。