请教一下此场景下的数据如何存储和计算

[SilenceLL]

1. 数据是按照业务时间排序的，但是允许用户插入或修改历史数据
2. 数据的计算是按照时间顺序，下一条数据依赖上一条数据，由于允许修改历史数据和插入历史数据会导致大量的历史数据重算。而且由于可以批量修改历史数据或者批量插入历史数据，会导致非常多的数据重算。
3. 查询这些数据有比较多的 group union 操作。
4. 单年数据行数会过亿，以前是分布在每个客户的机器上计算的，也会导致客户的机器很卡，现在做到服务器了。

目前是存储在 MySQL ，然后数据发生变更的时候捞出来在 java 程序中计算好再批量更新到 MySQL 中，占用资源非常多。有没有比较好的方案进行存储和计算。

[qping]

下一条数据依赖上一条数据。。。你们是做了一个可修改的区块链么。。。。

[arvinsilm]

Apache Doris 看一下，你们现在用的 MySQL ，这个迁移成本比较小

[shoumu]

看看时序数据库是否符合你的需求呢，比如 TDEngine

[liuhan907]

修改历史数据改为增加变更日志，写入的数据不要修改，每次重计算在上一次基础上再计算。定期清理旧数据，如果能的话。

[changepll]

你现在描述的是这个场景下你是怎么做的。 但没有说是什么场景。
可以说出业务需求，然后大家看有什么好的改进或是更佳的方案

[tooroot]

MySQL 可以迁移到 TiDB ，完全兼容的，避免导入导出；
如果晚上没有数据更新，类似你之前的方案，可以导入 Clickhouse ，性能非常残暴，算完再导回去，麻烦一些

[masterclock]

我们的做法是：
1. 数据库的数据通过 CDC 进 消息总线
2. 计算由请求触发，在计算结果缓存里找，没有的话就重新计算
3. 有个服务处理数据更新后删缓存结果，做了节流去抖
4. “最新” 结果会节流去抖后立刻计算，为了体验好点

应该不是太好的方案，但比较适合我们

[vvtf]

我觉得修改历史数据不能直接修改那一刻的数据, 而是根据一个算法在最后增加一个和当前逻辑一样的变更数据;
就如 git 一样;
比如以前的数据是:
时间 /对象 /操作(依赖上一条)/结果
220701/A/+1/1
220702/A/+1/2
220703/A/-3/-1

那么现在是需要把
220701/A/+1/1
这一条数据改成
220701/A/+2/2
其实可以理解成是增加了 1
可以在后面增加一个
220704/A/+1/0
因为最后的节点是
220703/A/-3/-1
所有算出来结构是+1/0

大概思路是这样, 比如要聚合的话也可以做到;
这样做的好处历史可追溯;且不可变;
坏处是需要看业务需求是否满足;
比如我在 220704 查询 220702 的数据, 是返回 2, 还是返回 3,(+1).

如上.

[SilenceLL]

@vvtf 如果是交易数据确实这样子可以

[liuhan907]

看你的描述，修改做成操作日志+定期压缩快照。我觉得是可行的，或者说有别的限制？

[a90120411]

你的用户年龄偏中老年群体，为什么要把产品做的非常灵活？没理解这个逻辑。
不是应该提供一键傻瓜式解决方案么，消除这种随意性带来的负担。
个人愚见。

[SilenceLL]

@liuhan907 是可以朝着这个方向设计，不过还是想看看有没有可能能够满足这种任意性的方案，如果有最好，实在不行就要跟业务商量对一些场景进行限制。

[SilenceLL]

@a90120411 大概是这个意思，一个系统有很多模块，比如商品，供应商，然后单据之类的。如果严谨的话用户应该在每个模块维护好各自的业务，实际我们设计的时候会做成比如这个人来了他就直接做单了，我们后台会帮他做很多事情，比如判断商品，供应商是否存在，如果不存在帮他创建。就是让他尽量把他当前想做的流程走下去，而不是要求他去严谨的按照设计去维护资料。还有像销售的场景也不会要求他一定要先有进货入库，可以允许他随便直接卖。总之就是走的下去就行。