我曾成功地将一些旧数据导入Timestream表一段时间，但随后它开始给出错误：
Timestream error: com.amazonaws.services.timestreamwrite.model.ThrottlingException: Your magnetic store writes to Timestream are throttled for this database. Refer to Timestream documentation for 'ActiveMagneticStorePartitions' metric to prevent recurrence of this issue or contact AWS support.
它所指的指标上升到了250的限制，但过了一段时间就降到了0，即使在那之后，当我开始导入时，它立即达到了限制，错误再次出现，因此根本没有导入任何内容。
我不是并行运行导入，而是一次只运行一个，但它仍然会引发错误。
作为一种解决方法，我决定增加该表的内存保留期，但由于某些原因，即使在新的内存保留期间内导入数据，仍然会出现相同的错误。
如果您正在接收旧数据，则应尝试按时间戳对数据进行排序。这将有助于创建更少的活动分区。然后，在将旧数据插入Timestream之前，您应该检查活动分区。
我与AWS支持团队见过几次面，以了解将数据摄入磁性存储的最佳方式(内存存储没有这个限制)。他们建议摄取按时间戳排序的数据。因此，如果您有多个设备，您应该按时间戳而不是按设备获取数据。
主动分区背后的标准并不明确，他们总是谈论可能性。。。
我运行了负载测试，将相同的数据摄入磁性存储，结果得到了不同数量的活动分区。
以下是我的负载测试结果：
我摄入了属于2022年1月的21422288记录，这些记录将用我当前的时间流配置写入磁存储中。在每次执行之间，我都会增加记录版本以覆盖以前的记录。
一月(活动分区总数：0)
- Ingest 2142288条记录->新的16个活动分区(新分区：16个)
- Ingest 2142288条记录->新增16个活动分区(新增：16个，总计：32个)
- Ingest 2142288条记录->新增16个活动分区(新增：16个，总计：48个)
- Ingest 2142288条记录->新增0个活动分区(新增：0，总计：48)
- Ingest 2142288条记录->新增0个活动分区(新增：0，总计：48)
在没有等待活动分区降至零的情况下，我摄入了属于2022年2月的1922784记录。
二月(活动分区总数：48)
- Ingest 1922784条记录->新增0个活动分区(新增：0，总计：48)
我一直等到活动分区减少到零，增加记录版本并运行相同的测试
二月(活动分区总数：0)
- Ingest 1922784条记录->新建82个活动分区(新建：0，总计：82)
正如您所看到的，关于活动分区的创建没有明确的模式，但如果您按时间戳对数据进行排序，您将在将数据摄入磁性存储时获得更好的成功可能性。
也有完全相同的问题。
有一张我们正在吸收历史记录的表，在我们通过某个阈值之前一直运行良好。(不确定是否值得一提，但当当前数据到达时，也会实时写入此表)。我们在没有达到250个活动分区限制的情况下，将大约500米的行放入表中，数据是有序的，等等。
几周前，情况发生了变化，从那时起，每当向表中写入历史行时，它几乎立即从0跳到250个活动磁分区，历史摄入也停止了。我们已经为此斗争了好几个星期了。
我们的解决方案是创建另一个空表，将历史记录导入该表，然后每隔50米左右使用一个调度查询来复制该表中的所有数据；temp"；表到我们要使用的实际表。这种临时表设置基本上是最小内存存储和最大磁存储，因为我们一次只写6个月大的历史数据。
由于某种原因，这很好，所有的行都被考虑在内，并且它永远不会达到250个活动分区的限制。它的成本要高一点，但在我们的案例中不会高很多，这是我们发现的唯一有效的方法。
如果我们将相同的数据写入原始表，它会立即命中250个活动mag分区。暂停该过程，更改目标表，再次运行它，对于相同的数据，新的目标表几乎没有超过8-12个有效磁分区的范围。
运行调度查询将数据从临时表复制到目标表似乎对我所看到的目标表活动分区计数器没有任何影响，我认为这只是在幕后发生的。
目前，这似乎是完成我们历史数据导入的唯一途径。
实时流式传输或"；今天"；mem存储中的数据始终运行良好。这种情况只在将历史数据写入磁存储器时才会发生。