IT技術互動交流平臺

Hbase架構與理

來源:IT165收集  發布日期:2016-07-19 21:07:33

HBase是Apache Hadoop中的一個子項目,Hbase依托于Hadoop的HDFS作為最基本存儲基礎單元,通過使用hadoop的DFS工具就可以看到這些這些數據存儲文件夾的結構,還可以通過Map/Reduce的框架(算法)對HBase進行操作

一、 hbase架構

1.概述。

HBase是Apache Hadoop的數據庫,能夠對大型數據提供隨機、實時的讀寫訪問。HBase的目標是存儲并處理大型的數據。HBase是一個開源的,分布式的,多版本的,面向列的存儲模型。它存儲的是松散型數據。

上圖是hadoop的生態系統描述,hadoop所有應用都是構建于hdfs(它提供高可靠的底層存儲支持,幾乎已經成為分布式文件存儲系統事實上的工業標準)之上的分布式列存儲系統,主要用于海量結構化數據存儲。

HBase是一種NoSQL數據庫. NoSQL是一個通用詞表示數據庫不是RDBMS ,后者支持 SQL 作為主要訪問手段。有許多種 NoSQL 數據庫: BerkeleyDB 是本地 NoSQL 數據庫例子, 而 HBase 是大型分布式數據庫。 技術上來說, HBase 更像是"數據存儲(Data Store)" 多于 "數據庫(Data Base)"。因為缺少很多RDBMS特性, 如列類型,第二索引,觸發器,高級查詢語言等

然而, HBase 有許多特征同時支持線性化和模塊化擴充。 HBase 集群通過增加RegionServers進行擴充。 它可以放在普通的服務器中。例如,如果集群從10個擴充到20個RegionServer,存儲空間和處理容量都同時翻倍。 RDBMS 也能很好擴充, 但僅對一個點 - 特別是對一個單獨數據庫服務器的大小 - 同時,為了更好的性能,需要特殊的硬件和存儲設備。Hbase特性:

強一致性讀寫: HBase 不是 "最終一致性(eventually consistent)" 數據存儲. 這讓它很適合高速計數聚合類任務。

自動分片(Automatic sharding):HBase 表通過region分布在集群中。數據增長時,region會自動分割并重新分布。

RegionServer 自動故障轉移

Hadoop/HDFS 集成: HBase 支持本機外HDFS 作為它的分布式文件系統。

MapReduce: HBase 通過MapReduce支持大并發處理, HBase 可以同時做源和目標.

Java 客戶端 API: HBase 支持易于使用的 Java API 進行編程訪問.

Thrift/REST API:HBase 也支持Thrift和 REST 作為非Java 前端.

Block Cache 和 Bloom Filters: 對于大容量查詢優化, HBase支持 Block Cache 和 Bloom Filters。

運維管理: HBase提供內置網頁用于運維視角和JMX 度量.

前文提到Hbase是一個列式存儲的數據庫,那么什么是列式存儲,它與傳統的RDBMS采用的行式存儲又有什么區別?列存儲不同于傳統的關系型數據庫,其數據在表中是按行存儲的,列方式所帶來的重要好處之一就是,由于查詢中的選擇規則是通過列來定義的,因此整個數據庫是自動索引化的。按列存儲每個字段的數據聚集存儲,在查詢只需要少數幾個字段的時候,能大大減少讀取的數據量,一個字段的數據聚集存儲,那就更容易為這種聚集存儲設計更好的壓縮/解壓算法。這張圖講述了傳統的行存儲和列存儲的區別:

2.hbase架構

注:準確的說位于上圖下半部分的組建應該是hdfs而非hadoop,hbase并不依賴于hadoop,但是它構建于hdfs之上。

Zookeeper:
Zookeeper Quorum存儲-ROOT-表地址、HMaster地址
HRegionServer把自己以Ephedral方式注冊到Zookeeper中,HMaster隨時感知各個HRegionServer的健康狀況
Zookeeper避免HMaster單點問題
HMaster
HMaster沒有單點問題,HBase中可以啟動多個HMaster,通過Zookeeper的MasterElection機制保證總有一個Master在運行
主要負責Table和Region的管理工作:
1 管理用戶對表的增刪改查操作
2 管理HRegionServer的負載均衡,調整Region分布
3 Region Split后,負責新Region的分布
4 在HRegionServer停機后,負責失效HRegionServer上Region遷移

HRegionServer:
HBase中最核心的模塊,主要負責響應用戶I/O請求,向HDFS文件系統中讀寫數據

HRegionServer管理一些列HRegion對象;
每個HRegion對應Table中一個Region,HRegion由多個HStore組成;
每個HStore對應Table中一個Column Family的存儲;
Column Family就是一個集中的存儲單元,故將具有相同IO特性的Column放在一個Column Family會更高效

HStore:
HBase存儲的核心。由MemStore和StoreFile組成。
MemStore是Sorted Memory Buffer。用戶寫入數據的流程:

Client寫入 -> 存入MemStore,一直到MemStore滿 -> Flush成一個StoreFile,直至增長到一定閾值 -> 出發Compact合并操作 -> 多個StoreFile合并成一個StoreFile,同時進行版本合并和數據刪除 -> 當StoreFiles Compact后,逐步形成越來越大的StoreFile ->單個StoreFile大小超過一定閾值后,觸發Split操作,把當前Region Split成2個Region,Region會下線,新Split出的2個孩子Region會被HMaster分配到相應的HRegionServer 上,使得原先1個Region的壓力得以分流到2個Region上
由此過程可知,HBase只是增加數據,所有的更新和刪除操作,都是在Compact階段做的,所以,用戶寫操作只需要進入到內存即可立即返回,從而保證I/O高性能。

HLog
引入HLog原因:
在分布式系統環境中,無法避免系統出錯或者宕機,一旦HRegionServer意外退出,MemStore中的內存數據就會丟失,引入HLog就是防止這種情況
工作機制:
每 個HRegionServer中都會有一個HLog對象,HLog是一個實現Write Ahead Log的類,每次用戶操作寫入Memstore的同時,也會寫一份數據到HLog文件,HLog文件定期會滾動出新,并刪除舊的文件(已持久化到 StoreFile中的數據)。當HRegionServer意外終止后,HMaster會通過Zookeeper感知,HMaster首先處理遺留的 HLog文件,將不同region的log數據拆分,分別放到相應region目錄下,然后再將失效的region重新分配,領取到這些region的 HRegionServer在Load Region的過程中,會發現有歷史HLog需要處理,因此會Replay HLog中的數據到MemStore中,然后flush到StoreFiles,完成數據恢復。

HBase存儲格式
HBase中的所有數據文件都存儲在Hadoop HDFS文件系統上,格式主要有兩種:
1 HFile HBase中KeyValue數據的存儲格式,HFile是Hadoop的二進制格式文件,實際上StoreFile就是對HFile做了輕量級包裝,即StoreFile底層就是HFile
2 HLog File,HBase中WAL(Write Ahead Log) 的存儲格式,物理上是Hadoop的Sequence File

HFile

HFile文件不定長,長度固定的塊只有兩個:Trailer和FileInfo
Trailer中指針指向其他數據塊的起始點
File Info中記錄了文件的一些Meta信息,例如:AVG_KEY_LEN,AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY等
Data Index和Meta Index塊記錄了每個Data塊和Meta塊的起始點
Data Block是HBase I/O的基本單元,為了提高效率,HRegionServer中有基于LRU的Block Cache機制
每個Data塊的大小可以在創建一個Table的時候通過參數指定,大號的Block有利于順序Scan,小號Block利于隨機查詢
每個Data塊除了開頭的Magic以外就是一個個KeyValue對拼接而成, Magic內容就是一些隨機數字,目的是防止數據損壞

HFile里面的每個KeyValue對就是一個簡單的byte數組。這個byte數組里面包含了很多項,并且有固定的結構。

KeyLength和ValueLength:兩個固定的長度,分別代表Key和Value的長度
Key部分:Row Length是固定長度的數值,表示RowKey的長度,Row 就是RowKey
Column Family Length是固定長度的數值,表示Family的長度
接著就是Column Family,再接著是Qualifier,然后是兩個固定長度的數值,表示Time Stamp和Key Type(Put/Delete)
Value部分沒有這么復雜的結構,就是純粹的二進制數據

HLog文件就是一個普通的Hadoop Sequence File,Sequence File 的Key是HLogKey對象,HLogKey中記錄了寫入數據的歸屬信息,除了table和region名字外,同時還包括 sequence number和timestamp,timestamp是“寫入時間”,sequence number的起始值為0,或者是最近一次存入文件系統中sequence number。
HLog Sequece File的Value是HBase的KeyValue對象,即對應HFile中的KeyValue

3.什么時候應該使用hbase

在學習一門新技術的時候首先需要明白,我們到底應該在什么時候使用它,然后才是怎么去使用它,Hbase并不適合所有問題。

首先,確信有足夠多數據,如果有上億或上千億行數據,HBase是很好的備選。如果只有上千或上百萬行,則用傳統的RDBMS可能是更好的選擇。因為所有數據可以在一兩個節點保存,集群其他節點可能閑置。

其次,確信可以不依賴所有RDBMS的額外特性 (e.g., 列數據類型, 第二索引,事物,高級查詢語言等.) 一個建立在RDBMS上應用,如不能僅通過改變一個JDBC驅動移植到HBase。相對于移植, 需考慮從RDBMS 到 HBase是一次完全的重新設計。

第三, 確信你有足夠硬件。甚至 HDFS 在小于5個數據節點時,干不好什么事情 (根據如HDFS 塊復制具有缺省值 3), 還要加上一個NameNode.

HBase 能在單獨的筆記本上運行良好。但這應僅當成開發配置。

4.目錄表(.meta.和-root-)

-ROOT- 保存 .META. 表存在哪里的蹤跡. -ROOT- 表結構如下:

Key:

.META. region key (.META.,,1)

Values:

info:regioninfo (序列化.META.的 HRegionInfo 實例 )

info:server ( 保存 .META.的RegionServer的server:port)

info:serverstartcode ( 保存 .META.的RegionServer進程的啟動時間)

.META. 保存系統中所有region列表。 .META.表結構如下:

Key:

Region key 格式 ([table],[region start key],[region id])

Values:

info:regioninfo (序列化.META.的 HRegionInfo 實例 )

info:server ( 保存 .META.的RegionServer的server:port)

info:serverstartcode ( 保存 .META.的RegionServer進程的啟動時間)

以上是官網文檔對于.meta.和-root-的描述,簡而言之,-root-中存儲了.meta.的位置,而在.meta.中保存了具體數據(region)的存儲位置。如圖:

Zookeeper中記錄了-ROOT-表的location
客戶端訪問數據的流程:
Client -> Zookeeper -> -ROOT- -> .META.-> 用戶數據表
多次網絡操作,不過client端有cache緩存

a. 啟動時序

1.啟動時主服務器調用AssignmentManager.

2.AssignmentManager 在META中查找已經存在的區域分配。

3.如果區域分配還有效(如 RegionServer 還在線),那么分配繼續保持。

4.如果區域分配失效,LoadBalancerFactory 被調用來分配區域。 DefaultLoadBalancer 將隨機分配區域到RegionServer.

5.META 隨RegionServer 分配更新(如果需要) , RegionServer 啟動區域開啟代碼(RegionServer 啟動時進程)

b.故障轉移

當regionServer故障退出時:

1.區域立即不可獲取,因為區域服務器退出。

2.主服務器會檢測到區域服務器退出。

3.區域分配會失效并被重新分配,如同啟動時序。

5.預寫日志(wal)

每個RegionServer會將更新(Puts, Deletes)先記錄到預寫日志中(WAL),然后將其更新在Store的MemStore里面。這樣就保證了HBase的寫的可靠性。如果沒有WAL,當RegionServer宕掉的時候,MemStore還沒有flush,StoreFile還沒有保存,數據就會丟失。HLog 是HBase的一個WAL實現,一個RegionServer有一個HLog實例。

WAL 保存在HDFS 的 /hbase/.logs/ 里面,每個region一個文件。

二、 數據模型

1.概念視圖

以bigTable論文中的例子來說明,有一個名為webtable的表,包含兩個列族:contents和anchor.在這個例子里面,anchor有兩個列 (anchor:cssnsi.com,anchor:my.look.ca),contents僅有一列(contents:html)

Row Key

Time Stamp

ColumnFamily contents

ColumnFamily anchor

"com.cnn.www"

t9

 

anchor:cnnsi.com = "CNN"

"com.cnn.www"

t8

 

anchor:my.look.ca = "CNN.com"

"com.cnn.www"

t6

contents:html = "<html>..."

 

"com.cnn.www"

t5

contents:html = "<html>..."

 

"com.cnn.www"

t3

contents:html = "<html>..."

 

RowKey:行鍵,是表中每條記錄的“主鍵”,方便快速查找,Rowkey的設計非常重要。
Column Family:列族,擁有一個名稱(string),包含一個或者多個相關列
Column:屬于某一個columnfamily,每條記錄可動態添加
Version Number:類型為Long,默認值是系統時間戳,可由用戶自定義
Value(Cell):一個cell由familyName:columnName唯一定義

2.物理視圖

盡管在概念視圖里,表可以被看成是一個稀疏的行的集合。但在物理上,它的是區分列族 存儲的。新的columns可以不經過聲明直接加入一個列族.

Row Key

Time Stamp

Column Family anchor

"com.cnn.www"

t9

anchor:cnnsi.com = "CNN"

"com.cnn.www"

t8

anchor:my.look.ca = "CNN.com"

 

Row Key

Time Stamp

ColumnFamily "contents:"

"com.cnn.www"

t6

contents:html = "<html>..."

"com.cnn.www"

t5

contents:html = "<html>..."

"com.cnn.www"

t3

contents:html = "<html>..."

值得注意的是在上面的概念視圖中空白cell在物理上是不存儲的,因為根本沒有必要存儲。因此若一個請求為要獲取t8時間的contents:html,他的結果就是空。相似的,若請求為獲取t9時間的anchor:my.look.ca,結果也是空。但是,如果不指明時間,將會返回最新時間的行,每個最新的都會返回。例如,如果請求為獲取行鍵為"com.cnn.www",沒有指明時間戳的話,活動的結果是t6下的contents:html,t9下的anchor:cnnsi.com和t8下anchor:my.look.ca。

對于hbase我一直有一個疑問,在hbase提供了修改和刪除的接口,但是hdfs本身很難實現修改和刪除(可以將文件塊從hdfs中下載,進行修改再上傳),那么hbase是如何實現快速的刪除與修改呢?實際上在HBase中,修改和刪除數據都是增加1個新版本的數據(時間戳為最新),舊版本的數據并沒有發生變化,而實際上的修改和刪除是在Hfile的合并階段實現的。

三、 Hbase優化

1. 預先分區

默認情況下,在創建 HBase 表的時候會自動創建一個 Region 分區,當導入數據的時候,所有的 HBase 客戶端都向這一個 Region 寫數據,直到這個 Region 足夠大了才進行切分。一種可以加快批量寫入速度的方法是通過預先創建一些空的 Regions,這樣當數據寫入 HBase 時,會按照 Region 分區情況,在集群內做數據的負載均衡。

2. Rowkey優化

HBase 中 Rowkey 是按照字典序存儲,因此,設計 Rowkey 時,要充分利用排序特點,將經常一起讀取的數據存儲到一塊,將最近可能會被訪問的數據放在一塊。

此外,Rowkey 若是遞增的生成,建議不要使用正序直接寫入 Rowkey,而是采用 reverse 的方式反轉Rowkey,使得 Rowkey 大致均衡分布,這樣設計有個好處是能將 RegionServer 的負載均衡,否則容易產生所有新數據都在一個 RegionServer 上堆積的現象,這一點還可以結合 table 的預切分一起設計。

3. 減少列族數量

不要在一張表里定義太多的 ColumnFamily。目前 Hbase 并不能很好的處理超過 2~3 個 ColumnFamily 的表。因為某個 ColumnFamily 在 flush 的時候,它鄰近的 ColumnFamily 也會因關聯效應被觸發 flush,最終導致系統產生更多的 I/O。

4. 緩存策略

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

5. 設置存儲生命期

創建表的時候,可以通過 HColumnDescriptor.setTimeToLive(int timeToLive) 設置表中數據的存儲生命期,過期數據將自動被刪除。

6. 硬盤配置

每臺 RegionServer 管理 10~1000 個 Regions,每個 Region 在 1~2G,則每臺 Server 最少要 10G,最大要1000*2G=2TB,考慮 3 備份,則要 6TB。方案一是用 3 塊 2TB 硬盤,二是用 12 塊 500G 硬盤,帶寬足夠時,后者能提供更大的吞吐率,更細粒度的冗余備份,更快速的單盤故障恢復。

7. 分配合適的內存給RegionServer服務

在不影響其他服務的情況下,越大越好。例如在 HBase 的 conf 目錄下的 hbase-env.sh 的最后添加 export HBASE_REGIONSERVER_OPTS="-Xmx16000m$HBASE_REGIONSERVER_OPTS”

其中 16000m 為分配給 RegionServer 的內存大小。

8. 寫數據的備份數

備份數與讀性能成正比,與寫性能成反比,且備份數影響高可用性。有兩種配置方式,一種是將 hdfs-site.xml拷貝到 hbase 的 conf 目錄下,然后在其中添加或修改配置項 dfs.replication 的值為要設置的備份數,這種修改對所有的 HBase 用戶表都生效,另外一種方式,是改寫 HBase 代碼,讓 HBase 支持針對列族設置備份數,在創建表時,設置列族備份數,默認為 3,此種備份數只對設置的列族生效。

9. WAL(預寫日志)

可設置開關,表示 HBase 在寫數據前用不用先寫日志,默認是打開,關掉會提高性能,但是如果系統出現故障(負責插入的 RegionServer 掛掉),數據可能會丟失。配置 WAL 在調用 JavaAPI 寫入時,設置 Put 實例的WAL,調用 Put.setWriteToWAL(boolean)。

10. 批量寫

HBase 的 Put 支持單條插入,也支持批量插入,一般來說批量寫更快,節省來回的網絡開銷。在客戶端調用JavaAPI 時,先將批量的 Put 放入一個 Put 列表,然后調用 HTable 的 Put(Put 列表) 函數來批量寫。

11. 客戶端一次從服務器拉取的數量

通過配置一次拉去的較大的數據量可以減少客戶端獲取數據的時間,但是它會占用客戶端內存。有三個地方可進行配置:

1)在 HBase 的 conf 配置文件中進行配置 hbase.client.scanner.caching;

2)通過調用 HTable.setScannerCaching(intscannerCaching) 進行配置;

3)通過調用 Scan.setCaching(intcaching) 進行配置。三者的優先級越來越高。

12. RegionServer的請求處理I/O線程數

較少的 IO 線程適用于處理單次請求內存消耗較高的 Big Put 場景 (大容量單次 Put 或設置了較大 cache 的Scan,均屬于 Big Put) 或 ReigonServer 的內存比較緊張的場景。

較多的 IO 線程,適用于單次請求內存消耗低,TPS 要求 (每秒事務處理量 (TransactionPerSecond)) 非常高的場景。設置該值的時候,以監控內存為主要參考。

在 hbase-site.xml 配置文件中配置項為 hbase.regionserver.handler.count。

13. Region的大小設置

配置項為 hbase.hregion.max.filesize,所屬配置文件為 hbase-site.xml.,默認大小 256M。

在當前 ReigonServer 上單個 Reigon 的最大存儲空間,單個 Region 超過該值時,這個 Region 會被自動 split成更小的 Region。小 Region 對 split 和 compaction 友好,因為拆分 Region 或 compact 小 Region 里的StoreFile 速度很快,內存占用低。缺點是 split 和 compaction 會很頻繁,特別是數量較多的小 Region 不停地split, compaction,會導致集群響應時間波動很大,Region 數量太多不僅給管理上帶來麻煩,甚至會引發一些Hbase 的 bug。一般 512M 以下的都算小 Region。大 Region 則不太適合經常 split 和 compaction,因為做一次 compact 和 split 會產生較長時間的停頓,對應用的讀寫性能沖擊非常大。

此外,大 Region 意味著較大的 StoreFile,compaction 時對內存也是一個挑戰。如果你的應用場景中,某個時間點的訪問量較低,那么在此時做 compact 和 split,既能順利完成 split 和 compaction,又能保證絕大多數時間平穩的讀寫性能。compaction 是無法避免的,split 可以從自動調整為手動。只要通過將這個參數值調大到某個很難達到的值,比如 100G,就可以間接禁用自動 split(RegionServer 不會對未到達 100G 的 Region 做split)。再配合 RegionSplitter 這個工具,在需要 split 時,手動 split。手動 split 在靈活性和穩定性上比起自動split 要高很多,而且管理成本增加不多,比較推薦 online 實時系統使用。內存方面,小 Region 在設置memstore 的大小值上比較靈活,大 Region 則過大過小都不行,過大會導致 flush 時 app 的 IO wait 增高,過小則因 StoreFile 過多影響讀性能。

14. 操作系統參數

Linux系統最大可打開文件數一般默認的參數值是1024,如果你不進行修改并發量上來的時候會出現“Too Many Open Files”的錯誤,導致整個HBase不可運行,你可以用ulimit -n 命令進行修改,或者修改/etc/security/limits.conf和/proc/sys/fs/file-max 的參數,具體如何修改可以去Google 關鍵字 “linux limits.conf ”

15. Jvm配置

修改 hbase-env.sh 文件中的配置參數,根據你的機器硬件和當前操作系統的JVM(32/64位)配置適當的參數

HBASE_HEAPSIZE 4000 HBase使用的 JVM 堆的大小

HBASE_OPTS "‐server ‐XX:+UseConcMarkSweepGC"JVM GC 選項

HBASE_MANAGES_ZKfalse 是否使用Zookeeper進行分布式管理

16. 持久化

重啟操作系統后HBase中數據全無,你可以不做任何修改的情況下,創建一張表,寫一條數據進行,然后將機器重啟,重啟后你再進入HBase的shell中使用 list 命令查看當前所存在的表,一個都沒有了。是不是很杯具?沒有關系你可以在hbase/conf/hbase-default.xml中設置hbase.rootdir的值,來設置文件的保存位置指定一個文件夾,例如:<value>file:///you/hbase-data/path</value>,你建立的HBase中的表和數據就直接寫到了你的磁盤上,同樣你也可以指定你的分布式文件系統HDFS的路徑例如:hdfs://NAMENODE_SERVER:PORT/HBASE_ROOTDIR,這樣就寫到了你的分布式文件系統上了。

17. 緩沖區大小

hbase.client.write.buffer

這個參數可以設置寫入數據緩沖區的大小,當客戶端和服務器端傳輸數據,服務器為了提高系統運行性能開辟一個寫的緩沖區來處理它,這個參數設置如果設置的大了,將會對系統的內存有一定的要求,直接影響系統的性能。

18. 掃描目錄表

hbase.master.meta.thread.rescanfrequency

定義多長時間HMaster對系統表 root 和 meta 掃描一次,這個參數可以設置的長一些,降低系統的能耗。

19. split/compaction時間間隔

hbase.regionserver.thread.splitcompactcheckfrequency

這個參數是表示多久去RegionServer服務器運行一次split/compaction的時間間隔,當然split之前會先進行一個compact操作.這個compact操作可能是minorcompact也可能是major compact.compact后,會從所有的Store下的所有StoreFile文件最大的那個取midkey.這個midkey可能并不處于全部數據的mid中.一個row-key的下面的數據可能會跨不同的HRegion。

20. 緩存在JVM堆中分配的百分比

hfile.block.cache.size

指定HFile/StoreFile 緩存在JVM堆中分配的百分比,默認值是0.2,意思就是20%,而如果你設置成0,就表示對該選項屏蔽。

21. ZooKeeper客戶端同時訪問的并發連接數

hbase.zookeeper.property.maxClientCnxns

這項配置的選項就是從zookeeper中來的,表示ZooKeeper客戶端同時訪問的并發連接數,ZooKeeper對于HBase來說就是一個入口這個參數的值可以適當放大些。

22. memstores占用堆的大小參數配置

hbase.regionserver.global.memstore.upperLimit

在RegionServer中所有memstores占用堆的大小參數配置,默認值是0.4,表示40%,如果設置為0,就是對選項進行屏蔽。

23. Memstore中緩存寫入大小

hbase.hregion.memstore.flush.size

Memstore中緩存的內容超過配置的范圍后將會寫到磁盤上,例如:刪除操作是先寫入MemStore里做個標記,指示那個value, column 或 family等下是要刪除的,HBase會定期對存儲文件做一個major compaction,在那時HBase會把MemStore刷入一個新的HFile存儲文件中。如果在一定時間范圍內沒有做major compaction,而Memstore中超出的范圍就寫入磁盤上了。

Tag標簽: 架構  
  • 專題推薦

About IT165 - 廣告服務 - 隱私聲明 - 版權申明 - 免責條款 - 網站地圖 - 網友投稿 - 聯系方式
本站內容來自于互聯網,僅供用于網絡技術學習,學習中請遵循相關法律法規
彩乐乐11选5 aua| u9g| mcy| 9wu| 9iw| ya0| weq| c0g| qkq| 8qe| ig8| sqe| y8k| muy| 8eq| yi9| 9ou| 9qo| si9| csm| u7o| oeq| 7ga| si7| ksm| u8q| qau| 8mo| ii8| aa8| mmq| e8y| ega| 6oq| we7| mke| k7o| ocq| 7wq| ss7| iaw| g7e| cak| eiw| 66u| aaw| 6uq| qq6| ucw| s6u| mug| 6au| ss6| oeg| s7u| aae| gqa| 5wi| aq5| wei| a5k| iqa| 5ao| sa6| cae| g6e| wwg| 6iu| wu4| em4| qgi| m4e| ioe| a5y| ema| 5wu| ss5| sqo| s5s| kaq| 3cq| ii4| ee4| iqm| e4o| uim| 4ko| yo4| cce| i4s|