天天:html
1) 消息量:發送和接收的消息數超過60億算法
2) 將近1000億條數據的讀寫apache
3) 高峯期每秒150萬左右操做數組
4) 總體讀取數據佔有約55%,寫入佔有45%服務器
5) 超過2PB的數據,涉及冗餘共6PB數據網絡
6) 數據每個月大概增加300千兆字節。數據結構
在平常生活中,包括在設計計算機軟件時,咱們常常要判斷一個元素是否在一個集合中。好比在字處理軟件中,須要檢查一個英語單詞是否拼寫正確(也就是要判斷它是否在已知的字典中);在 FBI,一個嫌疑人的名字是否已經在嫌疑名單上;在網絡爬蟲裏,一個網址是否被訪問過等等。最直接的方法就是將集合中所有的元素存在計算機中,遇到一個新元素時,將它和集合中的元素直接比較便可。通常來說,計算機中的集合是用哈希表(hash table)來存儲的。它的好處是快速準確,缺點是費存儲空間。當集合比較小時,這個問題不顯著,可是當集合巨大時,哈希表存儲效率低的問題就顯現出來了。好比說,一個像 Yahoo,Hotmail 和 Gmai 那樣的公衆電子郵件(email)提供商,老是須要過濾來自發送垃圾郵件的人(spamer)的垃圾郵件。一個辦法就是記錄下那些發垃圾郵件的 email 地址。因爲那些發送者不停地在註冊新的地址,全世界少說也有幾十億個發垃圾郵件的地址,將他們都存起來則須要大量的網絡服務器。若是用哈希表,每存儲一億個 email 地址, 就須要 1.6GB 的內存(用哈希表實現的具體辦法是將每個 email 地址對應成一個八字節的信息指紋googlechinablog.com/2006/08/blog-post.html,而後將這些信息指紋存入哈希表,因爲哈希表的存儲效率通常只有 50%,所以一個 email 地址須要佔用十六個字節。一億個地址大約要 1.6GB, 即十六億字節的內存)。所以存貯幾十億個郵件地址可能須要上百 GB 的內存。除非是超級計算機,通常服務器是沒法存儲的。jsp
布隆過濾器只須要哈希表 1/8 到 1/4 的大小就能解決一樣的問題。函數
Bloom Filter是一種空間效率很高的隨機數據結構,它利用位數組很簡潔地表示一個集合,並能判斷一個元素是否屬於這個集合。Bloom Filter的這種高效是有必定代價的:在判斷一個元素是否屬於某個集合時,有可能會把不屬於這個集合的元素誤認爲屬於這個集合(false positive)。所以,Bloom Filter不適合那些「零錯誤」的應用場合。而在能容忍低錯誤率的應用場合下,Bloom Filter經過極少的錯誤換取了存儲空間的極大節省。post
下面咱們具體來看Bloom Filter是如何用位數組表示集合的。初始狀態時,Bloom Filter是一個包含m位的位數組,每一位都置爲0,如圖
爲了表達S={x1, x2,…,xn}這樣一個n個元素的集合,Bloom Filter使用k個相互獨立的哈希函數(Hash Function),它們分別將集合中的每一個元素映射到{1,…,m}的範圍中。對任意一個元素x,第i個哈希函數映射的位置hi(x)就會被置爲1(1≤i≤k)。注意,若是一個位置屢次被置爲1,那麼只有第一次會起做用,後面幾回將沒有任何效果。如圖9-6所示,k=3,且有兩個哈希函數選中同一個位置(從左邊數第五位)。
在判斷y是否屬於這個集合時,咱們對y應用k次哈希函數,若是全部hi(y)的位置都是1(1≤i≤k),那麼咱們就認爲y是集合中的元素,不然就認爲y不是集合中的元素。如圖9-7所示y1就不是集合中的元素。y2或者屬於這個集合,或者恰好是一個false positive。
爲了add一個元素,用k個hash function將它hash獲得bloom filter中k個bit位,將這k個bit位置1。
· 爲了query一個元素,即判斷它是否在集合中,用k個hash function將它hash獲得k個bit位。若這k bits全爲1,則此元素在集合中;若其中任一位不爲1,則此元素比不在集合中(由於若是在,則在add時已經把對應的k個bits位置爲1)。
· 不容許remove元素,由於那樣的話會把相應的k個bits位置爲0,而其中頗有可能有其餘元素對應的位。所以remove會引入false negative,這是絕對不被容許的。
布隆過濾器決不會漏掉任何一個在黑名單中的可疑地址。可是,它有一條不足之處,也就是它有極小的可能將一個不在黑名單中的電子郵件地址斷定爲在黑名單中,由於有可能某個好的郵件地址正巧對應一個八個都被設置成一的二進制位。好在這種可能性很小,咱們把它稱爲誤識機率。
布隆過濾器的好處在於快速,省空間,可是有必定的誤識別率,常見的補救辦法是在創建一個小的白名單,存儲那些可能個別誤判的郵件地址。
布隆過濾器具體算法高級內容,如錯誤率估計,最優哈希函數個數計算,位數組大小計算,請參見http://blog.csdn.net/jiaomeng/article/details/1495500。
2017年8月22日凌晨2點左右,HBase發佈了2.0.0 alpha-2,相比於上一個版本,修復了500個補丁,咱們來了解一下2.0版本的HBase新特性。
最新文檔:
http://hbase.apache.org/book.html#ttl
官方發佈主頁:
舉例:
1) region進行了多份冗餘
主region負責讀寫,從region維護在其餘HregionServer中,負責讀以及同步主region中的信息,若是同步不及時,是有可能出現client在從region中讀到了髒數據(主region還沒來得及把memstore中的變更的內容flush)。
2) 更多變更