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 的大作中提到】
: 我有一个ORDER TABLE,有100BILLION数据
: 每天每个小时LOAD进1MILLION数据，
: 我有很多APPLICATION要RUN，我怎么LOAD数据
: 怎么搞INDEX和BACKUP啊
|
y****w
发帖数: 3747 | 4 partition
【在 s**********o 的大作中提到】
: 我有一个ORDER TABLE,有100BILLION数据
: 每天每个小时LOAD进1MILLION数据，
: 我有很多APPLICATION要RUN，我怎么LOAD数据
: 怎么搞INDEX和BACKUP啊
|
B*****g
发帖数: 34098 | 5 partition撑得住吗？
【在 y****w 的大作中提到】
: 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 的大作中提到】
: 我有一个ORDER TABLE,有100BILLION数据
: 每天每个小时LOAD进1MILLION数据，
: 我有很多APPLICATION要RUN，我怎么LOAD数据
: 怎么搞INDEX和BACKUP啊
|
y****w
发帖数: 3747 | 7 不用都挂上啊。hot的挂着，其他的备用。
【在 B*****g 的大作中提到】
: partition撑得住吗？
|
B*****g
发帖数: 34098 | 8 coolbid来说说怎么不挂上，我还没听说过。
我只是觉得这么大的数据要在技术上优化实在有限，不如在构架方面做改进。当然，据
说买了exadata就全解决了。
【在 y****w 的大作中提到】
: 不用都挂上啊。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 的大作中提到】
: 菜鸟想法，是不是考虑把name, address, email剥离出去，看看还有啥能剥离出去
: order table and order history table 分开.
|
|
|
y****w
发帖数: 3747 | 11 sql不支持deattach/attach?
【在 B*****g 的大作中提到】
: coolbid来说说怎么不挂上，我还没听说过。
: 我只是觉得这么大的数据要在技术上优化实在有限，不如在构架方面做改进。当然，据
: 说买了exadata就全解决了。
|
B*****g
发帖数: 34098 | 12 你是说只对某个partition做操作？
【在 y****w 的大作中提到】
: sql不支持deattach/attach?
|
B*****g
发帖数: 34098 | 13 数据不一定都在一个table里，甚至不一定在一个数据库里
【在 s**********o 的大作中提到】
: 不行，由于法律的关系，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 的大作中提到】
: 你是说只对某个partition做操作？
|
B*****g
发帖数: 34098 | 15 这个在俺们公司效果不好，partition和index总是不能结合的很好
还不如分table，在app层做处理
【在 y****w 的大作中提到】
: 如果应用允许就尽量在partition级别操作。为了获取最大灵活性，也许应用也要改改
: ，比如current data永远是xxx_current，也许需要join,或者union all一下。到一定
: 时候给挂到主表上去+生成一个新表。
: 对超大表的策略一般也就是分而治之。
|
y****w
发帖数: 3747 | 16 range partition key不好找？
我上个项目就有这问题，很难找到合适的分组key，以至于避免不了分区间引用。当时
建议加上一个生成key来解决这问题，不过后来人不在了也就不知道怎样了。
我怎么觉得smallburrito他说的就只是普通的大表？
【在 B*****g 的大作中提到】
: 这个在俺们公司效果不好，partition和index总是不能结合的很好
: 还不如分table，在app层做处理
|
B*****g
发帖数: 34098 | 17 公司的DBA哪里肯动脑子，简单按pk分
【在 y****w 的大作中提到】
: 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 的大作中提到】
: 我觉得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 的大作中提到】
: 一共就几十个州，这么多数据，分开挺好。
: partition算是union all view的进化，把一部分职能从developer往dba那里动了动，
: 设计要求提高了不少。协调不好还不如分表应用自己玩得好。
|
|
|
c*****d
发帖数: 6045 | 21 oracle partition没有attach/detach
好像只有ibm有这个功能
【在 B*****g 的大作中提到】
: coolbid来说说怎么不挂上，我还没听说过。
: 我只是觉得这么大的数据要在技术上优化实在有限，不如在构架方面做改进。当然，据
: 说买了exadata就全解决了。
|
c*****d
发帖数: 6045 | 22 你们用的是global index还是local index
【在 B*****g 的大作中提到】
: 这个在俺们公司效果不好，partition和index总是不能结合的很好
: 还不如分table，在app层做处理
|
c*****l
发帖数: 312 | 23 这个跟很多因素相关吧？比如application 架构， 数据type ，数据周期， 表的作用
，查询方式， 等等。
每天每个小时LOAD进1MILLION数据， 一年九有100B的数据了。
【在 s**********o 的大作中提到】
: 我有一个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 的大作中提到】
: 我有一个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 的大作中提到】
: 我有一个ORDER TABLE,有100BILLION数据
: 每天每个小时LOAD进1MILLION数据，
: 我有很多APPLICATION要RUN，我怎么LOAD数据
: 怎么搞INDEX和BACKUP啊
|
