这个是分布式时序数据库的典型场景。提供一个使用DolphinDB解决类似场景的案例。
(1) 客户几百个业务场景，每天产生200多亿条时序日志记录(每条记录10个字段左右，维度+指标)，所有数据写入采用双副本，并提供强一致性保证。每天产生数据2个T，双副本大概4个T，压缩之后1个T。数据保留15天左右。
(2)写入的同时有并发的查询和计算。大概分三种。
根据业务场景和时间范围，读取原始数据，每次读取最近一个小时左右的数据，约几十万条数据
按设备或按业务场景等维度进行分类统计过去24小时内每分钟的统计量(均值)
按设备或按业务场景等维度进行分类统计过去24小时内各种指标的95百分位，供实时监控使用。
这三种query涉及的数据量都比较大，每分钟大概2000~3000个这样的query。单个查询和计算的延迟在几十毫秒到2秒之间。
(3)部署了6台(36核，256G内存的服务器)物理机的DolphinDB集群解决上面的场景。实际上内存和cpu的使用率都不是很高，可以使用更少的资源来完成。
你的场景数据量少很多，但是要保留更长的时间。一台16~24核，128~256G内存，6~12个hdd硬盘的物理机(售价6~10万)，安装DolphinDB时序数据库就可以搞定。你的业务场景非常简单，数据在DolphinDB中按照日期和设备两个维度分区就可以了。日期采用值分区，每天一个，设备采用范围或哈希分区，分成100个。这样每个分区的数据量大概在100万条左右，非常好的平衡了查询延时和吞吐量。