bloom-filter 算法
場景：我說的大數據量處理是指同時需要對數據進行檢索查詢，同時有高並發的增刪改操作；
記得以前在XX做電力時，幾百萬條數據，那時一個檢索查詢可以讓你等你分鍾；
現在我是想探討下對大數據量的處理，那時我就在想例如騰訊，盛大，動輒數以億計的帳號,怎么能這么快呢， 於是找到了互聯網現在對數據處理的發展：
對於大數據量處理，如果是互聯網處理的話，一般分為下面階段：
第一階段，所有數據都裝入一個數據庫，當數據量大了肯定就會出現問題，就像剛剛說的查詢，於是想辦法
第二階段，那時肯定想做緩存機制，確實可以如加上緩存Memcached，但緩存也是治標不治本，數據量太大了也是不行於是
第三階段，master-slave模式，進行主從數據庫，master提供寫，slave進行讀，這個適合於有寫造成數據庫卡的方法，XX那個還是不行，於是
第四階段，垂直分庫，這個意義還是不大，對於這種采集數據的，於是
第五階段，進行水平分庫，這個不錯，記得以前從興也是按這個分時間水平分庫，其實可以分的更細點估計效果更好
補充一個階段,應該還有一個階段是內存數據庫的階段，內存數據庫只是復雜的關系處理和事務等，電信計費等很多都用這個
第六階段，用nosql做了，關於nosql怎么做可以參考google的bigtable
其實本文主要目的也是想探討nosql對大數據量的處理：
NOSQL就是將寫操作在內存中進行，定時或按某一條件將內存中的數據直接寫到磁盤上，一定基礎上是解決了
nosql 主要解決了：
1，高並發讀寫的需求
2，海量數據訪問的需求
3，數據庫橫向擴展性的需求
CAP理論來說，nosql是犧牲了一致性，做到了AP，一致性只是保證了最終一致性
缺點也很明顯：
1，當機器掛了數據將會丟失
解決：可以考慮共享內存
補充1：其實這里可以展開了講,一種是通過共享內存來實現
集群內存：根據的是Quorum NRW理論,比如你有N台機子用來集群，每次你進行讀寫數據時可以至少要同步到X個節點才算成功，所以你每次讀數據時只需要讀大於N-X個節點就能保持你的正確率，其實就是對數據進行的冗余備份，不過我們存的是內存，相對於直接的磁盤操作，跨網絡進行內存操作可以更快；
其實還一種保證數據一致性，就是記錄日志，當數據每次寫操作內存時都進行日志記錄，然后再在內存中進行寫操作，至少很多數據庫就是這樣做的，如redis
2，內存的限制,內存有限當寫數據操作太大的時候內存也會爆
解決：Bigtable的做法是通過bloom-filter算法合並掉相同的操作，比如UPDATE A='A' ，update A='B'時可以直接合並了
---------------------------------
基本理論基礎
nosql理論基礎：內存是新的硬盤，硬盤是新的磁盤
NOSQL探討
關系型數據庫都要實現事務ACID特效即:原子性(Atomicity), 一致性(Consistency), 隔離性(Isolation), 持久性(Durability)
CAP理論
Consistency 一致性
Availability -可用性
Partition -容錯性
-------------------------------
拋磚引玉而已，如果有什么經驗歡迎分享，我將持續關注大數據量處理
大多數NoSQL數據庫都不支持事務,不支持SQL等，所以還是得保留關系型數據庫
現在有人提到用內存數據庫， 總體如果是簡單業務來說，NOSQL的速度比內存數據庫更快，但NOSQL最大缺點，不支持事務，不支持SQL查詢等