当前在线人数11352
首页 - 分类讨论区 - 电脑网络 - 数据库版 -阅读文章
未名交友
[更多]
[更多]
文章阅读:Re: question on large tables (>=800 million records, 10 G
[同主题阅读] [版面: 数据库] [作者:babycry] , 2007年01月20日09:18:58
babycry
进入未名形象秀
我的博客
[上篇] [下篇] [同主题上篇] [同主题下篇]

发信人: babycry (babycry), 信区: Database
标  题: Re: question on large tables (>=800 million records, 10 G b
发信站: BBS 未名空间站 (Sat Jan 20 09:18:58 2007)


Question # 1:

Why build a customized B-tree/Hash table ?
How is it different from the B-tree implementation in a database server?
Why the B-tree/Hash table implemented in mysql server is NOT good ?
How can a customized B-tree/Hash table benefit ?

Somebody cannot drive a car from Boston to S.F. in one hour
does not necesserily mean you can do it if you drive by yourself.


Question # 2:

How upgrading hardware will make the application faster ...
say from 5 minutes per query to 1 minute per query ?
Is it because the CPU is 5 times faster from dual 800 Mhz to 8Ghz?
Is it because the disk access is faster, from 10k rpm SCSI hard drive
to 50k rpm hard drive, or some kind of RAID ?
Is it because the front bus bandwidth is larger, from 166Mhz to 830Mhz ?
Or is it because the video card is better and more expensive ?

(The questions are tailored with the reasoning of the previous post,
and is just for making a joke. I aim at nobody, and am just talking about
the previous post.)

Question # 3:

What is the largest size of the tables the author of the previous post have
ever met ?
What should be the query performance of your 10G tables ?
Why do the performances of algorithms for a large table is the same
as those for a small table ? Any useful proofs/calculations/evidence beyond
" I feel so ..." ?


As I said, doing an experiment with 800M records by yourself is the best way
to understand the question.

Concerning hardware: We are not rich. We are not upgrade-mania.


【 在 wyr (遗忘小资) 的大作中提到: 】
: I do not quite catch what you guys are discussing here,
: you are just saying that you have a 800M record table with no active
insert/
: update/delete and you want to query it by PK?
: 800M line does not sound like a extremely huge one consider your data file
: is
: only 10G.
: If you just want to find result, then you may build a customized B-Tree to
: store your PK . You can easily implement parition or hash here to help
: compress the tree, right? With this implementation, you can shrink the
: physicalsize of your index file(s)
: ...................



--

※ 来源:·BBS 未名空间站 http://mitbbs.com·[FROM: 18.251.]

[上篇] [下篇] [同主题上篇] [同主题下篇]
[转寄] [转贴] [回信给作者] [修改文章] [删除文章] [同主题阅读] [从此处展开] [返回版面] [快速返回] [收藏] [举报]
 
回复文章
标题:
内 容:

未名交友
将您的链接放在这儿

友情链接


 

Site Map - Contact Us - Terms and Conditions - Privacy Policy

版权所有,未名空间(mitbbs.com),since 1996