This topic has been archived. It cannot be replied.
-
工作学习 / IT技术讨论 / 有一个问题请教各位大侠：有一个很大的database table有一个问题请教：有一个很大的database table,现在大约有几十万条数据，每天以3万多条的数据增加。要不了多久就会过百万。那肯定会影响查询的速度。有没有一种办法，既可以每天以3万多条的数据增加，有不会影响查询的速度。谢谢了。。
-shanbuzhuan(山不转);
2005-3-11
{217}
(#2171978@0)
-
什么机器？什么数据库？几十万记录不算多啊。4年前我在2000多万条记录里面查数据也才1秒多时间。多建查询相关的index试试看，不过index建多了在写数据库的时候有点影响。
-thisunreal(饭得志);
2005-3-11
(#2172045@0)
-
谢谢了！是oracle 8i 在hp unix上
-shanbuzhuan(山不转);
2005-3-11
(#2172082@0)
-
index当然有啊，关键是每天以3万多条的数据增加，几年下来，那不是很可怖吗，又要保证查询速度。不知道你的index有什么特别的吗？
-shanbuzhuan(山不转);
2005-3-11
(#2172095@0)
-
speed is not an issue. space is.
-aka(棒棒);
2005-3-11
(#2172134@0)
-
真的啊。。
-shanbuzhuan(山不转);
2005-3-11
(#2172171@0)
-
Zen De. But should not worry about either of them! You made me think of a fortune - "Why make it simple and easy when you can make it complecated and wonderful?" Good luck, let it grow, let it grow, let it grow..
-aka(棒棒);
2005-3-11
(#2172200@0)
-
space不值钱啊，4年前机器是200多G已经很了不得了，现在是以T来记。
-thisunreal(饭得志);
2005-3-11
(#2172225@0)
-
有些机器的硬盘贵的要死。
-aka(棒棒);
2005-3-11
(#2173254@0)
-
SAN
-handd(大熊猫®);
2005-3-11
(#2173289@0)
-
what kind of query? full table scan? or lightweight query
-647i(#2153402);(#2323);
2005-3-11
(#2173081@0)
-
I have some tables holding over 100M rows. And my query still can be done within 1 sec. But the info you provided is not enough to tune it.Such as:
What kind of query is going to be run (pre-defined, or ad hoc)?
-handd(大熊猫®);
2005-3-11
{73}
(#2172126@0)
-
是pre-defined, 有select and join and group based on the different conditions
-shanbuzhuan(山不转);
2005-3-11
(#2172167@0)
-
你可以作一下几件是：Get a explain plan based on your pre-defined select statement
Try to use unique index or bitmap index
If function based condition is used, build a function based index.
Try different hints in your select statement.
Try to partition your table.
-handd(大熊猫®);
2005-3-11
{247}
(#2172290@0)
-
太感谢拉。真是牛啊。。
-shanbuzhuan(山不转);
2005-3-11
(#2172620@0)
-
你可以当系统休息的时候，运行Gather database/schema/database statistics, 如果80-90%的参数运行时间长的话，可以减到40-50%， 甚至是10-20%，一般可以放在深夜进行。
-vetra(piyupiyu);
2005-3-12
(#2174395@0)
-
more actions worth tryingthough application coding has the most impact on query performance, tunning the io can make big diffence:
* depend on the server's configuration, io slaves maybe help.
* physically spearate data from index tablespace, as well as online redo log.
* use raw device.
* hash partition.
-dotod(Hewllet Greger);
2005-3-12
{286}
(#2174482@0)
-
能给个例子吗？
-shanbuzhuan(山不转);
2005-3-11
(#2172179@0)
-
和查询的种类也有关,是直接查询还是统计(Aggregate)查询，是前者则建立合理的索引,是后者就应该考虑建立数据仓库数据库
-lica(MAG);
2005-3-11
(#2172276@0)
-
建立合理的索引，做表分区，使用不同的表空间，将数据文件放在不同的分区上平均I/O操作。最重要的就是要做表分区，每个月或者每两个月的数据可以放在一个分区上。
-hard20(hard20);
2005-3-11
(#2172409@0)
-
谢谢了。能给个例子，或者是source code 什么的具体点的。。
-shanbuzhuan(山不转);
2005-3-11
(#2172637@0)
-
我的是Aggregate 查询，自己做的dataware house,总是担心数据量太大，Performance 受影响。。
-shanbuzhuan(山不转);
2005-3-11
(#2172628@0)
-
数据仓库结构定义很重要, DIMENSION和Measure的合理对于减少数据大小很有影响,如果每天3万记录是Transaction记录的话建议设定Trigger程序更新数据仓库,同时针对数据仓库做优化
-lica(MAG);
2005-3-11
(#2172711@0)
-
可以用任何ETL作更新，但是最好不要用TRIGGER作类似ETL的事。
-handd(大熊猫®);
2005-3-11
(#2172725@0)
-
Trigger最适合Transaction程序向数据仓库提供统计信息,因为每次输入一条记录本来就要经过很多验证,通过后利用最后的Trigger产生一个中间统计数据库,然后晚上批更新总数据库
-lica(MAG);
2005-3-11
(#2172764@0)
-
我们有cron job 去update 数据库
-shanbuzhuan(山不转);
2005-3-11
(#2172742@0)
-
如果你的DW的FACT TABLE太大，而且每天只UPDATE一两次，你可以将AGGREGATE查询做成MATERIALIZED VIEW。
-handd(大熊猫®);
2005-3-11
(#2172716@0)
-
没错，我就是担心Fact table 太大，MATERIALIZED VIEW没用过，这个view 我是不是每天都得新建啊。。能加快Performance吗。
-shanbuzhuan(山不转);
2005-3-11
(#2172730@0)
-
MV的好处是它的结果可以存储下来以备查询，所以用户的查询就针对这个MV而不是FACT TABLE，MV定义后可以定时更新，但如果更新过於频繁就会占用过多的资源，所以对DW(每天更新的次数少)很适用。
-handd(大熊猫®);
2005-3-11
(#2172751@0)
-
我在使用MV过程中感觉总是不太灵活,还不如建立程序更新DataMart FACT Table来的灵活和有效,如果分析报表多样的话就必须借助OLAP分析工具.
-lica(MAG);
2005-3-11
(#2172743@0)
-
问一下，自己dataware house, 如何解决granularity啊，我的最小到分钟 。
-shanbuzhuan(山不转);
2005-3-11
(#2172789@0)
-
你是指数据仓库在时间纬度上要Granularity到分钟吗?倒是挺有挑战性的.
-lica(MAG);
2005-3-11
(#2172809@0)
-
就是啊。。
-shanbuzhuan(山不转);
2005-3-11
(#2172813@0)
-
那么加上时间到分钟，还能用MV 吗？
-shanbuzhuan(山不转);
2005-3-11
(#2172793@0)
-
除了熊猫外，其它几个人都应好好认真地去读一下Kimball的Data warehouse书。
-sosad(ROLIA森林的故事);
2005-3-11
(#2172833@0)
-
呵呵，要看你是查1条还是很多条数据了，我以前写的OCI(Oracle Call Interface)，1千万条记录中查1条记录只需要1.2ms(千分之一秒)查1条记录问题不大的，就算是几千万数据，只要做好索引就可以了，这个和ORACLE里面的B TREE算法有关
如果是查询多条记录而且不是经常查询的，那么你就用ORACLE里面的PARTITION + LOCAL PARTITION INDEX，这些在ORACLE自带的文档里面有例子。另外你的表插入速度才几秒钟一条，是不需要考虑INDEX对插入速度有影响的。
我以前用C++，PRO*C+OCI为一个计费模块的数据仓库写过一个ETL工具，类似SQL PLUS，每天在北京节点装载1200万条计费记录都没问题。
-henryxy(亨利大帝);
2005-3-11
{420}
(#2173038@0)
-
就这也号称，“有一个很大的database table ”，每天才3万条，要是在7年前还可以是新闻
-houseless(糊涂);
2005-3-12
(#2175393@0)
-
5年前，俺在密西沙加support oracle 7.3, 一半table size 都在 35 GB
-houseless(糊涂);
2005-3-12
(#2175413@0)
-
俺现在支持的库里10%的table size 350 GB，data 270 GB，index 80 GB。共1，735，754，152条记录，这还不是最大的表。每天的输入量为500，000到1，000，000条记录的replication
-houseless(糊涂);
2005-3-12
(#2175453@0)
-
俺这里共36个库，最小的200GB，最大的998GB，就这，俺都不敢称“很大”二字，因为美国那里有好几个5000GB数据库，一个表里有好几百billion记录
-houseless(糊涂);
2005-3-12
(#2175476@0)
-
##俺们这里近2billion条数据表的查询都没超过2分钟，所以请楼主，不要忧天，也不要再提什么“很大”的table，你那个table太正常了。
-houseless(糊涂);
2005-3-12
(#2175518@0)
-
你花五篇文章来炫耀自己ORACLE里面的数据量，还不如说说你是怎样做优化的
-henryxy(亨利大帝);
2005-3-12
(#2175548@0)
-
人家就是担心table太大了，又没有问优化什么，搞什么搞，有没有搞清爽，
-houseless(糊涂);
2005-3-12
(#2175592@0)