大數據量處理的幾種方法

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查詢等