Clickhouse 的奇葩儲存機制，你注意到沒？

之所以說它奇葩，原因在於對於一個資料庫來說，我頭一次遇到，如果要對資料的儲存目錄(磁碟)設定多個的話，會這麼麻煩。

為什麼會突然注意到這個問題，原因在於之前部署的 clickhouse (下稱 CK) 叢集，為了方便，其資料儲存路徑只配置了一個(一塊磁碟)，但是隨著資料的持續寫入，發現這塊盤的磁碟空間逐漸開始遭不住了。

於是想著，再給它額外新增2個目錄，畢竟，我這伺服器上還有另外2塊磁碟沒有用上呢。

但是，就是這麼一件看似特別簡單的事情，到了 CK 這裡，可謂大有乾坤，當然，在我決定要寫這篇文章的時候，這裡面的彎彎繞繞已基本上被我理清楚了。

那麼這篇文章，就想來跟你聊一聊關於 CK 在儲存配置上的一些，跟其他資料庫有所不同的地方。

0. 關於CK的儲存規則

對於 CK 來說，如果你只有一個儲存目錄(一塊磁碟)，那好說，直接配置成預設儲存就好，比如在主配置檔案 config.xml 中這麼寫：

就能夠滿足 CK 對於資料的基礎儲存需求，其他亂八七糟一些跟儲存相關的，更加複雜的概念和配置，你根本就不需要搭理。

但是，一旦你對它的資料儲存有著更高，更多樣的需求之後，你就必須要了解下面這幾個概念了：

1. 儲存策略(storage policy)

對於 CK 來說，可以有大於等於1個的儲存策略，預設的儲存策略叫 default，而且必須存在，且不可更改。

對於任何一個儲存策略來說，可以配置多個「卷(volume)」，但大部分情況下，其實配置一個卷就夠了，而每個卷下面，又可以配置多個儲存路徑(多塊磁碟)：

但是呢，這裡有個我認為比較奇葩的意外，那就是對於這個必須存在的 default 儲存策略，它卻只能配置一個儲存目錄(一塊磁碟)。

至於我是怎麼知道的，其實官方文件並沒有明確告知，我是根據以往經驗，試錯試出來的，這個後文會講。

2. 卷(volume)

這個是儲存策略的下一級，是一個邏輯的概念，每個儲存策略可以包含多個卷，但是在我的經驗裡，絕大多數情況，用一個卷就夠了，而一個卷，又可以配置多塊磁碟。

比如這裡的 volume01 包含 disk02 跟 disk03：

在資料寫入的時候，配置了該卷對應的儲存策略的表，會將資料並行寫入到這2個目錄中，提高IO效率。

3. 預設磁碟(default disk)

必須指定的資料儲存目錄，只能指定一個(一塊磁碟)，會儲存所有表的後設資料資訊。此外，在建表的時候，除非特別設定，否則資料也全都會儲存到個目錄中。

4. 其他盤(disk)

必須要跟上面的預設盤分開，也必須隸屬於除 default 儲存策略之外的其他策略。

比如：

而且，從配置檔案給出的配置案例來看，這個 disk 的型別相當之豐富，除了可以配置本地的磁碟目錄外，還可以配置外部的檔案系統，比如S3、HDFS等。

1. 測試驗證

其實一開始的時候，我的想法非常樸素，不就是額外再加硬碟嘛，那我直接在原來配置的基礎上，再把新的磁碟目錄添上不就行了嗎，畢竟之前的 ES 就是這麼幹的。

ES的多磁碟配置

雖然不知道符不符合配置規範，但，來都來了，那就試試唄。

於是，照貓畫虎，為了防止意外發生，我新找了一臺機器，根據這臺機器的磁碟情況，在預設儲存的位置，配了兩個目錄。

結果你猜怎麼著，CK服務居然可以啟動成功。

只不過，結果跟咱想的有點不太一樣，CK並沒有把這個配置當成兩個目錄，而是一個。

看得我哭笑不得，算了，不折騰了。

你說要是官網，或者配置檔案裡面的解釋說明裡，能順帶提那麼一嘴，「就只允許配置一個單目錄」，我也不至於幹出這麼讓人尷尬的事情來不是。

那正確的玩法是什麼樣的呢？

來看一眼，我研究一番之後的配置，這裡既配置了額外的2個本地磁碟目錄，還新增了另外一個 hadoop 叢集的HDFS儲存路徑。

  <path>/hddata01/clickhouse/</path>

  <storage_configuration>
   <disks>
       <disk02>
           <path>/hddata02/clickhouse/</path>
       </disk02>
       <disk03>
           <path>/hddata03/clickhouse/</path>
       </disk03>
       <hdfs>
           <type>hdfs</type>
           <endpoint>hdfs://xxxxx:8020/DATA/clickhouse/</endpoint>
       </hdfs>
   </disks>
      <policies>
          <policy01>
              <volumes>
                  <volume01>
                      <disk>disk02</disk>
                      <disk>disk03</disk>
                  </volume01>
            </volumes>
        </policy01>
        <policy02>
            <volumes>
                <volume01>
                    <disk>hdfs</disk>
                </volume01>
            </volumes>
        </policy02>
      </policies>
  </storage_configuration>

這個配置檔案對應有2個儲存策略，其儲存策略、卷、磁碟的關係如下：

policy01關係圖

policy02關係圖

如此配置之後，CK服務就能正常啟動起來。

服務啟動之後，為了檢驗剛才配置是否生效，我們需要在命令列中，去查詢一些相關的資訊。

這裡就要涉及到兩張重要的「系統表」，一張叫： system.storage_policies ，另一張叫：system.disks (按理來說應該還有一張 system.volumes 的表才對，但是沒有，不過不影響)。

查詢當前 CK 包含有哪些儲存策略：

可以看到，配置裡新新增的額外2個儲存策略已經能查到了。

再查詢當前CK可用的磁碟情況。

2. 如何使用

CK 的這種儲存機制，比較膈應的一點在於，它不像其他資料庫那麼“傻瓜式”，你配了幾個目錄，所有表的資料，就往幾個目錄裡寫，至於怎麼寫？輪休還是併發，由資料庫自己來決定。

但是 CK 不一樣，它應該是我目前為止接觸的資料庫中，把“手動擋”理念貫徹得最徹底的一個了。

建表時，如果你不額外指定「儲存策略」，那麼就使用的預設(default)儲存策略，對應的資料也只會儲存到 default 策略對應的目錄上(且只能配一個)。

先隨便建張表：

然後透過查詢 system.tables 這張表，就可以知道當前建立的表，用的哪個儲存策略，以及對應的目錄。

往裡寫入幾條資料後，再透過另一張表 system.parts 來檢視資料在目錄中的儲存情況。

可以看到，資料只會儲存到對應的1個目錄中。

再不那麼隨便地建另一張表：

透過指定儲存策略(policy01)，建立另一張表之後，再用同樣的方式，查詢到當前表所使用的儲存策略，以及對應的儲存路徑。

再次寫入幾條資料後，查詢其資料在各個目錄中的儲存情況：

可以看到，資料會儲存到對應的2個目錄中。

所以，到這裡，你應該能看出 CK 這個儲存機制的缺點了，那就是：就算我的機器同時有3塊資料盤，但是，你不能透過一次性配置，來達到讓它們均勻儲存資料的目的。

最後

雖然說，CK 的資料儲存機制非常的豐富，且強大。但是呢，在我看來，它顛覆了以往我們對資料庫多目錄配置的使用習慣。

在便利性上，會多少讓人有些不適，也進一步提高了使用者的門檻，需要時間去適應。

那麼對於 CK 的這種多儲存策略配置方式，你怎麼看？