s**********o 发帖数: 14359 | 1 我有一个ORDER TABLE,有100BILLION数据
每天每个小时LOAD进1MILLION数据,
我有很多APPLICATION要RUN,我怎么LOAD数据
怎么搞INDEX和BACKUP啊 |
c*****d 发帖数: 6045 | 2 在oracle里backup不是问题
index可能有性能问题 |
B*****g 发帖数: 34098 | 3 每天一个table
【在 s**********o 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 我有一个ORDER TABLE,有100BILLION数据 : 每天每个小时LOAD进1MILLION数据, : 我有很多APPLICATION要RUN,我怎么LOAD数据 : 怎么搞INDEX和BACKUP啊
|
y****w 发帖数: 3747 | 4 partition
【在 s**********o 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 我有一个ORDER TABLE,有100BILLION数据 : 每天每个小时LOAD进1MILLION数据, : 我有很多APPLICATION要RUN,我怎么LOAD数据 : 怎么搞INDEX和BACKUP啊
|
B*****g 发帖数: 34098 | 5 partition撑得住吗?
【在 y****w 的大作中提到】![](/moin_static193/solenoid/img/up.png) : partition
|
n****f 发帖数: 905 | 6 You should provide more information.
What these 1MILLION looks like. What is the key......
Then you can choose how to load them, index....
【在 s**********o 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 我有一个ORDER TABLE,有100BILLION数据 : 每天每个小时LOAD进1MILLION数据, : 我有很多APPLICATION要RUN,我怎么LOAD数据 : 怎么搞INDEX和BACKUP啊
|
y****w 发帖数: 3747 | 7 不用都挂上啊。hot的挂着,其他的备用。
【在 B*****g 的大作中提到】![](/moin_static193/solenoid/img/up.png) : partition撑得住吗?
|
B*****g 发帖数: 34098 | 8 coolbid来说说怎么不挂上,我还没听说过。
我只是觉得这么大的数据要在技术上优化实在有限,不如在构架方面做改进。当然,据
说买了exadata就全解决了。
【在 y****w 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 不用都挂上啊。hot的挂着,其他的备用。
|
z**********8 发帖数: 2049 | 9 菜鸟想法,是不是考虑把name, address, email剥离出去,看看还有啥能剥离出去
order table and order history table 分开. |
s**********o 发帖数: 14359 | 10 不行,由于法律的关系,5年的数据都必须AVAILABLE,
每个州都有一个同样DB SERVER 收集ORDER,如果重新
NORMAILIZE的,工作量很大几乎不可能,而且多个TABLE
也会使SSIS变得更复杂,大家可以设想ORDER是病人记录
或者机动车记录或者电话记录等等。数据CENTRILIZE以后
要在NATIONAL LEVEL的网站上AVAIABLE
【在 z**********8 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 菜鸟想法,是不是考虑把name, address, email剥离出去,看看还有啥能剥离出去 : order table and order history table 分开.
|
|
|
y****w 发帖数: 3747 | 11 sql不支持deattach/attach?
【在 B*****g 的大作中提到】![](/moin_static193/solenoid/img/up.png) : coolbid来说说怎么不挂上,我还没听说过。 : 我只是觉得这么大的数据要在技术上优化实在有限,不如在构架方面做改进。当然,据 : 说买了exadata就全解决了。
|
B*****g 发帖数: 34098 | 12 你是说只对某个partition做操作?
【在 y****w 的大作中提到】![](/moin_static193/solenoid/img/up.png) : sql不支持deattach/attach?
|
B*****g 发帖数: 34098 | 13 数据不一定都在一个table里,甚至不一定在一个数据库里
【在 s**********o 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 不行,由于法律的关系,5年的数据都必须AVAILABLE, : 每个州都有一个同样DB SERVER 收集ORDER,如果重新 : NORMAILIZE的,工作量很大几乎不可能,而且多个TABLE : 也会使SSIS变得更复杂,大家可以设想ORDER是病人记录 : 或者机动车记录或者电话记录等等。数据CENTRILIZE以后 : 要在NATIONAL LEVEL的网站上AVAIABLE
|
y****w 发帖数: 3747 | 14 如果应用允许就尽量在partition级别操作。为了获取最大灵活性,也许应用也要改改
,比如current data永远是xxx_current,也许需要join,或者union all一下。到一定
时候给挂到主表上去+生成一个新表。
对超大表的策略一般也就是分而治之。
【在 B*****g 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 你是说只对某个partition做操作?
|
B*****g 发帖数: 34098 | 15 这个在俺们公司效果不好,partition和index总是不能结合的很好
还不如分table,在app层做处理
【在 y****w 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 如果应用允许就尽量在partition级别操作。为了获取最大灵活性,也许应用也要改改 : ,比如current data永远是xxx_current,也许需要join,或者union all一下。到一定 : 时候给挂到主表上去+生成一个新表。 : 对超大表的策略一般也就是分而治之。
|
y****w 发帖数: 3747 | 16 range partition key不好找?
我上个项目就有这问题,很难找到合适的分组key,以至于避免不了分区间引用。当时
建议加上一个生成key来解决这问题,不过后来人不在了也就不知道怎样了。
我怎么觉得smallburrito他说的就只是普通的大表?
【在 B*****g 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 这个在俺们公司效果不好,partition和index总是不能结合的很好 : 还不如分table,在app层做处理
|
B*****g 发帖数: 34098 | 17 公司的DBA哪里肯动脑子,简单按pk分
【在 y****w 的大作中提到】![](/moin_static193/solenoid/img/up.png) : range partition key不好找? : 我上个项目就有这问题,很难找到合适的分组key,以至于避免不了分区间引用。当时 : 建议加上一个生成key来解决这问题,不过后来人不在了也就不知道怎样了。 : 我怎么觉得smallburrito他说的就只是普通的大表?
|
s**********o 发帖数: 14359 | 18 我觉得PARTITION的INDEX也不好搞,
分表是可行的,把ORDER变成一个大VIEW,
每个州弄个VIEW_ORDER_CA
每个州有2个TABLE,
ORDER_CA_CURRENT
ORDER_CA_ARCHIVE
还可以把这些搞成MATERIALIZED VIEW,
这样每个州单独的LOAD SSIS,INDEX,BACKUP,ARCHIVE在特定的时间段
分在不同的数据库也可以,但是MATERIALIZED VIEW就不能用了 |
y****w 发帖数: 3747 | 19 一共就几十个州,这么多数据,分开挺好。
partition算是union all view的进化,把一部分职能从developer往dba那里动了动,
设计要求提高了不少。协调不好还不如分表应用自己玩得好。
【在 s**********o 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 我觉得PARTITION的INDEX也不好搞, : 分表是可行的,把ORDER变成一个大VIEW, : 每个州弄个VIEW_ORDER_CA : 每个州有2个TABLE, : ORDER_CA_CURRENT : ORDER_CA_ARCHIVE : 还可以把这些搞成MATERIALIZED VIEW, : 这样每个州单独的LOAD SSIS,INDEX,BACKUP,ARCHIVE在特定的时间段 : 分在不同的数据库也可以,但是MATERIALIZED VIEW就不能用了
|
s**********o 发帖数: 14359 | 20 如果嫌麻烦还可以做成REGION
【在 y****w 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 一共就几十个州,这么多数据,分开挺好。 : partition算是union all view的进化,把一部分职能从developer往dba那里动了动, : 设计要求提高了不少。协调不好还不如分表应用自己玩得好。
|
|
|
c*****d 发帖数: 6045 | 21 oracle partition没有attach/detach
好像只有ibm有这个功能
【在 B*****g 的大作中提到】![](/moin_static193/solenoid/img/up.png) : coolbid来说说怎么不挂上,我还没听说过。 : 我只是觉得这么大的数据要在技术上优化实在有限,不如在构架方面做改进。当然,据 : 说买了exadata就全解决了。
|
c*****d 发帖数: 6045 | 22 你们用的是global index还是local index
【在 B*****g 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 这个在俺们公司效果不好,partition和index总是不能结合的很好 : 还不如分table,在app层做处理
|
c*****l 发帖数: 312 | 23 这个跟很多因素相关吧?比如application 架构, 数据type ,数据周期, 表的作用
,查询方式, 等等。
每天每个小时LOAD进1MILLION数据, 一年九有100B的数据了。
【在 s**********o 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 我有一个ORDER TABLE,有100BILLION数据 : 每天每个小时LOAD进1MILLION数据, : 我有很多APPLICATION要RUN,我怎么LOAD数据 : 怎么搞INDEX和BACKUP啊
|
g*****g 发帖数: 34805 | 24 You can use Cassandra and the problem is solved. 1M entries/hour is not
heavy.
【在 s**********o 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 我有一个ORDER TABLE,有100BILLION数据 : 每天每个小时LOAD进1MILLION数据, : 我有很多APPLICATION要RUN,我怎么LOAD数据 : 怎么搞INDEX和BACKUP啊
|
d****n 发帖数: 12461 | 25 如果没有全局index,oracle可以搞两张分区表,current和backup,backup单个分区插
数据更新index,然后奇数偶数天exchange partition。
当然24x7的那种我也不知道怎么办。
还有那种一个州搬到另一个州的也要考虑到。
【在 s**********o 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 我有一个ORDER TABLE,有100BILLION数据 : 每天每个小时LOAD进1MILLION数据, : 我有很多APPLICATION要RUN,我怎么LOAD数据 : 怎么搞INDEX和BACKUP啊
|