我正在尝试实现一个新的数据库模式模板来高效地存储/检索“公园”的时间序列数据。
一个公园有多个设备（和子设备），每个设备都有自己的信号。在公园里可以有2-5公里的设备，在某些情况下甚至更多。通常，信号的时间分辨率对于公园是相同的，通常为5-10-15分钟或1小时。
因为每个公园都可以有不同数量的设备，每个设备都有不同数量的数据信号和不同的时间分辨率，所以我必须创建一个在所有情况下都能正常工作的数据库模板。
在我们的系统中，有一个api，它经常读取最近的数据（最多是上周的数据），而偶尔读取历史数据（当最终用户通过接口请求时）。这同样适用于聚合新数据的后端进程，例如从5分钟到1小时的分辨率等，并且仅在手动请求时才对历史数据执行此操作。历史数据也将被用来做一些离线分析公园专用软件。
重要的是能够迁移数据库/表并在出现问题时快速恢复它们。
我有两个选择：
使用基于日期的mysql分区。
有一个“当前数据”表，其中存储所有信号数据，以便快速访问，然后定期将“旧”数据移到日、月、年表（块）中。这些块可以是自适应的，以便所有表都具有相同的大小（就所使用的磁盘空间而言）。这是因为某些设备或整个园区可能会离线一段时间，并且会出现数据漏洞。
您是否有其他更符合目的的想法，并强调不同方法的优缺点？
以下是有关如何存储设备的一些信息：

CREATE TABLE `Device` (
   `id` smallint(5) unsigned NOT NULL AUTO_INCREMENT,
   `devicetype_id` smallint(5) unsigned NOT NULL,
   `parent_id` smallint(5) unsigned DEFAULT NULL,
   `name` varchar(50) NOT NULL,
   `displayname` varchar(30) DEFAULT NULL,
   `status` tinyint(4) NOT NULL DEFAULT '1',
   PRIMARY KEY (`id`),
   UNIQUE KEY `dev_par` (`name`,`parent_id`)
) ENGINE=InnoDB

以及如何存储数据：

CREATE TABLE `Data_raw` (
   `id` int(11) NOT NULL AUTO_INCREMENT,
   `device_id` smallint(5) unsigned NOT NULL,
   `datetime` datetime NOT NULL COMMENT '[UTC] beginning of timestep',
   `value` float NOT NULL,
   `signal_id` smallint(5) NOT NULL,
   `modified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
   PRIMARY KEY (`id`)
) ENGINE=InnoDB

其他信息：
公园数量：150个，很快将达到500个左右。每个公园将有一个模式。
一个公园每年平均有8000万行数据。历史最长可以达到20年，但按平均值我们已经/将达到5年。考虑到rick估计的50b/行，我们将达到每年约5gb，因此历史上约50gb。考虑到aws aurora mysql的容量可以达到64tb，所有的公园都可以放在数据库中。在未来最坏的情况下，我们可以将一个客户机的parks拆分为不同的数据库碎片，这样就不成问题了。
对于数据库，我们将在aws上使用mysql aurora，其中一个主数据库当前将有16gb的ram和4个vcpu（我们还可以增加，针对后台进程/数据插入进行了优化），并且将有一个该数据库的读取副本，具有针对api方面的操作优化的不同硬件规范。
所有历史记录都必须存储并可用（对于不太频繁的操作，如历史分析、数据下载等）。
还有哪些信息可以帮助您了解/确定更好的选择？谢谢你抽出时间。