供货情况变更的 Amazon Timestrea LiveAnalytics m - Amazon Timestream
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

从2025年6月20日起,亚马逊Timestream版 LiveAnalytics 将不再向新客户开放。如果您想使用亚马逊 Timestream LiveAnalytics,请在该日期之前注册。现有客户可以继续照常使用该服务。有关更多信息,请参阅 Amazon Timestream 以了解 LiveAnalytics 可用性变更。

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

供货情况变更的 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)和目标服务之间的查询兼容性进行全面评估。进行全面测试,以确定系统之间的语法差异、功能差异和性能差异。测试所有关键业务查询,或者尽可能测试应用程序所依赖的所有查询,以确保它们在迁移后能够正常运行并且性能良好。

数据转换计划

在迁移之前,请密切注意架构映射,以确保源系统和目标系统之间的数据正确对齐和结构一致性,以及专为时间序列数据量身定制的准确数据类型转换。这些组件协同工作,可确保数据质量、优化性能并维护不同系统架构的功能。此外,还应考虑任何专门的索引模式和系统特定的优化,以保证有效的数据访问和检索。

连续性和停机时间管理

由于数据迁移本质上会导致运营中断,因此制定全面的切换策略对于成功至关重要。为了最大限度地减少停机时间,迁移计划中需要考虑的几个最佳做法是:

  • 尽可能实施临时并行处理系统,以保持业务连续性。

  • 在流量较低的时段(例如周末或夜间)安排迁移。

  • 建立经过充分测试的回滚程序,以便在出现意外问题时快速恢复。