新足迹

 找回密码
 注册

精华好帖回顾

· 住家附近一栋房子:开价400K+,成交512K (2007-5-12) villa · 迈向皮鞋,我的广州-悉尼搬家经历 (2015-3-19) fangray
· 由世界边缘 (not quite) 到地之尽头——2016年初秋英国游记(完) (2018-5-29) shine_on · 南澳阿德,袋鼠岛,蓝湖9日游(完结) (2011-10-27) kate555
Advertisement
Advertisement
楼主:月亮

一个table,25亿条记录,每天要更新,最快的方法? [复制链接]

发表于 2013-4-17 09:01 |显示全部楼层
此文章由 workinvm 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 workinvm 所有!转贴必须注明作者、出处和本声明,并保持内容完整
试试SQL SERVER 的增量备份功能
Advertisement
Advertisement

发表于 2013-4-17 10:07 |显示全部楼层
此文章由 workflow 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 workflow 所有!转贴必须注明作者、出处和本声明,并保持内容完整
bluesknight 发表于 2013-4-17 00:41
额,我有点没整明白。要么batch job要么realtime,这每晚batch的realtime是嘛意思?兄弟给解释下? ...

系统完全real的不现实,实际上是混合在一起的

发表于 2013-4-17 11:24 |显示全部楼层
此文章由 wonderdream 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 wonderdream 所有!转贴必须注明作者、出处和本声明,并保持内容完整
workflow 发表于 2013-4-17 09:07
系统完全real的不现实,实际上是混合在一起的

Agree, in traditional data warehousing scenario, it is very hard to achieve real time processing.

If you don't need real time OLAP, "Always On" feature in new SQL Server 2012 should be able to achieve "real time" reporting requirement without impacting OLTP. You could replicate the data from the primary to secondary (and 3rd, 4th) in a real-time fashion. You can even build index on the secondary different to the primary.

评分

参与人数 1积分 +4 收起 理由
workflow + 4 感谢分享

查看全部评分

a

发表于 2013-4-17 19:43 |显示全部楼层
此文章由 bluesknight 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 bluesknight 所有!转贴必须注明作者、出处和本声明,并保持内容完整
workflow 发表于 2013-4-17 09:07
系统完全real的不现实,实际上是混合在一起的

可能是我阅读障碍了,看你上一贴我还以为是用batch来run realtime job,还在纠结这是怎么跑的

realtime确实是说得多做得少,很多client都在说要弄realtime,最后真做一个都没有,最多是looping batch job,勉强算semi-realtime吧。

发表于 2013-4-18 00:55 |显示全部楼层
此文章由 phome 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 phome 所有!转贴必须注明作者、出处和本声明,并保持内容完整
对于一个表存25亿数据来说,得分析表的使用场境和频率。更新的量是多少,插入的量是多少,删除的量是多少。对于这样的表,只能是增量备份。或实时备份。

发表于 2013-4-18 12:52 |显示全部楼层
此文章由 phoboshero 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 phoboshero 所有!转贴必须注明作者、出处和本声明,并保持内容完整
export import? 为什么要maintain这么大的一张表 有DWH支持的话不能每天只记录更新数据么 然后每天只扔给DWH当天的部分 让DWH做aggregation
Advertisement
Advertisement

发表于 2013-4-18 13:01 |显示全部楼层
此文章由 phoboshero 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 phoboshero 所有!转贴必须注明作者、出处和本声明,并保持内容完整
realtime也要看你做具体哪个行业的软件了 telecom assurance模块的话基本标准是15分钟 从probing到最后出数据 为了NOC SAC的需要

如果是daily reporting的话一般不算realtime

发表于 2013-4-18 20:26 |显示全部楼层
此文章由 huaxianz 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 huaxianz 所有!转贴必须注明作者、出处和本声明,并保持内容完整
晕,大家还在踊跃回答呢啊?版主明显是用来活跃版内气氛的,不是来提问的。虽然哥也回过两次
后来越想越不对劲。大家跟着这个思路走(所有的假设都是一般平均值,不排除这个帖子有可能说的某个极限):一个表500GB,这个库得多大?一般一个DW不能只有一个fact table吧?咱就往少算它1个T。做过DBA的同学给算算,1个T的database来个full backup需要多久?小数据库也许OK, VLDB光一个backup strategy就搞死你。比如怎么保证RTO和RPO?当一次机吭哧瘪肚的恢复数据两天?(当然肯定要就其他的HA方案,但不是我这里讨论的,因为它们并不冲突,或者说A代替不了B,反之也成立)所以这个或这群DBA肯定不是刚毕业的,整个file/group backup不算过吧?能搞得懂file/group design的,没听说过partitioning?开国际玩笑。500G的表每次都truncate?玩笑都出地球了。所以结论就是有这种数据量的公司,就肯定有相应的人才,尤其还是电信公司。很可能人才就是楼主自己。最好的证据就是楼主早就闪了。留下一群高手还在这儿华山论剑。都洗洗睡吧。

发表于 2013-4-19 16:54 |显示全部楼层
此文章由 zombie 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 zombie 所有!转贴必须注明作者、出处和本声明,并保持内容完整
是不是先搞清楚能不能做增量修改,还是非要全部重来?能不能重新考虑整个设计。
如果全部重来的话,源表和目的表是不是能partition。partition能增加并行运行。还有用SSD.
方法多一点的可能是增量修改。有没有MODIFIED DATE之类的可以区别,或者CDC,还有就是计算CHECKSUM。新的记录要做bulk load,修改的可能也是先删除再一起bulk load。目的表还是要分区快一点吧。index一般都是drop了再build吧。LZ发个500G表,大家各自设计比赛好了。

发表于 2013-4-19 16:58 |显示全部楼层
此文章由 梦呓人 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 梦呓人 所有!转贴必须注明作者、出处和本声明,并保持内容完整
huaxianz 发表于 2013-4-18 19:26
晕,大家还在踊跃回答呢啊?版主明显是用来活跃版内气氛的,不是来提问的。虽然哥也回过两次
后来越想 ...

月亮MM是在特大型公司就职啊


反正我看到帖子后被震住了,也学到了很多。。。

发表于 2013-4-20 20:23 |显示全部楼层
此文章由 huaxianz 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 huaxianz 所有!转贴必须注明作者、出处和本声明,并保持内容完整
梦呓人 发表于 2013-4-19 15:58
月亮MM是在特大型公司就职啊

是,我就是这个意思。他们这种规模公司的DBA们肯定不是吃素的。就是开个玩笑,希望楼主不要介意。

还有兄弟,你能不能不要定期把6park右下角上的自拍拿来当头像啊。。。
Advertisement
Advertisement

发表于 2013-4-22 10:52 |显示全部楼层
此文章由 梦呓人 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 梦呓人 所有!转贴必须注明作者、出处和本声明,并保持内容完整
huaxianz 发表于 2013-4-20 19:23
是,我就是这个意思。他们这种规模公司的DBA们肯定不是吃素的。就是开个玩笑,希望楼主不要介意。

还有 ...

大哥,我可以像毛主席保证:我几乎没有拿“留园右下角帖子”里的图片做过头像。。。。


太平洋足够宽广,容得下6park和其它类似网站的咯






评分

参与人数 1积分 +3 收起 理由
huaxianz + 3 你太有才了

查看全部评分

发表于 2013-5-1 23:36 |显示全部楼层
此文章由 daomeidan1234 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 daomeidan1234 所有!转贴必须注明作者、出处和本声明,并保持内容完整
晕,这个问题很无狸头啊?

既然是Bi,先问问这个表上的查询报表是怎么做的?

另外,既然BI,澳洲通常是Daily batch,一个表的一天的记录有25亿条啊?

这是什么业务啊???是coles 一天所有的交易明细吗?
与其插一腿,不如插一嘴。

发表于 2013-5-2 00:09 |显示全部楼层
此文章由 5.5 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 5.5 所有!转贴必须注明作者、出处和本声明,并保持内容完整
本帖最后由 5.5 于 2013-5-1 23:22 编辑
北风 发表于 2013-4-10 11:55
不要用insert into

这样,log会少很多


index creation alone may take really long time
schedule a backup restore whole database 啦
25亿, 还每天要update, 无partition, 从一开始design 就有问题

发表回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则

Advertisement
Advertisement
返回顶部