首先聲明，這篇文章是我整理所得，裏邊有很多地方嚴格的奉行了魯迅先生的拿來主義……，之所以還厚着臉皮的放在這裏，目的就是拋磚引玉，放出問題，供大家一起討論！
應用場景：大數據量處理是指同時需要對數據進行檢索查詢，同時有高併發的增刪改操作，數據量到達百萬級；
有過數據庫經驗的人都知道，有時候查詢幾百萬條數據，一個檢索查詢可以讓你等幾分鐘，這對於數據庫開發人員來說，無疑是無法忍受的；
現在我是想探討下對大數據量的處理，主要包括怎樣處理大數據量，加快增刪改查得速度，提高數據庫性能，試想：騰訊，新浪，百度，動輒數以億計的帳號,數據量的該有多大呀，對於這麼大的數據量，查詢速度怎麼這麼快呢，他們在使用什麼樣的方法？
於是我總結了互聯網現在對數據處理的發展階段。對於大數據量處理，如果是互聯網處理的話，一般分爲下面幾個階段：
第一階段，所有數據都裝入一個數據庫，當數據量大了肯定就會出現問題，就像剛剛說的查詢比較慢的問題。
於是大家開始想辦法，這就到了第二階段：
第二階段，那時肯定想做緩存機制，確實使用緩存可以如加上緩存Memcached，可以提高性能，減少數據庫服務器的壓力，但緩存也是治標不治本的，數據量太大了還會是一個很大的問題。
於是到了第三階段：
第三階段，也就是使用master-slave模式，也即主從數據庫，master提供寫，slave進行讀，這個適合於由寫造成數據庫性能下降的方法，並不能解決所有的問題。
這不，人們又想到了第四個階段：
第四階段，垂直分庫，這個可以解決一定的問題，把數據庫的表分在不同的服務器上，但是這也並不能解決所有的問題，有時候個別表的數據量還是增加的比較快的，查詢性能一樣是一個問題，並且其中一個服務器Down了系統都會出問題。
所以，又到了第五階段：
第五階段，進行水平分庫，這個不錯，記得以前也是嘗試過按這個分時間水平分庫，這樣的確是個不錯的方法，其實可以分的更細點估計效果更好，但是多個數據庫的管理也將是一個問題，但是這個問題還不大。
令人驚喜的是，現在又到了NoSQL階段：
第六階段，用NoSQL做了，關於NoSQL怎麼做可以參考Google的bigtable，相關的系統的知識，網上現在也有很多，我會在下邊簡單的聊聊NoSQL。
至於：
第七階段：……，還沒出來，你我都可以續寫！
下邊就試着探討NoSQL對大數據量的處理：
NoSQL就是將寫操作在內存中進行，定時或按某一條件將內存中的數據直接寫到磁盤上，一定程度上是解決了數據的訪問速度問題，解決了高併發讀寫以及海量數據訪問的問題，但是從數據庫橫向擴展性的 CAP理論來說，NoSQL是犧牲了一致性，只是做到了AP，沒有保證數據的一致性C，一致性只是保證了最終一致性，這是他的一個缺點，另外，還有以下的缺點：
1，當機器掛了數據將會丟失，這個可以可以考慮共享內存解決。
2，內存的限制,內存有限當寫數據操作太大的時候內存也會爆。
解決：Bigtable的做法是通過bloom-filter算法合併掉相同的操作，比如UPDATE A='A' ，update A='B'時可以直接合並了，當然這個只是儘量的減少內存爆的問題，並不能避免。
基本理論基礎 NoSQL理論基礎：把內存當成是新的硬盤，硬盤當成是新的磁盤。
這只是拋磚引玉，歡迎大家補充!
關係型數據庫都要實現事務ACID特效即:原子性(Atomicity), 一致性(Consistency), 隔離性(Isolation),持久性(Durability) 。
CAP理論：Consistency 一致性 ，Availability -可用性 ，Partition -容錯性