高分速度求语句--第三季

2011-07-07 11:14:33 507 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

高分子物理知识点分子链越刚，DSm小聚合物的熔点和熔限和结晶形成的温度Tc有一定的关系结晶温度Tc低( 阅读详情

表1数据如下：
1 111,112
2 221,222,223
3 331,332,333,334
4 441,442
5 551,552,553,554
......

表2数据如下：
1 112,113
2 222,223,224
3 332,333,335,336
4 441,442
5 551,552,553,554
......

注意：以上数据 1 2 3 是有重复的，如何把表1 更新为：
1 111,112,113
2 221,222,223,224
3 331,332,333,334,335,336
4 441,442
5 551,552,553,554
......

...全文

USRP X410 MPM版本与主机UHD版本不匹配问题记录与解决至此大功告成！之前安装软件的坑算是填起来了，再次记录一下，希望能帮到有同样问题的小伙伴~ 阅读详情

arrow_gx

应用实例 27,579 成员 68,540 内容

+ 关注 + 加入社区

切换为时间正序

叶子 2011-07-07

打赏
举报

[Quote=引用 41 楼 arrow_gx 的回复:]
每天有上千万条的记录，而且有很多会有重复，目前想每天一个新表，然后把结果统计到一个历史表里面，

每天一个新表里面的的记录为：
1 111
1 112
2 221
2 222
......

每天统计出一下结果：
1 112,113
2 222,223,224
3 332,333,335,336
4 441,442
5 551,552,553,554
......
……
[/Quote]
明白楼主的意思了

设计的时候是关系表的，但是现在是要做统计，但是统计的格式的字符串拼接的
但是数据量大导致效率问题

叶子 2011-07-07

打赏
举报

这个效率很难控制，一对多还是需要用关系表来处理
这样拼字符串+数据大是提高效率的瓶颈！

1 111,112
2 221,222,223
3 331,332,333,334
4 441,442
5 551,552,553,554

这种结构一般超过10000以上的数据，就强烈建议不要使用了。

还是按晴天说的那种：
1 111
2 112
3 331
3 332
3 333
这种处理好一些。

arrow_gx 2011-07-07

打赏
举报

每天有上千万条的记录，而且有很多会有重复，目前想每天一个新表，然后把结果统计到一个历史表里面，

每天一个新表里面的的记录为：
1 111
1 112
2 221
2 222
......

每天统计出一下结果：
1 112,113
2 222,223,224
3 332,333,335,336
4 441,442
5 551,552,553,554
......

历史表采用一对多的方式进行记录，
例如当前数据：
1 111,112
2 221,222,223
3 331,332,333,334
4 441,442
5 551,552,553,554
......

如何利用统计结果，将历史表去掉重复数据，更新为：
1 111,112,113
2 221,222,223,224
3 331,332,333,334,335,336
4 441,442
5 551,552,553,554
......

唉，不知道这样说，够清楚了吗，大家是否看的明白？？？我语文差，大家见谅

Mr_Nice 2011-07-07

打赏
举报

其实这个问题，LZ需要取舍的。

结构不好，后期需要很多特殊方法处理数据，比如：拆分列值，再合并之类的。
无非就是算的快慢的事儿，这些都是消耗硬件资源，如果LZ硬件够好，基本可以忽略。

结构好些，就是I/O的事儿，千万行记录，这个I/O怎么都不会省的。

arrow_gx 2011-07-07

打赏
举报

每天会有上千万条的记录，而且有很多会有重复，目前想每天一个新表，然后把结果统计到一个历史表里面，
历史表采用一对多的方式进行记录，
1 111,112
2 221,222,223
3 331,332,333,334
4 441,442
5 551,552,553,554

-晴天 2011-07-07

打赏
举报

还是没明白你的意思.
反正,用拼接字符串的活儿去干上千万条记录的事儿,那可千万别去做.除非你有足够足够的时间去等一个运行了一场足球赛都结束它还没完的查询语句.

arrow_gx 2011-07-07

打赏
举报

这里 userid= 1 2 3 4 5 等，比如 userid=1 的用户，对应的记录就是 111,112

这里的 111,112 在原始记录里面是两条记录
1 111
1 112

这样说明清楚了吗？唉，我语文不够好，说不清楚，见谅了啊

arrow_gx 2011-07-07

打赏
举报

伪命题.
如果一个userid对应有上千万用户,请问,按你这样的设计,第二列的数据类型是什么?

不是这样的，是一个 userid 有可能对应多条记录
1 111,112
2 221,222,223
3 331,332,333,334
4 441,442
5 551,552,553,554

这里 userid= 1 2 3 4 5 等，比如 userid=1 的用户，对应的记录就是 111,112

-晴天 2011-07-07

打赏
举报

[Quote=引用 33 楼 arrow_gx 的回复:]
引用 32 楼 qianjin036a 的回复:
引用 31 楼 arrow_gx 的回复:
有点没拿定主意，最后的历史表有一个应用，就是要对表里的每个 userid 进行分析，如果这个历史表记录太多，也会影响后期的处理，唉，有点难办

还没想通?
如果这个表里的记录太多,也就是行太多,就不好办了?
问题是1对1 的进行记录，有可能一个 userid 会对应上万条记录，我倒不是怕硬盘空间问题，是怕后面的处理效率问题，因为后续处理是针对每一个用户进行分析的，有几百上千万用户，处理起来就很麻烦了[/Quote]
伪命题.
如果一个userid对应有上千万用户,请问,按你这样的设计,第二列的数据类型是什么?

arrow_gx 2011-07-07

打赏
举报

[Quote=引用 32 楼 qianjin036a 的回复:]
引用 31 楼 arrow_gx 的回复:
有点没拿定主意，最后的历史表有一个应用，就是要对表里的每个 userid 进行分析，如果这个历史表记录太多，也会影响后期的处理，唉，有点难办

还没想通?
如果这个表里的记录太多,也就是行太多,就不好办了?
那如果不是用行,你不是还得把这些数据插入到同一行里?
换成单一的行,会增大数据量吗?
显然木有!!!!!!
[/Quote]

问题是1对1 的进行记录，有可能一个 userid 会对应上万条记录，我倒不是怕硬盘空间问题，是怕后面的处理效率问题，因为后续处理是针对每一个用户进行分析的，有几百上千万用户，处理起来就很麻烦了

-晴天 2011-07-07

打赏
举报

[Quote=引用 31 楼 arrow_gx 的回复:]
有点没拿定主意，最后的历史表有一个应用，就是要对表里的每个 userid 进行分析，如果这个历史表记录太多，也会影响后期的处理，唉，有点难办
[/Quote]
还没想通?
如果这个表里的记录太多,也就是行太多,就不好办了?
那如果不是用行,你不是还得把这些数据插入到同一行里?
换成单一的行,会增大数据量吗?
显然木有!!!!!!

arrow_gx 2011-07-07

打赏
举报

有点没拿定主意，最后的历史表有一个应用，就是要对表里的每个 userid 进行分析，如果这个历史表记录太多，也会影响后期的处理，唉，有点难办

-晴天 2011-07-07

打赏
举报

Mr_Nice 2011-07-07

打赏
举报

[Quote=引用 22 楼 arrow_gx 的回复:]

量太大了，每天会有上千万条的记录，而且有很多会有重复，目前想每天一个新表，然后把结果统计到一个历史表里面，
历史表采用一对多的方式进行记录，
1 111,112
2 221,222,223
3 331,332,333,334
4 441,442
5 551,552,553,554
[/Quote]

还是得根据应用来看结构，如果LZ后期需要针对每条明细查询的话，建议还是标准的
1 111
1 112
2 221

这样的结构，虽然数据行会变多，但还可以用加索引等方法来进行优化。
如果用算法来处理数据，再进行连接，无形中又添加了处理的难度和资源消耗。

亿级别数据的处理基本的思路是分库与分区

另外，明细汇总时，建议每天进行数据仓库类的处理。
这样可以从计算亿级降低到千万级别，如果可以的话，数据汇总时间可以多次，
再从千万级，降低到百万级，相信对于硬件来说，几次百万级的汇总会比一次千万级来的要容易些。

参考

arrow_gx 2011-07-07

打赏
举报

其实现在我已经是这么做了。这个问题的表1 对应我前一个问题的统计结果，，
问题链接如下
http://topic.csdn.net/u/20110707/09/1d247f05-d369-46da-b3cb-74da6c2eba04.html?53086

现在问题是，统计出来的结果，和历史结果之间，如何更新，或者说历史表，也简单的采用 1对1 的方式，直接记录数据？那样初步估计也太大了...

以上这些做完以后，还要对整个历史表进行后续处理的，效率比较难解决

arrow_gx 2011-07-07

打赏
举报

用一個表記錄表3 ??

表3 的结构如何？？

中国风 2011-07-07

打赏
举报

[Quote=引用 24 楼 arrow_gx 的回复:]

引用 20 楼 varbinary 的回复:
既然这么大数据，既然知道很慢，既然知道现在的结构做起来很难
为什么不考虑修改结构呢？这不是自讨苦吃吗

结构方面可以改，但改成什么样的比较合适呢？？
[/Quote]
表1，表2每條記錄分開，便於更新。用一個表記錄表3

AcHerat 2011-07-07

打赏
举报

程序里拆分后存入表应该会好点吧！就是插入的时候直接按

1 111
1 112
1 113

这样子插入，再者显示为 1 111,112,113 应该没什么用处吧！如果,有几百个几千个，页面再怎么看是看不完的。

arrow_gx 2011-07-07

打赏
举报

[Quote=引用 20 楼 varbinary 的回复:]
既然这么大数据，既然知道很慢，既然知道现在的结构做起来很难
为什么不考虑修改结构呢？这不是自讨苦吃吗
[/Quote]

结构方面可以改，但改成什么样的比较合适呢？？

中国风 2011-07-07

打赏
举报

如果記錄的有效性周期不長，可以采用歷史庫，把舊數據庫搬動到歷史庫，需要時再調用

加载更多回复（35）

高分速度求语句--第三季

相关推荐