<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                企業??AI智能體構建引擎,智能編排和調試,一鍵部署,支持知識庫和私有化部署方案 廣告
                [TOC] 下面幾個shell 命令在hbase操作中可以起到很到的作用,且主要體現在建表的過程中,看下面幾個create 屬性 # BLOOMFILTER 默認是NONE 是否使用布隆過慮及使用何種方式 布隆過濾可以每列族單獨啟用。 使用 HColumnDescriptor.setBloomFilterType(NONE | ROW | ROWCOL) 對列族單獨啟用布隆。 * Default = ROW 對行進行布隆過濾。 * 對 ROW,行鍵的哈希在每次插入行時將被添加到布隆。 * 對 ROWCOL,行鍵 + 列族 + 列族修飾的哈希將在每次插入行時添加到布隆 使用方法: ~~~ create 'table',{BLOOMFILTER =>'ROW'} ~~~ **啟用布隆過濾可以節省讀磁盤過程,可以有助于降低讀取延遲** # BLOCKSIZE 塊緩存 建表的時候可以設置數據塊大小 ~~~ create 'mytable', {NAME=>'colfam1',BLOCKSIZE=>'65536'} ~~~ 數據庫緩存默認是打開的,可以在建表的時候關閉他 ~~~ create 'mytable', {NAME=>'colfam1',BLOCKSIZE=>'false'} ~~~ # 激進緩存 可以選擇一些列族,賦予他們在數據塊緩存里有更高的優先級(LRU緩存).如果你預期一個列族比另一個列族隨機讀更多,這個特性遲早用的上.這個配置是在表實例化的時候定義: ~~~ create 'mytable', {NAME=>'colfam1',IN_MEMORY=>'true'} ~~~ IN_MEMORY的參數默認是false.因為hbase除了在數據塊緩存里保存這個列族相比其他列族更激進之外并不提供額外保證,所以設置為true不會變化太大 # VERSIONS 默認是1 這個參數的意思是數據保留1個 版本,如果我們認為我們的數據沒有這么大的必要保留這么多,隨時都在更新,而老版本的數據對我們毫無價值,那將此參數設為1 能節約2/3的空間 使用方法: `create 'table',{VERSIONS=>'2'}` 附:`MIN_VERSIONS => '0'`是說在compact操作執行之后,至少要保留的版本 # COMPRESSION 壓縮 默認值是NONE 即不使用壓縮 這個參數意思是該列族是否采用壓縮,采用什么壓縮算法 使用方法: `create 'table',{NAME=>'info',COMPRESSION=>'SNAPPY'} ` 建議采用SNAPPY壓縮算法 HBase中,在Snappy發布之前(Google 2011年對外發布Snappy),采用的LZO算法,目標是達到盡可能快的壓縮和解壓速度,同時減少對CPU的消耗; 在Snappy發布之后,建議采用Snappy算法(參考《HBase: The Definitive Guide》),具體可以根據實際情況對LZO和Snappy做過更詳細的對比測試后再做選擇。 ![](https://box.kancloud.cn/81d801b205ec3369aa359511a606a77f_454x260.png) 如果建表之初沒有壓縮,后來想要加入壓縮算法,可以通過alter修改schema 注意數據只是在硬盤上是壓縮的,在內存里(memstore或blockcache)或網絡傳輸的時候是沒有壓縮的 ## alter 使用方法: 如 修改壓縮算法 ~~~ disable 'table' alter 'table',{NAME=>'info',COMPRESSION=>'snappy'} enable 'table' ~~~ 但是需要執行`major_compact 'table'` 命令之后 才會做實際的操作。 # TTL 默認是 2147483647 即:Integer.MAX_VALUE 值大概是68年,默認`TTL=>'FOREVER'` 這個參數是說明該列族數據的存活時間,單位是s 這個參數可以根據具體的需求對數據設定存活時間,超過存過時間的數據將在表中不在顯示,待下次major compact的時候再徹底刪除數據 注意的是TTL設定之后 `MIN_VERSIONS=>'0'` 這樣設置之后,TTL時間戳過期后,將全部徹底刪除該family下所有的數據,如果MIN_VERSIONS 不等于0那將保留最新的MIN_VERSIONS個版本的數據,其它的全部刪除,比如`MIN_VERSIONS=>'1' `屆時將保留一個最新版本的數據,其它版本的數據將不再保存。 # describe 'table' 這個命令查看了create table 的各項參數或者是默認值 `disable_all 'toplist.*' ` `disable_all` 支持正則表達式,并列出當前匹配的表的如下: ~~~ toplist_a_total_1001 toplist_a_total_1002 toplist_a_total_1008 toplist_a_total_1009 toplist_a_total_1019 toplist_a_total_1035 ... Disable the above 25 tables (y/n)? 并給出確認提示 ~~~ # drop_all 這個命令和disable_all的使用方式是一樣的 # hbase 表預分區----手動分區 默認情況下,在創建HBase表的時候會自動創建一個region分區,當導入數據的時候,所有的HBase客戶端都向這一個region寫數據,直到這個region足夠大了才進行切分。**一種可以加快批量寫入速度的方法是通過預先創建一些空的regions**,這樣當數據寫入HBase時,會按照region分區情況,在集群內做數據的負載均衡。 命令方式: 15個分區,hash切分 ~~~ create 't1', 'f1', {NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'} ~~~ 也可以使用api的方式: ~~~ bin/hbase org.apache.hadoop.hbase.util.RegionSplitter test_table HexStringSplit -c 10 -f info ~~~ 參數: ~~~ test_table是表名 HexStringSplit 是split 方式 -c 是分10個region -f 是family ~~~ 可在UI上查看結果,如圖: ![](https://box.kancloud.cn/c353d9e36b22a66bdab6a35a2c9052eb_914x633.png) 這樣就可以將表預先分為15個區,減少數據達到storefile 大小的時候自動分區的時間消耗,并且還有以一個優勢,就是合理設計rowkey 能讓各個region 的并發請求平均分配(趨于均勻) 使IO 效率達到最高,但是預分區需要將filesize 設置一個較大的值, 設置哪個參數呢 hbase.hregion.max.filesize 這個值默認是10G 也就是說**單個region 默認大小是10G** 這個參數的默認值在0.90 到0.92到0.94.3各版本的變化:`256M--1G--10G` **但是如果MapReduce Input類型為TableInputFormat 使用hbase作為輸入的時候,就要注意了,每個region一個map,如果數據小于10G 那只會啟用一個map 造成很大的資源浪費,這時候可以考慮適當調小該參數的值,或者采用預分配region的方式,并將檢測如果達到這個值,再手動分配region** # 行鍵設計 表結構設計 1. 列族數量的設定 以用戶信息為例,可以將必須的基本信息存放在一個列族,而一些附加的額外信息可以放在另一列族; 2. 行鍵的設計 語音詳單: ~~~ 13877889988-20150625 13877889988-20150625 13877889988-20150626 13877889988-20150626 13877889989 13877889989 13877889989 ~~~ ----將需要批量查詢的數據盡可能連續存放 CMS系統----多條件查詢 盡可能將查詢條件關鍵詞拼裝到rowkey中,查詢頻率最高的條件盡量往前靠 ~~~ 20150230-zhangsan-category… 20150230-lisi-category… ~~~ (每一個條件的值長度不同,可以通過做定長映射來提高效率)(可以創建一張表來映射下) 參考:《hbase 實戰》----詳細講述了facebook /GIS等系統的表結構設計
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看