要获得与亚马逊 Timestream 类似的功能 LiveAnalytics，可以考虑适用于 InfluxDB 的亚马逊 Timestream。它为实时分析提供了简化的数据摄取和个位数毫秒的查询响应时间。点击此处了解更多。
本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
供货情况变更的 Amazon Timestrea LiveAnalytics m
由于时间序列应用程序具有独特的要求和特征，因此我们提供了一个广泛的框架，以帮助您在深入研究具体的实现细节之前评估各种替代方案。本高级指南是您决策过程的基础，后续章节将介绍更详细的步骤和实际实施方案。
替代服务评估
- 用例适合 InfluxDB 的 Amazon Timestream
-
如果你的表的 Timestream 的基数（系列键
）小于 1000 万个，这意味着 LiveAnalytics 表的唯一组合，概念 Amazon Timestream LiveAnalytics 或者你可以将表的基数减少到 1000 万以下，我们建议使用 Timestream 来使用 InfluxDB。InfluxDB 的 Timestream 允许你访问开源版本的 InfluxDB 的功能。选择此路径可提供现有的时间序列功能，例如 Flux 提供的时间序列分析函数、任务（等同于计划查询）和 Timestream 提供的其他类似函数。 LiveAnalyticsInfluxDB 的 Timestream 还提供了 InfluxQL （一种类似 SQL 的查询语言），用于与 InfluxDB 交互以查询和分析你的时间序列数据。 - 更喜欢使用 SQL 而不是 InfluxQL
-
我们建议实施 Amazon Aurora 或 RDS PostgreSQL。这些数据库提供完整的 SQL 功能，同时提供有效的时间序列数据管理功能。时间序列分析既可以使用内置数据库函数（如果有）来实现，也可以在应用程序层进行管理。
- 需要大规模的数据摄取（每秒超过 100 万条记录）
-
我们建议使用亚马逊 DynamoDB 或其他 Amazon NoSQL 数据库。
可以根据您的特定应用程序需求选择这些数据库。时间序列分析既可以使用内置数据库函数（如果有）来实现，也可以在应用程序层进行管理。
在开始将数据迁移到所选替代 Amazon 服务之前，必须评估几个关键因素，这些因素将对您的迁移策略及其最终成功产生重大影响。这些评估将帮助您制定方法，确定潜在的挑战，并确保在迁移过程中实现更顺畅的过渡。
数据选择和保留注意事项
通过定义确切的保留要求来评估您的数据迁移范围。考虑是否需要迁移完整的历史数据集、仅迁移最新数据（例如过去 30 天、60 天或 90 天的数据），还是需要迁移特定的时间序列数据段。该决策应以三个关键因素为指导：监管合规性要求、业务分析需求以及围绕迁移复杂性和成本的实际考虑。
查询模式兼容性分析
由于时间序列数据库处理查询语言和功能的方式不同，因此需要对源服务（Timestream for Timestream LiveAnalytics）和目标服务之间的查询兼容性进行全面评估。进行全面测试，以确定系统之间的语法差异、功能差异和性能差异。测试所有关键业务查询，或者尽可能测试应用程序所依赖的所有查询，以确保它们在迁移后能够正常运行并且性能良好。
数据转换计划
在迁移之前，请密切注意架构映射，以确保源系统和目标系统之间的数据正确对齐和结构一致性，以及专为时间序列数据量身定制的准确数据类型转换。这些组件协同工作，可确保数据质量、优化性能并维护不同系统架构的功能。此外，还应考虑任何专门的索引模式和系统特定的优化，以保证有效的数据访问和检索。
连续性和停机时间管理
由于数据迁移本质上会导致运营中断，因此制定全面的切换策略对于成功至关重要。为了最大限度地减少停机时间，迁移计划中需要考虑的几个最佳做法是：
-
尽可能实施临时并行处理系统，以保持业务连续性。
-
在流量较低的时段（例如周末或夜间）安排迁移。
-
建立经过充分测试的回滚程序，以便在出现意外问题时快速恢复。