7、ActiveMQ的持久訊息儲存方案

前文已經講過，當ActiveMQ接收到PERSISTENT Message訊息後就需要藉助持久化方案來完成PERSISTENT Message的儲存。這個介質可以是磁碟檔案系統、可以是ActiveMQ的內建資料庫，還可以是某種外部提供的關係型資料庫。本節筆者將向讀者講解三種ActiveMQ推薦的儲存方案的配置使用。

• 如上圖2.1的步驟所示，所有PERSISTENT Message都要執行持久化儲存操作，持久化儲存操作方案的效能直接影響著整個MQ服務端的PERSISTENT Message吞吐效能。另外NON_PERSISTENT Message雖然不會進行持久化儲存，但是NON_PERSISTENT Message也不是永遠都只存在與記憶體區域。

• 有的讀者會問，Topic模式的工作佇列在沒有任何活動訂閱者的情況下也會對PERSISTENT Message進行持久化儲存嗎？當然會，因為Topic模式的工作佇列還要考慮“Durable Topic Subscribers”形式的訂閱者。即使沒有“Durable Topic Subscribers”形式的訂閱者，先儲存再標記的過程也不會改變（只是不一定真正進入物理磁碟）。

• 有的讀者還會問，在客戶端啟動事務的情況下，如果沒有事務的commit操作，PERSISTENT Message也會進行持久化儲存嗎？當然還是會，前文我們已經講過沒有做事務的commit只是說這些事務中的訊息不會進行確認操作，不會分發到某個指定的具體佇列中；但是只要使用了send方法，PERSISTENT Message就會被髮送到服務端，就會進行持久化儲存操作

  。

• 如上圖中被標示為2.2的操作步驟所示，在ActiveMQ設定的持久化方案完成某條訊息的持久化後，會在ActiveMQ服務節點的內部發出一個“完成”訊號。這是為了告訴ActiveMQ服務節點自己，是否可以進行下一步操作。但是為了加快ActiveMQ服務節點內部的處理效率，這個過程可以設定為“非同步”。

• 那麼進行了持久化儲存的PERSISTENT Message什麼時候被刪除呢？就如同之前我們提到的一樣，ActiveMQ服務端只有在收到消費者端某一條訊息或某一組訊息的ACK標示後，才會認為訊息被消費者端正確處理了。就是在這個時候，ActiveMQ會通知持久化方案，進行刪除這一條或者這一組訊息的操作，並空閒出相應的儲存空間。如上圖被標示為5.1的操作步驟所示。

7-1、儲存方案配置

在介紹ActiveMQ的儲存方案之前，首先需要明確的是ActiveMQ中的幾種“容量”描述：

• ActiveMQ的核心是Java編寫的，也就是說如果服務端沒有Java執行環境ActiveMQ是無法執行的。ActiveMQ啟動時，啟動指令碼使用wrapper包裝器來啟動JVM。JVM相關的配置資訊在啟動目錄的“wrapper.conf”配置檔案中。各位讀者可以通過改變其中的配置項，設定JVM的初始記憶體大小和最大記憶體大小（當然還可以進行其他和JVM有關的設定，例如開啟debug模式），如下：

......

# Initial Java Heap Size (in MB)
wrapper.java.initmemory=100

# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=512

......

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9

以上配置項設定JVM的初始記憶體大小為100MB，設定JVM的最大記憶體大小為512MB。如果您在更改後使用console引數啟動ActiveMQ，那麼會看到當前ActiveMQ的JVM設定發生了變化：

• 明確了ActiveMQ的記憶體區域來源，才好理解後續的設定內容。ActiveMQ每一個服務節點都是一個獨立的程序。在ActiveMQ主配置檔案中，讀者可以找到一個“systemUsage”標記，類似定義如下：

<systemUsage>
    <systemUsage>
        <memoryUsage>
            <memoryUsage percentOfJvmHeap="70" />
        </memoryUsage>
        <storeUsage>
            <storeUsage limit="100 gb"/>
        </storeUsage>
        <tempUsage>
            <tempUsage limit="50 gb"/>
        </tempUsage>
    </systemUsage>
</systemUsage>

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13

systemUsage：該標記用於設定整個ActiveMQ節點在程序級別的各種“容量”的設定情況。其中可設定的屬性包括：sendFailIfNoSpaceAfterTimeout，當ActiveMQ收到一條訊息時，如果ActiveMQ這時已經沒有多餘“容量”了，那麼就會等待一段時間（這裡設定的毫秒數），如果超過這個等待時間ActiveMQ仍然沒有可用的容量，那麼就拒絕接收這條訊息並在訊息的傳送端丟擲javax.jms.ResourceAllocationException異常；sendFailIfNoSpace，當ActiveMQ收到一條訊息時，如果ActiveMQ這時已經沒有多餘“容量”了，就直接拒絕這條訊息（不用等待一段時間），並在訊息的傳送端丟擲javax.jms.ResourceAllocationException異常。

memoryUsage：該子標記設定整個ActiveMQ節點的“可用記憶體限制”。這個值不能超過上文中您設定的JVM maxmemory的值。其中的percentOfJvmHeap屬性表示使用“百分數值”進行設定，除了這個屬性以外，您還可以使用limit屬性進行固定容量授權，例如：limit=”1000 mb”。這些記憶體容量將供所有佇列使用。

storeUsage：該標記設定整個ActiveMQ節點，用於儲存“持久化訊息”的“可用磁碟空間”。該子標記的limit屬性必須要進行設定。在使用後續介紹的KahaDB方案或者LevelDB方案進行PERSISTENT Message持久化儲存時，這個storeUsage屬性都會起作用；但是如果使用資料庫儲存方案，這個屬性就不會起作用了。

tempUsage：在ActiveMQ 5.X+ 版本中，一旦ActiveMQ服務節點儲存的訊息達到了memoryUsage的限制，NON_PERSISTENT Message就會被轉儲到 temp store區域。雖然我們說過NON_PERSISTENT Message不進行持久化儲存，但是ActiveMQ為了防止“資料洪峰”出現時NON_PERSISTENT Message大量堆積致使記憶體耗盡的情況出現，還是會將NON_PERSISTENT Message寫入到磁碟的臨時區域——temp store。這個子標記就是為了設定這個temp store區域的“可用磁碟空間限制”。最後提醒各位讀者storeUsage和tempUsage並不是“最大可用空間”，而是一個閥值。

7-2、ActiveMQ中持久化儲存方案的演化

說到ActiveMQ中持久化儲存方案的演化問題，如果您仔細閱讀ActiveMQ官方文件中關於持久化部分的描述，您就不難發現ActiveMQ的開發團隊在針對持久化效能問題的優化上可謂與時俱進。這也符合一款健壯軟體的生命週期特徵：任何功能特性都在進行不斷累計完善：

從最初的AMQ Message Store方案，到ActiveMQ V4版本中推出的High performance journal（高效能事務支援）附件 ，並且同步推出了關於關係型資料庫的儲存方案。ActiveMQ 5.3版本中又推出了對KahaDB的支援（V5.4版本後稱為ActiveMQ預設的持久化方案），後來ActiveMQ V5.8版本開始支援LevelDB，到現在，V5.9+版本提供了標準的Zookeeper+LevelDB叢集化方案。下面我們重點介紹一下ActiveMQ中KahaDB、LevelDB和關係型資料庫這三種持久化儲存方案。並且會和讀者一起，使用Zookeeper搭建LevelDB叢集儲存方案。

對於最初的AMQ Message Store方案，ActiveMQ官方已不再推薦使用（實際上在筆者的實際工作中，也不會使用AMQ Message Store）。如果各位讀者想進行了解可以自行搜尋相關資料，這裡不再進行介紹。

7-3、KahaDB儲存方案

7-3-1、KahaDB基本結構

KahaDB is a file based persistence database that is local to the message broker that is using it. It has been optimised for fast persistence and is the the default storage mechanism from ActiveMQ 5.4 onwards. KahaDB uses less file descriptors and provides faster recovery than its predecessor, the AMQ Message Store.

以上引用自Apache ActiveMQ 官方對KahaDB的定義。首先KahaDB基於檔案系統，其次KahaDB支援事務。在ActiveMQ V5.4版本及後續版本KahaDB都是ActiveMQ的預設持久化儲存方案。最後Apache ActiveMQ官方表示它用來替換之前的AMQ Message Store儲存方案。

KahaDB主要元素包括：一個記憶體Metadata Cache用來在記憶體中檢索訊息的儲存位置、若干用於記錄訊息內容的Data log檔案、一個在磁碟上檢索訊息儲存位置的Metadata Store、還有一個用於在系統異常關閉後恢復Btree結構的redo檔案。如下圖所示（官網引用）：

以下是KahaDB在磁碟檔案上的現實展示。注意，可能您檢視自己測試例項中所執行的KahaDB，看到的效果和本文中給出的效果不完全一致。例如您的data log檔案可能叫db-1.log，也有可能會多出一個db.free的檔案，但是這些都不影響我們對檔案結構的分析：

[[email protected] KahaDB]# ll -h
總用量 29M
-rw-r--r--. 1 root root  32M 4月   7 04:53 db-3.log
-rw-r--r--. 1 root root 7.6M 4月   7 04:53 db.data
-rw-r--r--. 1 root root 2.8M 4月   7 04:53 db.redo
-rw-r--r--. 1 root root    8 4月   7 04:50 lock

• 1
• 2
• 3
• 4
• 5
• 6

• db-3.log：這個檔案就是我們上文提到的Data log檔案。一個KahaDB中，可能同時存在多個Data log檔案，他們儲存了每一條持久化訊息的真正內容。這些Data log檔案統一採用db-*.log的格式進行命名，並且每個Data log檔案預設的大小都是32M（當然是可以進行設定的）。當一個Data log檔案中的所有訊息全部被成功訊息後，這個Data log檔案會在Metadata Cache中被標記為刪除，並在下個checkpoint週期進行刪除操作。

• 各位讀者可能已經注意到一個現象：為什麼db-3.log的預設佔用大小就是32M，但是目錄顯示的“總用量”卻只有29M呢？在這個資料夾中，除了db-3.log檔案本身，加上其他幾個檔案所佔用的大小，已經遠遠超過了32M！這是因為，為了加快寫檔案的效能，Data log檔案採用順序寫的方式進行操作，為了保證檔案使用的扇區在物理上是連續的，所以Data log檔案需要預佔這些扇區（這個和Hadoop中每一個block大小都是固定的原因相似）。雖然您看到Data log檔案佔用的32M的磁碟空間，但是這些磁碟空間並沒有全部使用。另外，關於隨機讀寫和連續讀寫的巨大效能差異，我會在今年下半年新的“資料儲存專欄”中，進行詳細介紹。

• 為了更快的找到某個具體訊息在Data log檔案中的具體位置。訊息的位置索引採用BTree的結構被儲存在記憶體中，這個記憶體區域就是上文提到的Metadata Cache（大小也是可以設定的）。要知道Mysql的Innodb 儲存引擎也是採用BTree結構構造索引結構（用了都說快哦~~）。所以一般情況下，只要某個佇列有活動的消費者存在，訊息的定位、讀取操作是可以很快完成的。

• 記憶體中沒有被處理的訊息索引會以一定的週期（或者一定的數量規模）為依據，同步（checkpoint）到Metadata Store中，這就是我們在上文中看到的“db.data”檔案。當然db.redo檔案也會被更新，以便在ActiveMQ服務節點在重啟後對Metadata Cache進行恢復。最後，訊息同步（checkpoint）依據，可以在ActiveMQ的主配置檔案中進行設定。

7-3-2、在ActiveMQ中配置KahaDB

由於在ActiveMQ V5.4+的版本中，KahaDB是預設的持久化儲存方案。所以即使您不配置任何的KahaDB引數資訊，ActiveMQ也會啟動KahaDB。這種情況下，KahaDB檔案所在位置是您的ActiveMQ安裝路徑下的/data/${broker.Name}/KahaDB子目錄。其中${broker.Name}代表這個ActiveMQ服務節點的名稱。

正式的生產環境還是建議您在主配置檔案中明確設定KahaDB的工作引數。如下所示：

......
<broker xmlns="http://activemq.apache.org/schema/core"  brokerName="localhost" dataDirectory="${activemq.data}">
    ......
    <persistenceAdapter>
        <kahaDB directory="${activemq.data}/kahadb"/>
    </persistenceAdapter>
    ......
</broker>
......

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9

以上配置項設定使用kahaDB為持久化儲存方法，並且設定kahaDB的工作目錄為ActiveMQ安裝路勁下/data/kahadb目錄。如果您需要Data log檔案預設的32M的大小，可以使用journalMaxFileLength屬性進行設定，如下所示：

......
<broker xmlns="http://activemq.apache.org/schema/core"  brokerName="localhost" dataDirectory="${activemq.data}">
    ......
    <persistenceAdapter>
        <kahaDB directory="${activemq.data}/kahadb" journalMaxFileLength="64mb"/>
    </persistenceAdapter>
    ......
</broker>
......

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9

您還可以設定為：當Metadata Cache中和Metadata Store中不同的索引條數達到500條時，就進行checkpoint同步。如下所示：

......
<broker xmlns="http://activemq.apache.org/schema/core"  brokerName="localhost" dataDirectory="${activemq.data}">
    ......
    <persistenceAdapter>
        <kahaDB directory="${activemq.data}/kahadb" journalMaxFileLength="64mb" indexWriteBatchSize="500"/>
    </persistenceAdapter>
    ......
</broker>
......

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9

以下表格為讀者示例了KahaDB中所有的配置選項和其含義（引用自網路，加“*”部分是筆者認為重要的配置選項）：

property name	default value	Comments
*directory	activemq-data	訊息檔案和日誌的儲存目錄
*indexWriteBatchSize	1000	當Metadata cache區域和Metadata store區域不同的索引數量達到這個值後，Metadata cache將會發起checkpoint同步
*indexCacheSize	10000	記憶體中，索引的頁大小。超過這個大小Metadata cache將會發起checkpoint同步
*enableIndexWriteAsync	false	索引是否非同步寫到訊息檔案中，將以不要設定為true
*journalMaxFileLength	32mb	一個訊息檔案的大小
*enableJournalDiskSyncs	true	如果為true，保證使用同步寫入的方式持久化訊息到journal檔案中
*cleanupInterval	30000	清除（清除或歸檔）不再使用的db-*.log檔案的時間週期（毫秒）。
*checkpointInterval	5000	寫入索引資訊到metadata store中的時間週期（毫秒）
ignoreMissingJournalfiles	false	是否忽略丟失的journal檔案。如果為false，當丟失了journal檔案時，broker啟動時會拋異常並關閉
checkForCorruptJournalFiles	false	檢查訊息檔案是否損壞，true，檢查發現損壞會嘗試修復
checksumJournalFiles	false	產生一個checksum，以便能夠檢測journal檔案是否損壞。

• 5.4版本之後有效的屬性:

property name	default value	Comments
*archiveDataLogs	false	當為true時，歸檔的訊息檔案被移到directoryArchive,而不是直接刪除
*directoryArchive	null	儲存被歸檔的訊息檔案目錄
databaseLockedWaitDelay	10000	在使用負載時，等待獲得檔案鎖的延遲時間，單位ms
maxAsyncJobs	10000	等待寫入journal檔案的任務佇列的最大數量。應該大於或等於最大併發producer的數量。配合並行儲存轉發屬性使用。
concurrentStoreAndDispatchTopics	false	如果為true，轉發訊息的時候同時提交事務
concurrentStoreAndDispatchQueues	true	如果為true，轉發Topic訊息的時候同時儲存訊息的message store中

• 5.6版本之後有效的屬性:

property name	default value	Comments
archiveCorruptedIndex	false	是否歸檔錯誤的索引到Archive資料夾下

• 5.10版本之後有效的屬性:

property name	default value	Comments
IndexDirectory	單獨設定KahaDB中，db.data檔案的儲存位置。如果不進行設定，db.data檔案的儲存位置還是將以directory屬性設定的值為準

7-4、LevelDB儲存方案

LevelDb是能夠處理十億級別規模Key-Value型資料永續性儲存的C++ 程式庫，由Google發起並開源。LevelDB只能由本作業系統的其他程序呼叫，所以它不具有網路性。如果您需要網路上的遠端程序操作LevelDB，那麼就要自行封裝服務層。

7-4-1、LevelDB基本結構

LevelDB中的核心設計演算法是跳躍表（Skip List），核心操作策略是對磁碟上的資料日誌結構進行歸併（LSM）。跳躍表實際上是二叉平衡樹的一種變形結構，它通過將一個有序連結串列進行“升維”操作，從而減少每一層上需要遍歷的資料數量，達到快速查詢的目的。下圖示意了一個跳躍表結構（在實際工作中，跳躍表的層級和“升維”策略的不同，跳躍表的結構也不一樣）：

您可以將上圖中的每個元素節點，想象成每一條訊息的key值。為了講解方便，上圖中我將擁有全部資料的元素的跳躍層稱為Level 2（最高層），但實際上規範的跳躍表結構中，擁有全部元素的層次稱為Level 0（最底層）。跳躍表的結構並非一成不變，當有一條新的記錄需要插入到結構時，可能會引起表中的多個Level都發生變化。

那麼LevelDB是如何應用跳躍表結構的？又是如何進行歸併操的？我們首先來看看LevelDB的簡要結構：

• Log檔案

當LevelDB收到新的訊息是會同步寫兩個地方：記憶體中的MemTable區域和磁碟上的Log檔案。直接寫Log檔案是為了在系統異常退出並重啟時，能夠將LevelDB恢復到退出前的結構；那麼有的讀者會問，由於是直接寫磁碟會不會成為效能瓶頸呢？答案是，LevelDB的log檔案操作採用預佔磁碟空間（預設為100MB），進行順序寫的方式。並且這個過程可以設定為非同步的（當然如果設定成非同步的，可能需要接受異常情況下資料丟失的風險）。

• MemTable和Immutable

LevelDB還寫將訊息寫入記憶體的MemTable區域，MemTable區域的的資料組織結構就是跳躍表（Skip List），這樣的資料組織結構可以在讀取記憶體中資訊的時候，快速完成資訊定位。當MemTable區域的資料量達到indexWriteBufferSize屬性設定的大小時（預設為6MB），LevelDB就會把這個MemTable區域標記為Immutable，並開啟一個新的MemTable區域。一定注意，是標記為Immutable，而不是把MemTable區域的資料拷貝到某一個Immutable區域。

新標記的Immutable區域中的資料會被執行Compact操作，從而寫入到磁碟上的.sst檔案中。所謂Compact操作是指：LevelDB會剔除Immutable區域中那些已經被標示為“刪除”的資料（成功消費的資料就會被標記為“刪除”），排除那些格式錯誤的資料，並可能進行資料壓縮。

• SSTable檔案

SSTable檔案是指存在於硬碟上，字尾名為.sst的檔案。這些檔案是LevelDB磁碟上最重要的資料記錄檔案，每一個SSTable檔案的預設大小為2MB，也就是說LevelDB的資料夾下會有很多的.sst檔案。SSTable檔案並不是順序寫的，而是按照資料的key排序進行隨機寫，所以SSTable檔案無需預佔儲存磁碟儲存空間。

借鑑於跳躍表的設計思想，SSTable檔案也是分層次的。每一層可儲存的資料量是上一層的的10倍。舉個例子，第Level 2層可儲存的資料量80MB，那麼第Level 3層可儲存的資料量就是800MB。當某一層可儲存的資料量達到最大值，LevelDB就會從當層選取一個.sst檔案，向下層做Compact操作，由於來自於上層的新資料，所以下層的.sst檔案內容將產生變化（上文說過，.sst檔案中的內容是按照資料的key排序的）。

每一個SSTable檔案，由多個Block塊構成（預設大小為4KB），block塊是LevelDB讀寫磁碟上SSTable檔案的最小單元。每一個SSTable檔案最後一個Block塊稱為Index Block，它指明瞭SSTable檔案中每一個Data block的起始位置。

但是每次讀取某個Block塊時，如果都在磁碟上先去找Index Block，然後再根據其中記錄的index，找到Block在檔案的起始位置的話，查詢效率顯然不高。所以LevelDB的記憶體區域中，有一個稱為Block Cache的區域。這個區域儲存著眾多的Index Block，這樣就不需要到磁碟上查詢Index Block了。

• Manifest

那麼眾多的.sst檔案是如何被管理的呢？要知道如果在眾多.sst檔案中進行某條訊息的查詢時，如果將某一層的.sst檔案全部進行遍歷，那麼效能肯定是不能接受的。在LevelDB中有一類檔案被稱為Manifest，這些Manifest檔案記錄了sst檔案的關鍵資訊，包括（但不限於）：某個.sst檔案屬於哪一個Level、這個.sst檔案中最小的key值、這個.sst檔案中最大的key值。

7-4-2、在ActiveMQ中配置LevelDB

在ActiveMQ中配置使用LevelDB作為持久化儲存方案實際上很簡單，使用主配置檔案中的persistenceAdapter標記就可以完成。最簡配置如下所示：

......
<broker xmlns="http://activemq.apache.org/schema/core"  brokerName="localhost" dataDirectory="${activemq.data}">
    ......
    <persistenceAdapter>
        <levelDB directory="${activemq.data}/levelDB"/>
    </persistenceAdapter>
    ......
</broker>
......

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9

以上示例配置中，directory屬性表示LevelDB的結構檔案所放置的目錄位置。請注意，由於log檔案是順序寫的機制，所以log檔案也會預佔磁碟空間，並且log檔案預設的大小就是100MB。那麼只要生成一個log檔案，就至少會佔據100MB的儲存空間（但這不代表總的已使用量）。也就是說，如果您將主配置檔案中storeUsage標記的limit屬性設定為200mb，那麼透過ActiveMQ管理介面看到的現象就是：只要有任何一條PERSISTENT Message被接受，Store percent used立刻就會變成50%。如果您將storeUsage標記的limit屬性為100mb，那麼只要有任何一條PERSISTENT Message被接受，ActiveMQ服務端的Producer Flow Control策略就會立刻開始工作。

所以一定不要吝嗇分配memoryUsage、storeUsage。依據您的團隊在生產環境下的儲存方案，也可以通過logSize屬性改變LevelDB中單個log檔案的大小。如下示例：

......
<!-- 限制成50mb -->
<persistenceAdapter>
    <levelDB directory="${activemq.data}/levelDB" logSize="52428800"/>
</persistenceAdapter>
......

• 1
• 2
• 3
• 4
• 5
• 6

上一小節我們介紹到，預設的LevelDB儲存策略中，當ActiveMQ接收到一條訊息後，就會同步將這條訊息寫入到log檔案中，並且同時在記憶體區域向Memtable寫入位置索引。通過配置您也可以將這個過程改為“非同步”：

......
<!-- 改為非同步寫log檔案 -->
<persistenceAdapter>
    <levelDB directory="${activemq.data}/levelDB" logSize="52428800" sync="false"/>
</persistenceAdapter>
......

• 1
• 2
• 3
• 4
• 5
• 6

以下列表展示了您可以使用的LevelDB的配置屬性，使用“*”標識出來的屬性是筆者認為重要的配置項：

property name	default value	Comments
*directory	“LevelDB”	資料檔案的儲存目錄
sync	true	是否進行磁碟的同步寫操作
*logSize	104857600 (100 MB)	log日誌檔案的最大值
verifyChecksums	false	是否對從檔案系統中讀取的資料進行強制校驗校驗
paranoidChecks	false	如果LevelDB檢測到資料錯誤，則儘快將錯誤在儲存位置進行標記
indexFactory	org.fusesource.leveldbjni.JniDBFactory, org.iq80.leveldb.impl.Iq80DBFactory	建立LevelDB時使用的工廠類，由於LevelDB的本質是C++程式庫，所以Java是通過Jni進行底層呼叫的
*indexMaxOpenFiles	1000	可供索引使用的開啟檔案的數量，這是因為Level內部使用了多執行緒進行檔案讀寫操作
indexWriteBufferSize	6291456 (6 MB)	記憶體MemTable的最大值，如果MemTable達到這個值，就會被標記為Immutable
indexBlockSize	4096 (4 K)	每個讀取到記憶體的SSTable——Index Block資料的大小
*indexCacheSize	268435456 (256 MB)	使用一個記憶體區域記錄多個Level中，SSTable——Index Block資料，以便讀操作時，不經過遍歷就可直接定位資料在某個level中的位置，建議增大該區域
indexCompression	snappy	適用於索引塊的壓縮型別，影響Compression策略
logCompression	none	適用於日誌記錄的壓縮型別，影響Compression策略

相關推薦