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

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