金融行業(銀行、保險、資產管理公司等)存儲海量的圖片一般是使用商業影像存儲方案：IBM的CM，FileNet，EMC 的DocumentuM；互聯網公司，大多是使用開源的分布式文件系統：FastDFS、TFS、MogileFS等
千萬人同時訪問的網站，一般是有很多個數據庫同時工作，說明白一點就是數據庫集群和並發控制，這樣的網站實時性也是相對的。這些網站都有一些共同的特點：數據量大，在線人數多，並發請求多，pageview高，響應速度快。總結了一下各個大網站的架構，主要提高效率及穩定性的幾個地方包括：1、程序
程序開發是一方面，系統架構設計（硬件+網絡+軟件）是另一方面。軟件架構方面，做網站首先需要很多web服務器存儲靜態資源，比如圖片、視頻、靜態頁等，千萬不要把靜態資源和應用服務器放在一起。一個好的程序員寫出來的程序會非常簡潔、性能很好，一個初級程序員可能會犯很多低級錯誤，這也是影響網站性能的原因之一。
網站要做到效率高，不光是程序員的事情，數據庫優化、程序優化這是必須的，在性能優化上要數據庫和程序齊頭並進！緩存也是兩方面同時入手。第一，數據庫緩存和數據庫優化，這個由dba完成（而且這個有非常大的潛力可挖，只是由於我們都是程序員而忽略了他而已）。第二，程序上的優化，這個非常的有講究，比如說重要一點就是要規范ＳＱＬ語句，少用in 多用or，多用preparestatement，另外避免程序冗余如查找數據少用雙重循環等。另外選用優秀的開源框架加以支持，我個人認為中后台的支持是最最重要的，可以選取spring＋ibatis。因為ibatis直接操作SQL並有緩存機制。spring的好處就不用我多說了，ＩＯＣ的機制可以避免new對象，這樣也節省開銷。據我分析，絕大部分的開銷就是在NEW的時候和連接數據庫時候產生的，請盡量避免。另外可以用一些內存測試工具來做一個demo說明hibernate和ibatis誰更快！前台你想用什么就用什么，struts,webwork都成，如果覺得自己挺牛X可以試試用tapestry。用數據庫也未必不能解決訪問量巨大所帶來的問題，作成靜態文件硬盤的尋址時間也未必少於數據庫的搜索時間，當然對資料的索引要下一翻工夫。我自己覺得門戶往往也就是當天、熱門的資料點擊率較高，將其做緩存最多也不過1~2G的數據量吧，舉個例子：◎ 拿網易新聞來說 http://news.163.com/07/0606/09/3GA0D10N00011229.html
格式化一下，方便理解：http://域名/年/月日/新聞所屬分類/新聞ID.html
可以把當天發布的、熱門的、流攬量大的作個緩寸，用hashtable（key：年-月-日-分類-ID，value：新聞對象），靜態將其放到內存（速度絕對快過硬盤尋址靜態頁面）。通常是采用oracle存儲過程＋2個weblogic，更新機制也幾乎一樣每簽發一條新聞，就會生成靜態頁面，然后發往前端的web服務器，前端的web都是做負載均衡的。另外還有定時的程序，每5-15分鍾自動生成一次。在發布新聞的同時將數據緩存。當然緩存也不會越來越大，在個特定的時間段（如凌晨）剔除過期的數據。做一個大的網站遠沒有想象中那么簡單，服務器基本就要百十個的。這樣可以大大增加一台計算機的處理速度，如果一台機器處理不了，可以用httpserver集群來解決問題了。2、網絡
中國的網絡分南北電信和網通，訪問的ip就要區分南北進入不同的網絡。3、集群通常會使用CDN與GSBL與DNS負載均衡技術，每個地區一組前台服務器群，例如：網易，百度使用了DNS負載均衡技術，每個頻道一組前台服務器，一搜使用了DNS負載技術，所有頻道共用一組前台服務器集群。網站使用基於Linux集群的負載均衡，失敗恢復，包括應用服務器和數據庫服務器，基於linux-ha的服務狀態檢測及高可用化。
應用服務器集群可以采用apache+tomcat集群和weblogic集群等；web服務器集群可以用反向代理，也可以用NAT的方式，或者多域名解析都可以；Squid也可以，方法很多，可以根據情況選擇。4、數據庫因為是千萬人同時訪問的網站，所以一般是有很多個數據庫同時工作的，說明白一點就是數據庫集群和並發控制，數據分布到地理位置不同的數據中心，以免發生斷電事故。另外還有一點的是，那些網站的靜態化網頁並不是真的，而是通過動態網頁與靜態網頁網址交換做出現的假象，這可以用urlrewrite這樣的開源網址映射器實現。這樣的網站實時性也是相對的，因為在數據庫復制數據的時候有一個過程，一般在技術上可以用到hibernate和ecache，但是如果要使網站工作地更好，可以使用EJB和websphere，weblogic這樣大型的服務器來支持，並且要用oracle這樣的大型數據庫。
大型門戶網站不建議使用Mysql數據庫，除非你對Mysql數據的優化非常熟悉。Mysql數據庫服務器的master-slave模式，利用數據庫服務器在主從服務器間進行同步，應用只把數據寫到主服務器，而讀數據時則根據負載選擇一台從服務器或者主服務器來讀取，將數據按不同策略划分到不同的服務器（組）上，分散數據庫壓力。
大型網站要用oracle，數據方面操作盡量多用存儲過程，絕對提升性能；同時要讓DBA對數據庫進行優化，優化后的數據庫與沒優化的有天壤之別；同時還可以擴展分布式數據庫，以后這方面的研究會越來越多； 如果我來設計一個海量數據庫，可能首先考慮的就是平行擴容性，原因很簡單，我沒有辦法預估將來的數據規模，那我也就沒有邊界可言，因此，基本上首選dbm類哈希型數據庫，甚至，對於實時性要求很高的數據庫，可能會自行設計庫。 當我們使用業務描述腳本、事務批處理機、目錄服務、底層存取來划分一個數據庫系統之后，其實，所謂的海量數據需求，也就不是那么難辦到了。 嗯，這樣還有一個額外的好處，就是由於平行擴容性很好，因此，前期可以以較低成本搭建一個簡單的架子，后期根據業務量逐出擴容。這對很多企業來說，就是入門門檻很低，便於操作，且商業風險也小。MySQL比起動輒幾十萬美金，搭建豪華的Oracle平台，成本低多了。