資料量如果這麼大，而且又限定傳回的時間，建議用oracle等級的商業化資料庫，在高階的cluster跟最佳化會有比較好的擴充能力跟支援，硬體當然也要愈高階愈好，而且需要有專門的DBA來規劃及維護資料庫，另外也要考慮concurrent user有多少，基本上這是你有多少預算或者成本效益的問題！

另外如果你的需求是電子商務網站的產品搜尋，也可考慮採用全文檢索的搜尋引擎，因為全文檢索會針對搜尋需要做索引(例倒排索引)，所以會比SQL query來的有效率，也不會用到資料庫的資源，國內的話可以問問看openfind或其他相關做搜尋引擎的廠商

以上這些都可以找相關的廠商或ISV來協助評估或規劃！

以硬體的角度來看 這個東西會牽涉到資料庫的搜尋效能
因此在規劃伺服器的時候請考慮以下的建議規格

1. CPU的時脈愈快愈好 (3.0GHz或以上) 強烈建議四核心以上的CPU, 一顆就好, 除非妳的記憶體很大. AMD的CPU不適合跑database, 所以不考慮
2. 記憶體愈大愈好 (16GB以上, 從記憶體抓資料比從硬碟抓快多了)
3. 一筆資料100KB計算, 一億筆資料相當於要1TB, 圖檔大的話還可能更大,所以建議使用32MB Cache, 500GB以上,7200轉至10000轉企業版的硬碟作磁碟陣列, 磁碟陣列介面卡要用到PCI-e x 8以上的規格.

其他部分是資料庫廠商和網路廠商要去負責的, 這個我不會.

其實我也沒頭緒，不過「美麗程式」這本書有講到MapReduce的概念與實作方法，也許可以參考。

另外就看資料庫廠商的專業意見，他們應該有為這樣的需求提供一些解決方案。另外也許專業的搜尋方案廠商也有類似的解決方案。我想這樣的需求應該不太可能只靠一台硬體做到。

抱歉，幫不上忙。

如果您是用MySql
解決的方式有二種: 如果不怕系統出問題，就是換 MySQL Cluster 5.1 ，再不然就是多增加幾台 Data node 伺服器了。

在硬體的規格上而言
就如tecksin大所建議的
盡量用一些效能較高的硬體規格

至於在資料庫的搜尋上而言
有以下幾點建議

1、DataBase的relationship的建立：
一開始資料庫的建立，各個Table之間的relation，一定要先規劃好
最好把所有的Table全部重覆看幾遍，以確定好之間的relation沒有錯

2、不給條件值，並不代表就是全部
因為你的資料庫裡將來可能會裝有上億筆的資料
在讓使者做搜尋時，有一個要點一定要記得
「不給條件值，並不代表就是全部」
你可以自行指定一些條件值
當user不下條件值，那就給他用default的條件值
否則USER一個不小心按下去，那他只有乾等的份了
要不就是不等了，就給他關了
至於怎麼下default的條件值，我想這就要看個人功力了

3、在搜尋的條件值裡加上一個數量的條件
如果說今天使用者，他所下的搜尋條件
得到的答案是一千筆資料，你相信他真的會看完這一千筆資料
我想看到第100筆就很了不起了
這是要看你的商務網站的服務項目是什麼，自行斟酌

4、在資料庫裡增加一個商品的加權
給商品一個加權指數也是很重要的
多人購買的商品，或是多人點閱的商品
給所有商品建立一些加權指數
當使用者在搜尋時，依據這個指數來決定什麼東西是第一個show出來的
再跟第3項結合，相信一定能減少很多從資料庫裡撈資料的時間..

以上提供給你做參考
若有想到其他的我再行補充..

這個跟應用系統的分析有關係吧,如果我要幫你開發的話,你的需求要清楚的給我,依此分析之後再進行設計,然後再進行coding. 搜尋的效能跟程式怎麼寫有絕對的影響力, 至於資料庫功能或其他硬體方案,能提昇5~10%就相當不錯了.

除了硬體問題外
要注意您所下的 sql
以及您建的index
尤其index特別重要

我的回答可能有些離題了，因為題目問的是資料庫的規劃。
不過如果從資料的使用著手，除了各位高手所提之外，還有一件事情可以加以考量，那就是資料快取(Caching)。
因為資料使用的比例是不一樣的，可能跟資料屬性有關(欄位)，也可能跟商品本身的熱門程度有關，所以設計上我們不需要也不應該一視同仁。最簡單的方式，我們可以將熱門商品的查詢，在第一次查詢的時候就將結果記錄下來，之後同樣的查詢(包含換頁)就可以直接引用上次查詢的結果。甚至我們可以先將部分商品作預先查詢，這樣連第一次查詢的使用者都不需要額外的等待時間。至於快取儲存的地方包含了記憶體、Temporary Table(資料庫)、速度較快的硬碟(如固態硬碟)或檔案，使用上甚至可以同時採用多種快取機制並行。當然，目前很多資料庫都有內建一些快取的機制，不過這部分並不是資料庫的標準，算是特定資料庫本身規劃的一環。
首先要注意的地方是各種快取機制的優缺點(尤其是容量、價格、存/取速度)，據此搭配資料的使用情形做出規劃。除此之外，程式部分也需要加以搭配。像是快取資料的產生時，必須知道哪些資料可以快取，哪些不適合快取(如即時的庫存量)，以免發生顯示過期資料的問題。例如以產品基本資料而言，因為變動機會不高，而且都是必須經過特定的流程才能改變，所以就很適合採用快取的方式。甚至可以直接採用類似上稿的方式，將商品上架時就把基本資料一併存到快取了。另外就像所有的快取機制一樣，必須考慮快取資料有效期限的問題。不同的快取機制與資料屬性，需要不同的管理機制。
最後也是最重要的是，不管在開發的環境或是正式的環境，都應該有一套監測的機制，確保目前資料取得的服務是否達到一定的效能。並在採用新的提升效能方案後，是否產生了預期的效果。效能的問題應該是一項科學，而不是光憑感覺。

1. 將你要儲存的資料先作"正規化".
2. 建立系統的 ERD.
3. 考慮 各資料庫的效能, 管理介面, 擴充性.
4. 建立測試資料.
5. 有錢就做壓力測試(因為一個人可以達到要求, 但網路使用人數增加, 就可能會塞車)
6. 資料庫效能調校.

提供幾個參考資料.
可以對比什麼樣規模的資料庫，需要什麼樣的軟硬體規格
日本7-11的總部情報系統(POS系統）
1992
資料庫：oracle6
資料量：150G
硬體：HP9000/870/HP-UX8.0

1998
資料庫Oracle8
資力量：1TB
硬體：HP9000V2200/HP-UX11

2006
資料庫：Oracle 10g
資料量：15TB
硬體：HP Integrity Superdome(HP-UX11i)

聘請專業 programmer 另作專業規劃...(...that is, 專案處理...)

公司用; 一億筆資料 一筆資料建立 一毛錢 也要 一千萬
用 Oracle 怎會貴 ??
除非資料根本沒價值!!
個人研究用
Oracle Developer Network 歡迎你開發研究 用到爽 不需付一毛錢