自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

HBase性能優(yōu)化方法總結(jié)

數(shù)據(jù)庫 其他數(shù)據(jù)庫
本文主要是從HBase應(yīng)用程序設(shè)計(jì)與開發(fā)的角度,總結(jié)幾種常用的性能優(yōu)化方法。有關(guān)HBase系統(tǒng)配置級別的優(yōu)化,這里涉及的不多,這部分可以參考:淘寶Ken Wu同學(xué)的博客。

 1. 表的設(shè)計(jì)

1.1 Pre-Creating Regions

默認(rèn)情況下,在創(chuàng)建HBase表的時候會自動創(chuàng)建一個region分區(qū),當(dāng)導(dǎo)入數(shù)據(jù)的時候,所有的HBase客戶端都向這一個region寫數(shù)據(jù),直到這個region足夠大了才進(jìn)行切分。一種可以加快批量寫入速度的方法是通過預(yù)先創(chuàng)建一些空的regions,這樣當(dāng)數(shù)據(jù)寫入HBase時,會按照region分區(qū)情況,在集群內(nèi)做數(shù)據(jù)的負(fù)載均衡。

有關(guān)預(yù)分區(qū),詳情參見:Table Creation: Pre-Creating Regions,下面是一個例子:

  1. public static boolean createTable(HBaseAdmin admin, HTableDescriptor table, byte[][] splits) 
  2. throws IOException { 
  3.   try { 
  4.     admin.createTable(table, splits); 
  5.     return true
  6.   } catch (TableExistsException e) { 
  7.     logger.info("table " + table.getNameAsString() + " already exists"); 
  8.     // the table already exists... 
  9.     return false
  10.   } 
  11.   
  12. public static byte[][] getHexSplits(String startKey, String endKey, int numRegions) { 
  13.   byte[][] splits = new byte[numRegions-1][]; 
  14.   BigInteger lowestKey = new BigInteger(startKey, 16); 
  15.   BigInteger highestKey = new BigInteger(endKey, 16); 
  16.   BigInteger range = highestKey.subtract(lowestKey); 
  17.   BigInteger regionIncrement = range.divide(BigInteger.valueOf(numRegions)); 
  18.   lowestKey = lowestKey.add(regionIncrement); 
  19.   for(int i=0; i < numRegions-1;i++) { 
  20.     BigInteger key = lowestKey.add(regionIncrement.multiply(BigInteger.valueOf(i))); 
  21.     byte[] b = String.format("%016x", key).getBytes(); 
  22.     splits[i] = b; 
  23.   } 
  24.   return splits; 

1.2 Row Key

HBase中row key用來檢索表中的記錄,支持以下三種方式:

  • 通過單個row key訪問:即按照某個row key鍵值進(jìn)行g(shù)et操作;
  • 通過row key的range進(jìn)行scan:即通過設(shè)置startRowKey和endRowKey,在這個范圍內(nèi)進(jìn)行掃描;
  • 全表掃描:即直接掃描整張表中所有行記錄。

在HBase中,row key可以是任意字符串,***長度64KB,實(shí)際應(yīng)用中一般為10~100bytes,存為byte[]字節(jié)數(shù)組,一般設(shè)計(jì)成定長的。

row key是按照字典序存儲,因此,設(shè)計(jì)row key時,要充分利用這個排序特點(diǎn),將經(jīng)常一起讀取的數(shù)據(jù)存儲到一塊,將最近可能會被訪問的數(shù)據(jù)放在一塊。

舉個例子:如果最近寫入HBase表中的數(shù)據(jù)是最可能被訪問的,可以考慮將時間戳作為row key的一部分,由于是字典序排序,所以可以使用Long.MAX_VALUE – timestamp作為row key,這樣能保證新寫入的數(shù)據(jù)在讀取時可以被快速命中。

1.3 Column Family

不要在一張表里定義太多的column family。目前Hbase并不能很好的處理超過2~3個column family的表。因?yàn)槟硞€column family在flush的時候,它鄰近的column family也會因關(guān)聯(lián)效應(yīng)被觸發(fā)flush,最終導(dǎo)致系統(tǒng)產(chǎn)生更多的I/O。感興趣的同學(xué)可以對自己的HBase集群進(jìn)行實(shí)際測試,從得到的測試結(jié)果數(shù)據(jù)驗(yàn)證一下。

1.4 In Memory

創(chuàng)建表的時候,可以通過HColumnDescriptor.setInMemory(true)將表放到RegionServer的緩存中,保證在讀取的時候被cache命中。

1.5 Max Version

創(chuàng)建表的時候,可以通過HColumnDescriptor.setMaxVersions(int maxVersions)設(shè)置表中數(shù)據(jù)的***版本,如果只需要保存***版本的數(shù)據(jù),那么可以設(shè)置setMaxVersions(1)。

1.6 Time To Live

創(chuàng)建表的時候,可以通過HColumnDescriptor.setTimeToLive(int timeToLive)設(shè)置表中數(shù)據(jù)的存儲生命期,過期數(shù)據(jù)將自動被刪除,例如如果只需要存儲最近兩天的數(shù)據(jù),那么可以設(shè)置setTimeToLive(2 * 24 * 60 * 60)。

1.7 Compact & Split

在HBase中,數(shù)據(jù)在更新時首先寫入WAL 日志(HLog)和內(nèi)存(MemStore)中,MemStore中的數(shù)據(jù)是排序的,當(dāng)MemStore累計(jì)到一定閾值時,就會創(chuàng)建一個新的MemStore,并且將老的MemStore添加到flush隊(duì)列,由單獨(dú)的線程flush到磁盤上,成為一個StoreFile。于此同時, 系統(tǒng)會在zookeeper中記錄一個redo point,表示這個時刻之前的變更已經(jīng)持久化了(minor compact)。

StoreFile是只讀的,一旦創(chuàng)建后就不可以再修改。因此Hbase的更新其實(shí)是不斷追加的操作。當(dāng)一個Store中的StoreFile達(dá)到一定的閾值后,就會進(jìn)行一次合并(major compact),將對同一個key的修改合并到一起,形成一個大的StoreFile,當(dāng)StoreFile的大小達(dá)到一定閾值后,又會對 StoreFile進(jìn)行分割(split),等分為兩個StoreFile。

由于對表的更新是不斷追加的,處理讀請求時,需要訪問Store中全部的StoreFile和MemStore,將它們按照row key進(jìn)行合并,由于StoreFile和MemStore都是經(jīng)過排序的,并且StoreFile帶有內(nèi)存中索引,通常合并過程還是比較快的。

實(shí)際應(yīng)用中,可以考慮必要時手動進(jìn)行major compact,將同一個row key的修改進(jìn)行合并形成一個大的StoreFile。同時,可以將StoreFile設(shè)置大些,減少split的發(fā)生。

2. 寫表操作

2.1 多HTable并發(fā)寫

創(chuàng)建多個HTable客戶端用于寫操作,提高寫數(shù)據(jù)的吞吐量,一個例子:

  1. static final Configuration conf = HBaseConfiguration.create(); 
  2. static final String table_log_name = “user_log”; 
  3. wTableLog = new HTable[tableN]; 
  4. for (int i = 0; i < tableN; i++) { 
  5.     wTableLog[i] = new HTable(conf, table_log_name); 
  6.     wTableLog[i].setWriteBufferSize(5 * 1024 * 1024); //5MB 
  7.     wTableLog[i].setAutoFlush(false); 

2.2 HTable參數(shù)設(shè)置

2.2.1 Auto Flush

通過調(diào)用HTable.setAutoFlush(false)方法可以將HTable寫客戶端的自動flush關(guān)閉,這樣可以批量寫入數(shù)據(jù)到HBase,而不是有一條put就執(zhí)行一次更新,只有當(dāng)put填滿客戶端寫緩存時,才實(shí)際向HBase服務(wù)端發(fā)起寫請求。默認(rèn)情況下auto flush是開啟的。

2.2.2 Write Buffer

通過調(diào)用HTable.setWriteBufferSize(writeBufferSize)方法可以設(shè)置HTable客戶端的寫buffer大小,如果新設(shè)置的buffer小于當(dāng)前寫buffer中的數(shù)據(jù)時,buffer將會被flush到服務(wù)端。其中,writeBufferSize的單位是byte字節(jié)數(shù),可以根據(jù)實(shí)際寫入數(shù)據(jù)量的多少來設(shè)置該值。

2.2.3 WAL Flag

在HBae中,客戶端向集群中的RegionServer提交數(shù)據(jù)時(Put/Delete操作),首先會先寫WAL(Write Ahead Log)日志(即HLog,一個RegionServer上的所有Region共享一個HLog),只有當(dāng)WAL日志寫成功后,再接著寫MemStore,然后客戶端被通知提交數(shù)據(jù)成功;如果寫WAL日志失敗,客戶端則被通知提交失敗。這樣做的好處是可以做到RegionServer宕機(jī)后的數(shù)據(jù)恢復(fù)。

因此,對于相對不太重要的數(shù)據(jù),可以在Put/Delete操作時,通過調(diào)用Put.setWriteToWAL(false)或Delete.setWriteToWAL(false)函數(shù),放棄寫WAL日志,從而提高數(shù)據(jù)寫入的性能。

值得注意的是:謹(jǐn)慎選擇關(guān)閉WAL日志,因?yàn)檫@樣的話,一旦RegionServer宕機(jī),Put/Delete的數(shù)據(jù)將會無法根據(jù)WAL日志進(jìn)行恢復(fù)。

2.3 批量寫

通過調(diào)用HTable.put(Put)方法可以將一個指定的row key記錄寫入HBase,同樣HBase提供了另一個方法:通過調(diào)用HTable.put(List<Put>)方法可以將指定的row key列表,批量寫入多行記錄,這樣做的好處是批量執(zhí)行,只需要一次網(wǎng)絡(luò)I/O開銷,這對于對數(shù)據(jù)實(shí)時性要求高,網(wǎng)絡(luò)傳輸RTT高的情景下可能帶來明顯的性能提升。

2.4 多線程并發(fā)寫

在客戶端開啟多個HTable寫線程,每個寫線程負(fù)責(zé)一個HTable對象的flush操作,這樣結(jié)合定時flush和寫buffer(writeBufferSize),可以既保證在數(shù)據(jù)量小的時候,數(shù)據(jù)可以在較短時間內(nèi)被flush(如1秒內(nèi)),同時又保證在數(shù)據(jù)量大的時候,寫buffer一滿就及時進(jìn)行flush。下面給個具體的例子:

  1. for (int i = 0; i < threadN; i++) { 
  2.     Thread th = new Thread() { 
  3.         public void run() { 
  4.             while (true) { 
  5.                 try { 
  6.                     sleep(1000); //1 second 
  7.                 } catch (InterruptedException e) { 
  8.                     e.printStackTrace(); 
  9.                 } 
  10.                                 synchronized (wTableLog[i]) { 
  11.                     try { 
  12.                         wTableLog[i].flushCommits(); 
  13.                     } catch (IOException e) { 
  14.                         e.printStackTrace(); 
  15.                     } 
  16.                 } 
  17.             } 
  18.                 } 
  19.     }; 
  20.     th.setDaemon(true); 
  21.     th.start(); 

3. 讀表操作

3.1 多HTable并發(fā)讀

創(chuàng)建多個HTable客戶端用于讀操作,提高讀數(shù)據(jù)的吞吐量,一個例子:

  1. static final Configuration conf = HBaseConfiguration.create(); 
  2. static final String table_log_name = “user_log”; 
  3. rTableLog = new HTable[tableN]; 
  4. for (int i = 0; i < tableN; i++) { 
  5.     rTableLog[i] = new HTable(conf, table_log_name); 
  6.     rTableLog[i].setScannerCaching(50); 

3.2 HTable參數(shù)設(shè)置

3.2.1 Scanner Caching

通過調(diào)用HTable.setScannerCaching(int scannerCaching)可以設(shè)置HBase scanner一次從服務(wù)端抓取的數(shù)據(jù)條數(shù),默認(rèn)情況下一次一條。通過將此值設(shè)置成一個合理的值,可以減少scan過程中next()的時間開銷,代價是scanner需要通過客戶端的內(nèi)存來維持這些被cache的行記錄。

3.2.2 Scan Attribute Selection

scan時指定需要的Column Family,可以減少網(wǎng)絡(luò)傳輸數(shù)據(jù)量,否則默認(rèn)scan操作會返回整行所有Column Family的數(shù)據(jù)。

3.2.3 Close ResultScanner

通過scan取完數(shù)據(jù)后,記得要關(guān)閉ResultScanner,否則RegionServer可能會出現(xiàn)問題(對應(yīng)的Server資源無法釋放)。

3.3 批量讀

通過調(diào)用HTable.get(Get)方法可以根據(jù)一個指定的row key獲取一行記錄,同樣HBase提供了另一個方法:通過調(diào)用HTable.get(List)方法可以根據(jù)一個指定的row key列表,批量獲取多行記錄,這樣做的好處是批量執(zhí)行,只需要一次網(wǎng)絡(luò)I/O開銷,這對于對數(shù)據(jù)實(shí)時性要求高而且網(wǎng)絡(luò)傳輸RTT高的情景下可能帶來明顯的性能提升。

3.4 多線程并發(fā)讀

在客戶端開啟多個HTable讀線程,每個讀線程負(fù)責(zé)通過HTable對象進(jìn)行g(shù)et操作。下面是一個多線程并發(fā)讀取HBase,獲取店鋪一天內(nèi)各分鐘PV值的例子:

  1. public class DataReaderServer { 
  2.      //獲取店鋪一天內(nèi)各分鐘PV值的入口函數(shù) 
  3.      public static ConcurrentHashMap getUnitMinutePV(long uid, long startStamp, long endStamp){ 
  4.          long min = startStamp; 
  5.          int count = (int)((endStamp - startStamp) / (60*1000)); 
  6.          List lst = new ArrayList(); 
  7.          for (int i = 0; i <= count; i++) { 
  8.             min = startStamp + i * 60 * 1000; 
  9.             lst.add(uid + "_" + min); 
  10.          } 
  11.          return parallelBatchMinutePV(lst); 
  12.      } 
  13.       //多線程并發(fā)查詢,獲取分鐘PV值 
  14. private static ConcurrentHashMap parallelBatchMinutePV(List lstKeys){ 
  15.         ConcurrentHashMap hashRet = new ConcurrentHashMap(); 
  16.         int parallel = 3; 
  17.         List<List<String>> lstBatchKeys  = null
  18.         if (lstKeys.size() < parallel ){ 
  19.             lstBatchKeys  = new ArrayList<List<String>>(1); 
  20.             lstBatchKeys.add(lstKeys); 
  21.         } 
  22.         else
  23.             lstBatchKeys  = new ArrayList<List<String>>(parallel); 
  24.             for(int i = 0; i < parallel; i++  ){ 
  25.                 List lst = new ArrayList(); 
  26.                 lstBatchKeys.add(lst); 
  27.             } 
  28.   
  29.             for(int i = 0 ; i < lstKeys.size() ; i ++ ){ 
  30.                 lstBatchKeys.get(i%parallel).add(lstKeys.get(i)); 
  31.             } 
  32.         } 
  33.   
  34.         List >> futures = new ArrayList >>(5); 
  35.   
  36.         ThreadFactoryBuilder builder = new ThreadFactoryBuilder(); 
  37.         builder.setNameFormat("ParallelBatchQuery"); 
  38.         ThreadFactory factory = builder.build(); 
  39.         ThreadPoolExecutor executor = (ThreadPoolExecutor) Executors.newFixedThreadPool(lstBatchKeys.size(), factory); 
  40.   
  41.         for(List keys : lstBatchKeys){ 
  42.             Callable< ConcurrentHashMap > callable = new BatchMinutePVCallable(keys); 
  43.             FutureTask< ConcurrentHashMap > future = (FutureTask< ConcurrentHashMap >) executor.submit(callable); 
  44.             futures.add(future); 
  45.         } 
  46.         executor.shutdown(); 
  47.   
  48.         // Wait for all the tasks to finish 
  49.         try { 
  50.           boolean stillRunning = !executor.awaitTermination( 
  51.               5000000, TimeUnit.MILLISECONDS); 
  52.           if (stillRunning) { 
  53.             try { 
  54.                 executor.shutdownNow(); 
  55.             } catch (Exception e) { 
  56.                 // TODO Auto-generated catch block 
  57.                 e.printStackTrace(); 
  58.             } 
  59.           } 
  60.         } catch (InterruptedException e) { 
  61.           try { 
  62.               Thread.currentThread().interrupt(); 
  63.           } catch (Exception e1) { 
  64.             // TODO Auto-generated catch block 
  65.             e1.printStackTrace(); 
  66.           } 
  67.         } 
  68.   
  69.         // Look for any exception 
  70.         for (Future f : futures) { 
  71.           try { 
  72.               if(f.get() != null
  73.               { 
  74.                   hashRet.putAll((ConcurrentHashMap)f.get()); 
  75.               } 
  76.           } catch (InterruptedException e) { 
  77.             try { 
  78.                  Thread.currentThread().interrupt(); 
  79.             } catch (Exception e1) { 
  80.                 // TODO Auto-generated catch block 
  81.                 e1.printStackTrace(); 
  82.             } 
  83.           } catch (ExecutionException e) { 
  84.             e.printStackTrace(); 
  85.           } 
  86.         } 
  87.   
  88.         return hashRet; 
  89.     } 
  90.      //一個線程批量查詢,獲取分鐘PV值 
  91.     protected static ConcurrentHashMap getBatchMinutePV(List lstKeys){ 
  92.         ConcurrentHashMap hashRet = null
  93.         List lstGet = new ArrayList(); 
  94.         String[] splitValue = null
  95.         for (String s : lstKeys) { 
  96.             splitValue = s.split("_"); 
  97.             long uid = Long.parseLong(splitValue[0]); 
  98.             long min = Long.parseLong(splitValue[1]); 
  99.             byte[] key = new byte[16]; 
  100.             Bytes.putLong(key, 0, uid); 
  101.             Bytes.putLong(key, 8, min); 
  102.             Get g = new Get(key); 
  103.             g.addFamily(fp); 
  104.             lstGet.add(g); 
  105.         } 
  106.         Result[] res = null
  107.         try { 
  108.             res = tableMinutePV[rand.nextInt(tableN)].get(lstGet); 
  109.         } catch (IOException e1) { 
  110.             logger.error("tableMinutePV exception, e=" + e1.getStackTrace()); 
  111.         } 
  112.   
  113.         if (res != null && res.length > 0) { 
  114.             hashRet = new ConcurrentHashMap(res.length); 
  115.             for (Result re : res) { 
  116.                 if (re != null && !re.isEmpty()) { 
  117.                     try { 
  118.                         byte[] key = re.getRow(); 
  119.                         byte[] value = re.getValue(fp, cp); 
  120.                         if (key != null && value != null) { 
  121.                             hashRet.put(String.valueOf(Bytes.toLong(key, 
  122.                                     Bytes.SIZEOF_LONG)), String.valueOf(Bytes 
  123.                                     .toLong(value))); 
  124.                         } 
  125.                     } catch (Exception e2) { 
  126.                         logger.error(e2.getStackTrace()); 
  127.                     } 
  128.                 } 
  129.             } 
  130.         } 
  131.   
  132.         return hashRet; 
  133.     } 
  134. //調(diào)用接口類,實(shí)現(xiàn)Callable接口 
  135. class BatchMinutePVCallable implements Callable>{ 
  136.      private List keys; 
  137.   
  138.      public BatchMinutePVCallable(List lstKeys ) { 
  139.          this.keys = lstKeys; 
  140.      } 
  141.   
  142.      public ConcurrentHashMap call() throws Exception { 
  143.          return DataReadServer.getBatchMinutePV(keys); 
  144.      } 

3.5 緩存查詢結(jié)果

對于頻繁查詢HBase的應(yīng)用場景,可以考慮在應(yīng)用程序中做緩存,當(dāng)有新的查詢請求時,首先在緩存中查找,如果存在則直接返回,不再查詢HBase;否則對HBase發(fā)起讀請求查詢,然后在應(yīng)用程序中將查詢結(jié)果緩存起來。至于緩存的替換策略,可以考慮LRU等常用的策略。

3.6 Blockcache

HBase上Regionserver的內(nèi)存分為兩個部分,一部分作為Memstore,主要用來寫;另外一部分作為BlockCache,主要用于讀。

寫請求會先寫入Memstore,Regionserver會給每個region提供一個Memstore,當(dāng)Memstore滿64MB以后,會啟動 flush刷新到磁盤。當(dāng)Memstore的總大小超過限制時(heapsize * hbase.regionserver.global.memstore.upperLimit * 0.9),會強(qiáng)行啟動flush進(jìn)程,從***的Memstore開始flush直到低于限制。

讀請求先到Memstore中查數(shù)據(jù),查不到就到BlockCache中查,再查不到就會到磁盤上讀,并把讀的結(jié)果放入BlockCache。由于BlockCache采用的是LRU策略,因此BlockCache達(dá)到上限(heapsize * hfile.block.cache.size * 0.85)后,會啟動淘汰機(jī)制,淘汰掉最老的一批數(shù)據(jù)。

一個Regionserver上有一個BlockCache和N個Memstore,它們的大小之和不能大于等于heapsize * 0.8,否則HBase不能啟動。默認(rèn)BlockCache為0.2,而Memstore為0.4。對于注重讀響應(yīng)時間的系統(tǒng),可以將 BlockCache設(shè)大些,比如設(shè)置BlockCache=0.4,Memstore=0.39,以加大緩存的命中率。

有關(guān)BlockCache機(jī)制,請參考這里:HBase的Block cache,HBase的blockcache機(jī)制,hbase中的緩存的計(jì)算與使用。

4.數(shù)據(jù)計(jì)算

4.1 服務(wù)端計(jì)算

Coprocessor運(yùn)行于HBase RegionServer服務(wù)端,各個Regions保持對與其相關(guān)的coprocessor實(shí)現(xiàn)類的引用,coprocessor類可以通過RegionServer上classpath中的本地jar或HDFS的classloader進(jìn)行加載。

目前,已提供有幾種coprocessor:

Coprocessor:提供對于region管理的鉤子,例如region的open/close/split/flush/compact等;
RegionObserver:提供用于從客戶端監(jiān)控表相關(guān)操作的鉤子,例如表的get/put/scan/delete等;
Endpoint:提供可以在region上執(zhí)行任意函數(shù)的命令觸發(fā)器。一個使用例子是RegionServer端的列聚合,這里有代碼示例。
以上只是有關(guān)coprocessor的一些基本介紹,本人沒有對其實(shí)際使用的經(jīng)驗(yàn),對它的可用性和性能數(shù)據(jù)不得而知。感興趣的同學(xué)可以嘗試一下,歡迎討論。

4.2 寫端計(jì)算

4.2.1 計(jì)數(shù)

HBase本身可以看作是一個可以水平擴(kuò)展的Key-Value存儲系統(tǒng),但是其本身的計(jì)算能力有限(Coprocessor可以提供一定的服務(wù)端計(jì)算),因此,使用HBase時,往往需要從寫端或者讀端進(jìn)行計(jì)算,然后將最終的計(jì)算結(jié)果返回給調(diào)用者。舉兩個簡單的例子:

PV計(jì)算:通過在HBase寫端內(nèi)存中,累加計(jì)數(shù),維護(hù)PV值的更新,同時為了做到持久化,定期(如1秒)將PV計(jì)算結(jié)果同步到HBase中,這樣查詢端最多會有1秒鐘的延遲,能看到秒級延遲的PV結(jié)果。
分鐘PV計(jì)算:與上面提到的PV計(jì)算方法相結(jié)合,每分鐘將當(dāng)前的累計(jì)PV值,按照rowkey + minute作為新的rowkey寫入HBase中,然后在查詢端通過scan得到當(dāng)天各個分鐘以前的累計(jì)PV值,然后順次將前后兩分鐘的累計(jì)PV值相減,就得到了當(dāng)前一分鐘內(nèi)的PV值,從而最終也就得到當(dāng)天各個分鐘內(nèi)的PV值。

4.2.2 去重

對于UV的計(jì)算,就是個去重計(jì)算的例子。分兩種情況:

如果內(nèi)存可以容納,那么可以在Hash表中維護(hù)所有已經(jīng)存在的UV標(biāo)識,每當(dāng)新來一個標(biāo)識時,通過快速查找Hash確定是否是一個新的UV,若是則UV值加1,否則UV值不變。另外,為了做到持久化或提供給查詢接口使用,可以定期(如1秒)將UV計(jì)算結(jié)果同步到HBase中。
如果內(nèi)存不能容納,可以考慮采用Bloom Filter來實(shí)現(xiàn),從而盡可能的減少內(nèi)存的占用情況。除了UV的計(jì)算外,判斷URL是否存在也是個典型的應(yīng)用場景。

4.3 讀端計(jì)算

如果對于響應(yīng)時間要求比較苛刻的情況(如單次http請求要在毫秒級時間內(nèi)返回),個人覺得讀端不宜做過多復(fù)雜的計(jì)算邏輯,盡量做到讀端功能單一化:即從HBase RegionServer讀到數(shù)據(jù)(scan或get方式)后,按照數(shù)據(jù)格式進(jìn)行簡單的拼接,直接返回給前端使用。當(dāng)然,如果對于響應(yīng)時間要求一般,或者業(yè)務(wù)特點(diǎn)需要,也可以在讀端進(jìn)行一些計(jì)算邏輯。

5.總結(jié)

作為一個Key-Value存儲系統(tǒng),HBase并不是***的,它有自己獨(dú)特的地方。因此,基于它來做應(yīng)用時,我們往往需要從多方面進(jìn)行優(yōu)化改進(jìn)(表設(shè)計(jì)、讀表操作、寫表操作、數(shù)據(jù)計(jì)算等),有時甚至還需要從系統(tǒng)級對HBase進(jìn)行配置調(diào)優(yōu),更甚至可以對HBase本身進(jìn)行優(yōu)化。這屬于不同的層次范疇。

總之,概括來講,對系統(tǒng)進(jìn)行優(yōu)化時,首先定位到影響你的程序運(yùn)行性能的瓶頸之處,然后有的放矢進(jìn)行針對行的優(yōu)化。如果優(yōu)化后滿足你的期望,那么就可以停止優(yōu)化;否則繼續(xù)尋找新的瓶頸之處,開始新的優(yōu)化,直到滿足性能要求。

以上就是從項(xiàng)目開發(fā)中總結(jié)的一點(diǎn)經(jīng)驗(yàn),如有不對之處,歡迎大家不吝賜教。

原文鏈接:http://blog.linezing.com/2012/03/hbase-performance-optimization

【編輯推薦】

  1. 讓數(shù)據(jù)庫變快的10個建議
  2. 利用Java進(jìn)行MySql數(shù)據(jù)庫的導(dǎo)入和導(dǎo)出
  3. 20個數(shù)據(jù)庫設(shè)計(jì)***實(shí)踐
  4. 超越MySQL 對流行數(shù)據(jù)庫進(jìn)行分支
  5. 迎接大數(shù)據(jù)時代,高手較量數(shù)據(jù)庫遷移實(shí)戰(zhàn)方案

責(zé)任編輯:彭凡 來源: 量子恒道官方博客
相關(guān)推薦

2021-08-27 14:26:06

開發(fā)技能React

2019-02-25 07:07:38

技巧React 優(yōu)化

2022-05-23 13:44:53

前端開發(fā)優(yōu)化

2017-03-01 20:53:56

HBase實(shí)踐

2016-11-17 09:00:46

HBase優(yōu)化策略

2013-09-16 15:16:20

Android性能優(yōu)化

2009-12-24 16:46:03

WPF性能優(yōu)化

2016-12-19 10:00:00

React性能優(yōu)化

2013-01-10 09:47:09

HBase性能優(yōu)化

2019-12-10 08:10:35

LinuxCPU性能優(yōu)化

2017-12-04 12:29:15

前端JavaScript性能優(yōu)化

2015-07-09 13:19:17

Ceph分布式存儲性能調(diào)優(yōu)

2015-11-05 09:02:05

Java代碼性能優(yōu)化

2022-09-13 12:56:28

前端優(yōu)化

2011-06-20 14:22:58

外鏈

2021-07-16 23:01:03

SQL索引性能

2015-07-02 11:17:30

MySQLSlave延遲優(yōu)化

2014-04-04 10:16:51

Nginx配置Nginx性能優(yōu)化

2010-12-10 10:17:21

關(guān)系型數(shù)據(jù)庫

2021-07-26 18:23:23

SQL策略優(yōu)化
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號