如果某一列的取值的維度比較大，則不太適合建立位圖索引。因為位圖索引會非常大, 則不太適合建立點陣圖索了。
但是對於olap框架而言，這個問題時不可避免的，舉例而言，我們需要儲存和統計公司的所有**的訪問記錄，那麼ip的範圍就會比較大。此時如果直接對ip建立位圖索引的話就會導致該索引非常大，不太現實，那麼怎麼辦呢？這就需要對位圖索引進行壓縮了。我們知道，常見的壓縮演算法對資料進行壓縮之後，確實可以減少空間占用，但是當需要使用資料的時候，就需要對資料進行解壓縮，效率不高。對於位圖索引而言，其目的本來就是為了減少資料查詢的處理時間，如果再查詢的時候，需要對索引進行解壓縮，然後再使用的話就不一定能夠提高效率了。所以一般情況下位圖索引的壓縮演算法，會使得索引在使用的時候， 可以不解壓縮就可以直接使用。其原理如下圖所示：
圖中的第一行是點陣圖索引的原始資料，壓縮演算法將位圖索引的原始資料按31位分成若干個字（乙個字是32個bit，這裡按31個bit分有其目的）， 最後的乙個字有可能不足31位，則補充0。 分過之後，再分析每乙個字, 這是有兩種情況：
(1) 該字中的31位不是全為0也不是全為1；
(2) 該字中的31位全為0；
(3) 該字中的31位全為1；
對於這三種情況，壓縮演算法分別有不同的處理方式：
對於情況(1) , 則在其前面補1位1即可，這樣就構成了乙個32位的字;
對於情況(2), 則在其前面首先補1位0, 這個0代表該字全為0或者全為1。緊接著，再在這個0後面補一位0，這第二個0代表的是該字全為0， 然後向後遍歷，看有多少個字(31位)的0， 像圖中的情況，有3個字的0連在一起，所以後面的30位只需要寫乙個整形的值3即可， 它代表的是有31*3這麼多個連續的0。
對於情況(3), 跟情況(2)類似，唯一的差別就是第二位是1.
該演算法在進行與或非運算的時候，就可以不用解壓縮整個位圖索引，只需要乙個字乙個字的進行先分析再運算即可。並且，當某個屬性的取值範圍很大的時候，則原始的點陣圖索引中必然有很大連續的0的情況，則其位圖索引的壓縮比例就會比較高。
目前很多的點陣圖索引的壓縮演算法都是在這個演算法的基礎之上改進而來的。原理大同小異。
而druid就是對我們插入其中的資料按一定的時間範圍生成段，每個段其實就是該時間範圍內的資料的點陣圖索引，當進行查詢自定義的查詢的時候(例如我需要查詢ip=ip1&url=url1的所有記錄的總的訪問次數)，druid會首先根據過濾條件，取得所有的滿足條件的資料，再進行統計。這樣由於其處理過濾條件會比較快速，從而也提高了查詢效率。
下一講我們開始談druid的架構。
Druid是什麼和Druid的介紹
druid的簡介 druid首先是乙個資料庫連線池。druid是目前最好的資料庫連線池，在功能 效能 擴充套件性方面，都超過其他資料庫連線池，包括dbcp c3p0 bonecp proxool jboss datasource。druid已經在阿里巴巴部署了超過600個應用，經過一年多生產環境大規...
Druid是什麼和Druid的介紹
druid的簡介 druid首先是乙個資料庫連線池。druid是目前最好的資料庫連線池，在功能 效能 擴充套件性方面，都超過其他資料庫連線池，包括dbcp c3p0 bonecp proxool jboss datasource。druid已經在阿里巴巴部署了超過600個應用，經過一年多生產環境大規...
Task2 GloVe原理介紹
使用skipgram和cbow兩種模型進行詞向量預訓練，我們會發現word2vec模型是乙個超級大的神經網路 權重矩陣規模非常大 舉個栗子，我們擁有10000個單詞的詞彙表，我們如果想嵌入200維的詞向量，那麼我們的輸入 隱層權重矩陣和隱層 輸出層的權重矩陣都會有 10000 x 200 200萬個...