SequoiaDB擴容介紹與最佳實踐

1. 前言

隨著業務系統非結構化數據年增長量較大並且數據越來越多。在業務系統投產後，由於業務量的增加使得集群可使用存儲容量逐漸變小，因此在業務系統接入集群前需考慮存儲容量耗盡後整個集群的水平擴展。SequoiaDB是分散式架構的文檔型資料庫，因此可以通過集群的擴容實現集群性能的近線性增長。通過擴容後主要解決兩個問題是數據存儲的容量問題和整個集群的性能問題。因為數據量的不斷增長及上線後的推廣使用，所以需要進行擴容來提升集群性能及增加數據存儲空間。

2.典型應用場景

1.舊數據量大，不希望移動數據；

業務系統庫表數據量非常龐大，由於投產以來，業務量的持續增長，集群可用的存儲容量消耗殆盡，沒有多餘的其他磁碟資源來滿足移動舊數據的能力。期望能在不移動已經存在的舊數據的情況下，解決存儲容量不夠的問題，以滿足後期業務增長的需求。

2.舊數據量不大，期望獲得最好的性能，可以移動數據；

業務系統庫表數據量不大，但包含日常業務操作，尤其是大量的前台操作，對查詢的響應速度、並發量和吞吐量要求高。期望在數據量增長後，依然能夠得到極致的讀寫性能。

3.完全不停服務，對應用透明；

業務系統存在數據存儲容量或集群性能瓶頸，需要進行改善，但業務系統需要24小時對外提供服務，期望資料庫的擴容動作對上層業務完全透明。

4.能夠有停服務時間窗口，對應用透明；

和上述3場景類似，但能夠有一定的時間窗口進行停止服務進行資料庫變更，期望業務系統不需要改動，完成擴容的動作。

5.不改動資料庫，希望更新應用；

應用代碼比較容易變更，修改代碼邏輯，完成集群的擴容。

3. 優缺點對比

針對以上幾種應用場景提供的幾種不同解決方案優缺點對比：

每種解決方案在後面章節5將有具體介紹。

4. SequoiaDB支持擴容的特性

4.1 垂直分區

SequoiaDB的垂直分區也稱作主子表，是將集合數據按照指定的分區鍵範圍分別存儲到不同的子表中，類似於傳統關係型資料庫中分區表的概念，主集合中不存放任何數據記錄。

detach原子表，attach

4.2 Split方法

集合的split方法，用作數據的切分，把存儲在某些物理區塊上的一個大數據量集合，按某一個或多個欄位的值將之劃分成若干個小的部分，將這些小的部分分散存放到更多的物理區塊上。

4.3 數據遷移

SequoiaDB提供數據的導入（sdbimprt）和導出(sdbexprt)工具,能夠將JSON格式或 CSV 格式的數據導入到sdb資料庫,和將sdb資料庫集合中的數據導出到外部文件中。

5. 應用案例

5.1 測試環境

V2.8.2的集群環境：

下面通過以上的幾種特性的組合，完成幾種不同場景下的擴容方法：

5.2 第一種方式：主子表+導出導入

擴容前該主子表的每個子表（集合1-n）數據均勻存放在原數據域內數據組1-3上，如圖1所示，目標是將每個子表（集合1-n）數據均勻分布到包含原數據組和新加入數據組的數據組1-6上，如圖4所示，通過如下步驟進行擴容：

(1).將新加入的數據複製組添加到域中；

(2).在更新後的域中對主表的每個子表建立新的子表；

(3).建立管道文件；

(4).導出原子表數據到管道文件，同時導入管道文件中的數據到新子表中；

(5).導出導入完成後，校驗數據的正確性，從主表上分離原子表，掛載新子表；

(6).刪除原子表。

此方式適用於，原來的數據組數據未接近飽和，最接近飽和的數據組，能容納最大數據量集合除以擴容後數據組個數的存儲空間。由於主表名稱不受擴容影響，分離原子表，掛載新子錶速度很快，能不停機提供查詢操作，不需要改動上層業務系統正常運轉。但在遷移過程中，集合中數據不能變動。

5.3 第二種方式：主子表+split

擴容前該主子表的每個子表（集合1、2）數據均勻存放在原數據域內數據組1-3上，如圖1所示，目標是新增子表（新集合1、2），新數據均勻分布到新加入數據組的數據組上，如圖4所示。

在建立子表時，設置autoSplit屬性為false，使用Group屬性，但使用Group指定集合建立的分組時，只能指定一個數據組，不能指定多個數據組。因此還需要在子表上，手動使用split方法，將數據範圍切分到其他新增的數據組上。通過如下步驟進行擴容：

1.將新加入的數據複製組添加到域中；

2.在新加入的某個數據複製組上，建立新的子表；

3.使用split手動將新子表切分到其他新加入的數據組上；

4.掛載新的子表到主表上。

此方式適用於主子表，且主表和子表之間帶有時間特性，業務系統過來的新增數據存入到新的子表中，在按年或月信息作主子表分區鍵時，在當前階段的子表數據接近飽和時，通過新增下一階段的子表，來存放下一階段的數據。 對業務系統透明且無任何運轉的影響。但由於Group只能指定一個分區組，手動切分比較麻煩。

5.4 第三種方式：主子表+數據域

由於數據域的指定是在集合空間上，所以新的子表不能建在原集合空間上，需要新建集合空間，指定數據域為新的數據域。

1.在新加入的數據複製組上新建域；

2.在新的數據域上，建立新的集合空間；

3.在新的集合空間上，建立新的子表；

4.將新的子表attach到主表上。

和第三種方式差不多，適用場景一樣，但少了手動切分的過程，替換為新增數據域和集合空間，利用域的autoSplit特性，自動完成切分過程。缺點是增加了域和集合空間，增加了複雜性。

5.5 第四種方式：普通分區表+split

1.將新加入的數據複製組添加到域中；

2.使用split方法對域中的每個集合的數據，手動切分到新加入的數據組中。

最常規的一種方式，適用於非主子表結構的普通集合，能不停機提供查詢操作。

註：在切分的過程中，從協調節點看，集合的數據量會存在波動；對該集合數據的增刪改可能會出現問題，建議在沒有修改操作的時候進行該切分操作。

5.6 第五種方式：普通分區表+導出導入

1. 將新加入的數據複製組添加到域中；

2. 導出域中所有的集合數據，以及集合空間定義、集合定義和索引定義；

3. 刪除域中原有的集合空間；

4. 新建集合空間、集合以及索引。

5. 導入之前導出的數據到新建立的集合中。

相當於是對整個域內的結構，進行重建，適用於集合空間、集合和數據組特別多，但域內數據量不多，或數據可以全部清空的場景。特別適用於初期建表測試時，發現表結構或容量不滿足需求，需要重建的情況。

6.總結

在不同的適用場景下選擇不同的擴容方式，如果擴容前，採用了主子表的存儲方式，根據主表分區鍵的特徵，選取不同的擴容方式，如果分區鍵帶有時間特性（邏輯上某段時間入庫的數據，只會落在某些子表上），譬如業務暫時存儲近期內的數據，遠期的數據存儲在未來部署的機器上的場景，可以使用方式二和方式三，而當新增數據組特別多時，方式三工作量更小；如果分區鍵不帶有時間特性，可以使用方式一。如果擴容前沒採用主子表的存儲方式，可以使用方式四。如果在業務數據存儲規劃前期（數據量較小的情況下），建表後，發現起初規劃的存儲空間不夠用，需要增加數據組，可以使用方式五，快速重建表結構。

推薦閱讀：