一个table，25亿条记录，每天要更新，最快的方法？

workflow

IsDonIsGood 发表于 2013-4-11 10:09
ETL，Report,Data mining应该分开算吧。
但是个人理解都算BI了

好多年没碰DW了，那时候是DM（data mart）跟DW（data warehouse）两大流派PK，不知道现在是肿么个情况。貌似澳洲还是DM派占上风。

Fernando

现在的新趋势是要求real time reporting， real time BI了，不过这几年肯投钱的公司不多吧

porcorosso

findajob 发表于 2013-4-11 09:11
各位足迹名人都都是做IT的阿 哈哈

何谓名人？

AmandaX

25亿。。。来膜拜下。。。

IsDonIsGood

workflow 发表于 2013-4-11 09:14
好多年没碰DW了，那时候是DM（data mart）跟DW（data warehouse）两大流派PK，不知道现在是肿么个情况。 ...

DW失败率超高，还有就是BIs经常打肿脸充胖子，明明设计有误，或者坐到一半已经无法为继了，偏要说成功了。
之后要么推到重来，要么后面的人不断地各种补丁各种擦PP.

IsDonIsGood

Fernando 发表于 2013-4-11 09:16
现在的新趋势是要求real time reporting， real time BI了，不过这几年肯投钱的公司不多吧 ...

有相关的Article了吗，上了CMS的贼船后很久没碰这些东西了。
real time reporting 难不成是放在memory里的那种DW？

workflow

Fernando 发表于 2013-4-11 10:16
现在的新趋势是要求real time reporting， real time BI了，不过这几年肯投钱的公司不多吧 ...

恩，我们现在的reporting系统就是realtime的（每晚batch）DM，搞了２年整个enterprise的DW，又烧钱又不出东西，各个系统部门也不配合，直接失败。现在上面的CTO想通了，直接搞DM，又省心又省钱，business用的爽，大家都开心。

workflow

IsDonIsGood 发表于 2013-4-11 10:18
DW失败率超高，还有就是BIs经常打肿脸充胖子，明明设计有误，或者坐到一半已经无法为继了，偏要说成功了 ...

BI在经济好的时候需求旺盛，现在经济萎靡不振，能砍就砍，有钱也都先花在业务核心系统了

righttang

因为做IT的才有空来泡论坛啊。。。。。

motorhero

25亿个记录做daily 移植本身就不是好设计。partion 吧。只制止变化变化的partion

IsDonIsGood

motorhero 发表于 2013-4-11 09:30
25亿个记录做daily 移植本身就不是好设计。partion 吧。只制止变化变化的partion ...

+1，25亿的记录不可能每条每天都在变，但是每天都要传送那么多明显是设计上的失误。就像之前有兄弟说的，加一个flag就可以很大程度上解决问题。专注于有什么技术可以解决25亿条记录的Transfer上有点舍本逐末了。设计上的问题拿技术来补，这个想法不对。

典

IsDonIsGood 发表于 2013-4-11 09:18
DW失败率超高，还有就是BIs经常打肿脸充胖子，明明设计有误，或者坐到一半已经无法为继了，偏要说成功了 ...

有时候是一种政治需要

你看我手下20个人做DW ，每年多少million，牛吧，
最后做出一堆垃圾没人用，再把责任推给其它人

典

做IT 不希奇
美女做IT就难得了

Ketchup

Log shipping？总不能每天25亿条记录都是全新的吧？

NNX

不需要drop table, SQL Server truncate table也不会写入log.

1. SSIS package 在source端还是destination?, 后者的话, 用SQL server Desination 会比 OLD DB Destination快
2. 可以考虑到的顺序是 truncate table - drop all index - insert data - re-create index, 这样会比带着index写入数据快很多很多, 否认你每写入一条记录都会涉及到index的变动
3. 如果可行的话, 可以把DB backup的model 改为simple, 写完数据之后再改回来, 这样可以确保最少的trans log

NNX

另外表中有没有什么id 或是date field可以确定是新的数据? 如果有的话, 每次在desitnation 读取max(id), 然后SSIS insert new data only with source id >destination max(id)

Fernando

IsDonIsGood 发表于 2013-4-11 09:18
DW失败率超高，还有就是BIs经常打肿脸充胖子，明明设计有误，或者坐到一半已经无法为继了，偏要说成功了 ...

我见过以DW 项目失败来搞政治斗争的，输掉的一方两层manager都被赶走，干活的team也拆了

findajob

porcorosso 发表于 2013-4-11 09:16
何谓名人？

就是常被人拍和拍人的童鞋

nis

掏宝普及mysql ,去掉oracle。谁从技术角度分析一下，为啥要这么干？

yangwulong1978

一个是钱的问题，设备维护费用贵，LICENSE  贵，,另一个淘宝的DB 牛，能确保用ＭＹＳＱＬ也没问题。。

不是说MYSQL就比ＯＲＡＣＬＥ强。

Fernando

nis 发表于 2013-4-11 11:11
掏宝普及mysql ,去掉oracle。谁从技术角度分析一下，为啥要这么干？

具体的内容国内网站很多了。 准确的说是去IOE，指 IBM P系列，Oracle DB，EMC 高端存储。硬件上大量使用 x86 + ssd + 廉价存储，大部分DB 用 mysql。他们自己在应用层做load balance, application partition, redundancy。没那个规模不可能这么干。估计是向facebook，google学的。
ebay原来很牛，全用Oracle，所有的DB 拖两个standby，Oracle的超级大客户。现在也开始用一部分mysql了，不过已经落后taobao很多了。

workflow

Fernando 发表于 2013-4-11 12:32
具体的内容国内网站很多了。 准确的说是去IOE，指 IBM P系列，Oracle DB，EMC 高端存储。硬件上大量使用  ...

应用层做优化是王道啊

psaux

根据数据量来选择数据库的都是不懂数据处理的，不解释。

ssat

use real time messaging interface?

wonderdream

psaux 发表于 2013-4-12 14:27
根据数据量来选择数据库的都是不懂数据处理的，不解释。

Hmm, I'm going to put the data set into desktop version of Microsoft Access.

....

Just a joke. I'm actually agree with you.

huaxianz

psaux 发表于 2013-4-12 14:27
根据数据量来选择数据库的都是不懂数据处理的，不解释。

顶你!
只能说这里懂的人不多。

bluesknight

典 发表于 2013-4-11 09:37
做IT 不希奇
美女做IT就难得了

我进这家公司的第一个project，6个人的team只有我一个男的，每次加班吃宵夜我都要扮演净坛使者的角色

bluesknight

workflow 发表于 2013-4-11 09:14
好多年没碰DW了，那时候是DM（data mart）跟DW（data warehouse）两大流派PK，不知道现在是肿么个情况。 ...

现在也还是两个流派，要么是3-tier solution：source -- staging -- DW -- DM，DW只负责data integration，所有business logic集中在DM。要么是2-tier solution，bypass DW，从staging直接到DM。我们一般建议客户用3-tier，除了技术因素外，多一层DW多收一份钱不是

bluesknight

workflow 发表于 2013-4-11 09:23
恩，我们现在的reporting系统就是realtime的（每晚batch）DM，搞了２年整个enterprise的DW，又烧钱又不出 ...

额，我有点没整明白。要么batch job要么realtime，这每晚batch的realtime是嘛意思？兄弟给解释下？

jetty

需求不太清楚。是把DW库的表truncate然后全量update? production 25亿的数据，更改模型是什么？只插入，还是有delete有update，每天更改数据多少，没有这些部分不好定量分析。