各位大佬对预测数据存储有什么好的方案吗

[y0bcn]

发布时间：t

预测时间范围：t-->Δi

现有方案 1：

发布时间	预测时间	预测项 1	预测项 2	预测项 3	预测项...
t1	t1+Δ	v	v	v	v
t2	t2+Δ	v	v	v	v
t…	t...+Δ	v	v	v	v

有点：心智成本低，读写方便

缺点：记录数多且查询性能较差，建索引后查询性能有所提升但插入速度较慢

现有方案 2：

发布时间	Δ1	Δ2	Δ3	Δ…	Δi
t1	V1	V2	V3	V…	Vi
t2	V1	V2	V3	V…	Vi
t…	V1	V2	V3	V…	Vi

优点：可有效降低记录数量，提高查询效率

缺点：进行各种计算时心智成本过高，代码质量难以保证

现在用 MySQL 硬存，有以上两种方案，发现要么性能差，要么心智成本高，想跟各位大佬取取经 可以尝试 newSQL ，了解了时序数据库感觉好像也不是特别合适？因为时间会有重合

[dayeye2006199]

得分析一下你的下游是怎么使用这个数据的。

我们做过和你的同样的应用，下游需要支持按照发布时间+预测时间作为查询条件的查询和时间上卷操作。
所以方案 1 对这个需求支持是最好的。

对发布时间和预测时间需要建立索引。

数据量如果非常巨量的话，考虑对发布时间或者发布时间的区间（例如一周）做 partition 进行分表操作。

方案 2 虽然数据更加紧凑，但是下游的查询是真的难写，不推荐。

[y0bcn]

@dayeye2006199 感谢回复，目前采用方案 2 ，确实下游查询非常难写，做法是将数据查出来后进行拆解转换，来简化开发，但是感觉这样的代码实在是难以维护，还是想办法提高方案 1 的性能才是好的方案。

[zmal]

方案一中“建索引后查询性能有所提升但插入速度较慢”，感觉写入速度不应该是瓶颈...mysql 写入有不少优化方案，真心数据量特别大还可以 load data 。

[y0bcn]

@zmal 好的，感谢提醒，我去学习一下