这是一个创建于 974 天前的主题，其中的信息可能已经有所发展或是发生改变。
发布时间：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 ，了解了时序数据库感觉好像也不是特别合适？因为时间会有重合
 |
1
dayeye2006199 2022-03-17 05:19:10 +08:00  1
得分析一下你的下游是怎么使用这个数据的。
我们做过和你的同样的应用，下游需要支持按照发布时间+预测时间作为查询条件的查询和时间上卷操作。 所以方案 1 对这个需求支持是最好的。 对发布时间和预测时间需要建立索引。 数据量如果非常巨量的话，考虑对发布时间或者发布时间的区间（例如一周）做 partition 进行分表操作。 方案 2 虽然数据更加紧凑，但是下游的查询是真的难写，不推荐。 |
 |
2
y0bcn OP @dayeye2006199 感谢回复，目前采用方案 2 ，确实下游查询非常难写，做法是将数据查出来后进行拆解转换，来简化开发，但是感觉这样的代码实在是难以维护，还是想办法提高方案 1 的性能才是好的方案。
|
 |
3
zmal 2022-03-17 11:33:28 +08:00
方案一中“建索引后查询性能有所提升但插入速度较慢”，感觉写入速度不应该是瓶颈...mysql 写入有不少优化方案，真心数据量特别大还可以 load data 。
|
Select Language