数据库方案求助

暂时想到这些，但是都不理想，不是服务器压力过重就是数据量太大
请帮个忙看看



服务器推荐：
一）web服务器：linux + apache + tomcat + j2sdk1.5
二）数据库服务器：linux + orcale

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

方案一（数据库保存所有服务器索引信息）

全对称结构，没有中央服务器

web方案：
只从本地数据库检索符合条件的记录，给出结果
每次检索都要从本地服务器的海量数据中进行

数据库方案：
数据库保存所有服务器的索引内容
缓存命中率高的记录，减少检索时间

服务器负载分析：

服务器负载假设：
一百个结点，每结点一百人同时使用，每个结点一万条记录
web服务器：同时一百线程在本地数据库服务器检索
数据库服务器：每次接收一百个查询请求；每个请求要从一百万条索引中检索（最坏的情况）；缓冲机制可以稍微减轻负担

数据更新操作：
同时更新所有数据库/只更新本地，服务器间相互同步








方案二（数据库保存本地索引及少量缓冲）

所有结点全对称结构，网络中没有一个中央服务器

web方案：
接收到请求时同时多线程向其它服务器同时搜索（服务器压力问题？）

数据库方案：
数据库保存本地数据
数据库保存一定量缓冲数据，

服务器负载分析：


服务器负载假设：
一百个结点，每结点一百人同时使用
则每个web服务器同时发起一万个线程向其它数据服务器搜索（oops!）
每个数据库服务器会同时接收到一万个查询请求（oops！）
采用学习过程只能少量减少查询请求和web服务器搜索线程

数据更新操作：
只更新本地





方案三（中央服务器方案一）

每结点结构相同，连接到同一个中央服务器

web方案
每个查询向中央服务器进行，由中央服务器实行检索，中央服务器返回检索结果

数据库方案
中央数据库保存所有索引信息
每结点可以只用小型数据库保存本地用户和其它信息即可

服务器负载分析：

服务器负载假设：
一百个结点，每结点一百人同时使用，每结点资料记录一万条
web服务器：同时发起一百个进程向中央数据库查询
数据库服务器（中央）：同时接收一万条查询请求并返回大容量结果
数据库服务器（结点）：少量工作

数据更新操作：
只更新中央服务器


方案四（中央服务器方案二）

每结点结构相同，连接到同一中央服务器

web方案：
每个查询向中央服务器进行，由中央服务器根据查询内容进行转发到结点数据库，再由结点数据库返回结果

数据库方案：
中央服务器保存各结点分类信息，根据页面请求的分类转发查询到相应服务器

服务器负载分析：

服务器负载假设：
一百个结点，每结点一百人同时使用，每结点资料记录一万条，每结点一百个类别
web服务器：同时一百个进程向中央数据库查询
数据库服务器（中央）：同时接收一万条请求并转发
数据库服务器（结点）：从中央服务器接收查询请求，最坏情况下每结点接收到一万条查询请求

数据更新操作：
只更新本地服务器
分类变化时更新中央服务器


--------------------
            [a=http://blog.csdn.net/GOJYO/]向北的路灯灭了.我不知道我是谁.NorTH.Path[/a]
               ~      ???????         幸福是一雙溫暖的紅唇   ?
        幸福的距离遥不可及
       [ 2005-03-30 13:19:11 0000 修改 ]

每个结点的数据都不一样
而且结点个数没有统一规划 --------------------            [a=http://blog.csdn.net/GOJYO/]向北的路灯灭了.我不知道我是谁.NorTH.Path[/a]
               ~      ???????         幸福是一雙溫暖的紅唇   ?
        幸福的距离遥不可及
      

我没说清楚怎么回事 -_-#
情况是这样滴:

整个系统中有多个结点
每个结点有一个WEB服务器,一个数据库服务器和一个文件服务器
大至流程是用户通过WEB页面搜索资料,然后从文件服务器上下载
资料的所在地及数据库的分布对用户透明
每个服务器上所存数据都不一样
而且没有统一安排
不能确定哪人服务器放置哪一类资料------偶只是做,用是别人的事了,偶没权管....T_T
随时可能添加进新的服务器

帮忙想想吧 --------------------            [a=http://blog.csdn.net/GOJYO/]向北的路灯灭了.我不知道我是谁.NorTH.Path[/a]
               ~      ???????         幸福是一雙溫暖的紅唇   ?
        幸福的距离遥不可及
      

不是类似那些下载站？
天空……

数据库服务器集中，文件服务器分布。这取决于网络传输数据量的大小。
你描述的数据查询要求，Oracle没问题，顶多服务器牛X点，实在不行就集群。
如果查询数据量增到很大，估计先撑不住的是你的Tomcat。建议加个应用服务器跑Tomcat，将动态查询发布为静态页面；Web服务器只跑Apache，用来发布静态页面。或者就用Weblogic，但是Weblogic重在配置，配置不好效果还不如Tomcat呢。

已你现在描述，压力还是小意思。中经网、首都之窗、新华网都使用的上面我说的方案，但他们应用服务器里跑的软件有内涵，Cache技术作的非常好，核心数据库用的非关系型数据库，查询效率很高。

不知题意理解的对不对，说得不好瞎说。

--------------------
因我的生命就有若微尘，躺卧于街头或结伴同行，也不介意做个自由人，无必须要紧。
[ 2005-04-02 14:40:43 灭绝师太 修改 ]

：）
数据库服务器也分散
每个结点都一样（一个数据库服务器，一个web服务器，一个文件服务器）──是不是很浪费？

新的办法是
利用缓冲并综合方案一和二。这样差不多了；）
每个web服务器大多数时间只负责本地数据库的查询工作，所以tomcat没问题了
每个数据库大多时间也只负责来自本地的web服务器的查询，数据库压力也下来了

非关系型数据库。。。还不是很了解，编程上难度会增大吧 --------------------            [a=http://blog.csdn.net/GOJYO/]向北的路灯灭了.我不知道我是谁.NorTH.Path[/a]
               ~      ???????         幸福是一雙溫暖的紅唇   ?
        幸福的距离遥不可及