????以前上學的時候數(shù)據(jù)庫學的是皮毛中的皮毛，唯一的課程設(shè)計也只是跑幾個簡單得很得SQL語句而已。無論是數(shù)據(jù)庫設(shè)計，還是SQL語句的各種經(jīng)典寫法和強大功能都沒有怎么好好地研究過。
??????? 功能上的學習都不全面，就更不要提性能、安全和大數(shù)據(jù)量等等在實際應用中會遇到的問題勒。參與的一個項目中，就涉及到比較大量的數(shù)據(jù)量的處理和存儲（當然處理大數(shù)據(jù)量就是另外一個問題勒）。加之分配給數(shù)據(jù)庫所在的磁盤空間相當有限，造成了非常捉襟見肘的局面。
??????? 幻想著有朝一日可以不為這些事情煩惱，像google,sina一樣，用幾十上百臺配置一般的機器連起來也能作為一個強壯的server。
從網(wǎng)上看到一些關(guān)于存儲海量數(shù)據(jù)的討論：
1、分表、分數(shù)據(jù)庫
根據(jù)一定的規(guī)則把不同的數(shù)據(jù)庫表分開
缺點：有一定風險，因為一旦分開存放的兩個數(shù)據(jù)庫表有朝一日需要“聯(lián)表”操作，那么就郁悶了，而且最好是把幾個數(shù)據(jù)量大的表分開，單獨拎出來幾個小表意義很不大，而且業(yè)務(wù)邏輯層的代碼需要知道自己要處理的數(shù)據(jù)存在哪個服務(wù)器里，有一點兒奇怪。
例如：（來自ball_lei）
??????? 我現(xiàn)在采用的架構(gòu)采用數(shù)據(jù)庫群的方式，每個客戶的數(shù)據(jù)單獨存在一臺數(shù)據(jù)庫服務(wù)器上，所有的客戶根據(jù)一定的規(guī)則安排存放的數(shù)據(jù)庫服務(wù)器，在主數(shù)據(jù)庫服務(wù)器上有一張-索引表保存客戶與數(shù)據(jù)庫服務(wù)器的對應關(guān)系，每臺數(shù)據(jù)庫服務(wù)器中用于存放這些數(shù)據(jù)的表按照月份分成12張，每張存放當月的全部客戶的數(shù)據(jù)，目前計算出單臺服務(wù)器-單表需要容納9億條數(shù)據(jù)，并且每臺服務(wù)器在這種方式下可以容納10000個客戶的數(shù)據(jù)，以后客戶數(shù)量增加時只需要增加數(shù)據(jù)庫服務(wù)器即可。
??????? 程序邏輯，我采用業(yè)務(wù)邏輯層的概念，對外提供應用服務(wù)器接口，全部的客戶端通過應用服務(wù)器接口進行業(yè)務(wù)運算，應用服務(wù)器我也采用服務(wù)器群的概念，有一個主的應用服務(wù)器，有幾個副應用服務(wù)器，全部客戶端只知道該主應用服務(wù)器的地址，上線時登陸主應用服務(wù)器，然后主應用服務(wù)器根據(jù)各臺應用服務(wù)器的負載情況返回給客戶端真正的登陸地址（副應用服務(wù)器的地址），然后客戶端再登陸到上面進行業(yè)務(wù)處理，每臺應用服務(wù)器都能夠訪問各臺數(shù)據(jù)服務(wù)器進行數(shù)據(jù)提取。
問題：需要每臺應用服務(wù)器都配備一個公網(wǎng)ip么，還是有其他的方式可以只需要一個公網(wǎng)ip可以給全部的服務(wù)器公用？Nat能夠?qū)崿F(xiàn)么？或者能否進行更好的負載均衡，就是客戶端的各種業(yè)務(wù)都可以在不同的服務(wù)器上運算
改進：
用戶規(guī)則配置應該不大，所以也可以做成配置一次Load到內(nèi)存中。
如此大數(shù)據(jù)量的項目竟不用Oracle,實在讓人費解。我現(xiàn)在的月數(shù)據(jù)量大概2.5億，用了3臺HP
SUPERDEMO,9個CUSTERMOR DB。其中一個CATALOG數(shù)據(jù)庫，相當于你的客戶索引。
你的插入操作很多，所以建議少建幾個索引，其實一些業(yè)務(wù)完全可以在數(shù)據(jù)庫中完成，通過觸發(fā)器，約束和存儲過程，這樣性能會有大的提高。大數(shù)據(jù)的表，分區(qū)的確是必須的，當然，還需要更完善的維護計劃，否則很容易，你的業(yè)務(wù)可能就會因為性能問題掛起了。
1、通過（數(shù)據(jù)庫+文件)方式進行數(shù)據(jù)存儲
2、集群方案
還有當初選修的“分布式數(shù)據(jù)庫”，不知道這個概念是不是能夠活生生的用到項目中來。。。