这是一个创建于 862 天前的主题，其中的信息可能已经有所发展或是发生改变。
- 数据是按照业务时间排序的，但是允许用户插入或修改历史数据
- 数据的计算是按照时间顺序，下一条数据依赖上一条数据，由于允许修改历史数据和插入历史数据会导致大量的历史数据重算。而且由于可以批量修改历史数据或者批量插入历史数据，会导致非常多的数据重算。
- 查询这些数据有比较多的 group union 操作。
- 单年数据行数会过亿，以前是分布在每个客户的机器上计算的，也会导致客户的机器很卡，现在做到服务器了。
目前是存储在 MySQL ，然后数据发生变更的时候捞出来在 java 程序中计算好再批量更新到 MySQL 中，占用资源非常多。有没有比较好的方案进行存储和计算。
第 1 条附言 · 2022-07-14 10:41:34 +08:00
感谢大家回复，没有说业务场景，补充一下。
我们是传统行业，简单点描述是记录商品的进出，然后使用的移动加权方式计算商品的成本，以及进行一些报表计算。面向的客户逻辑水平会比较低，因为很多客户是那种四五十岁的甚至还有七十多的那种没什么逻辑的客户，所以我们的软件做得非常灵活。业内常用的方案是限制修改历史数据的规模，以及定期强制客户结转数据。我们因为做的太灵活了，这两个都不太好做，可以说是做不了，因为结转的前提就是结清，我们的用户没有这个认知水平，没法强制他们做。
核心的问题就是在于可以随意增删改历史数据导致历史数据后面的数据都要重算更新，并不像那些交易类的数据不可变更，可以通过流式计算来处理。
我们是传统行业，简单点描述是记录商品的进出，然后使用的移动加权方式计算商品的成本，以及进行一些报表计算。面向的客户逻辑水平会比较低，因为很多客户是那种四五十岁的甚至还有七十多的那种没什么逻辑的客户，所以我们的软件做得非常灵活。业内常用的方案是限制修改历史数据的规模，以及定期强制客户结转数据。我们因为做的太灵活了，这两个都不太好做，可以说是做不了，因为结转的前提就是结清，我们的用户没有这个认知水平，没法强制他们做。
核心的问题就是在于可以随意增删改历史数据导致历史数据后面的数据都要重算更新，并不像那些交易类的数据不可变更，可以通过流式计算来处理。
 |
1
qping 2022-07-14 09:43:10 +08:00
下一条数据依赖上一条数据。。。你们是做了一个可修改的区块链么。。。。
|
 |
2
arvinsilm 2022-07-14 09:46:35 +08:00
Apache Doris 看一下，你们现在用的 MySQL ，这个迁移成本比较小
|
 |
3
shoumu 2022-07-14 09:48:09 +08:00
看看时序数据库是否符合你的需求呢，比如 TDEngine
|
 |
4
liuhan907 2022-07-14 09:54:41 +08:00 via Android
修改历史数据改为增加变更日志，写入的数据不要修改，每次重计算在上一次基础上再计算。定期清理旧数据，如果能的话。
|
 |
5
changepll 2022-07-14 10:13:08 +08:00
你现在描述的是这个场景下你是怎么做的。 但没有说是什么场景。
可以说出业务需求，然后大家看有什么好的改进或是更佳的方案 |
 |
6
tooroot 2022-07-14 10:13:19 +08:00
MySQL 可以迁移到 TiDB ，完全兼容的，避免导入导出；
如果晚上没有数据更新，类似你之前的方案，可以导入 Clickhouse ，性能非常残暴，算完再导回去，麻烦一些 |
 |
7
masterclock 2022-07-14 10:21:22 +08:00
我们的做法是：
1. 数据库的数据通过 CDC 进 消息总线 2. 计算由请求触发，在计算结果缓存里找，没有的话就重新计算 3. 有个服务处理数据更新后删缓存结果，做了节流去抖 4. “最新” 结果会节流去抖后立刻计算，为了体验好点 应该不是太好的方案，但比较适合我们 |
 |
8
vvtf 2022-07-14 10:23:40 +08:00
我觉得修改历史数据不能直接修改那一刻的数据, 而是根据一个算法在最后增加一个和当前逻辑一样的变更数据;
就如 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). 如上. |
|
10
liuhan907 2022-07-14 14:52:50 +08:00
看你的描述，修改做成操作日志+定期压缩快照。我觉得是可行的，或者说有别的限制？
|
 |
11
a90120411 2022-07-14 17:35:53 +08:00
你的用户年龄偏中老年群体，为什么要把产品做的非常灵活？没理解这个逻辑。
不是应该提供一键傻瓜式解决方案么，消除这种随意性带来的负担。 个人愚见。 |
Select Language