1 引言
隨著用戶的增長、業(yè)務(wù)的發(fā)展，大型企業(yè)用戶的業(yè)務(wù)系統(tǒng)的數(shù)據(jù)量越來越大，超大數(shù)據(jù)表的性能問題成為阻礙業(yè)務(wù)功能實現(xiàn)的一大障礙。其中，流水表作為最常見的一類超大表，是企業(yè)級用戶經(jīng)常碰到的性能瓶頸。
本文就以流水類的超大表，探討分布式的超大表進(jìn)行的性能調(diào)優(yōu)。對于海量數(shù)據(jù)的存儲和高并發(fā)操作，分布式數(shù)據(jù)庫相較于傳統(tǒng)數(shù)據(jù)庫有著天然的優(yōu)勢，合理利用分布式數(shù)據(jù)庫多種特性，輕松解決超大表的性能問題。其中，SequoiaDB 巨杉數(shù)據(jù)庫，作為新一代 OLTP 的分布式數(shù)據(jù)庫，被廣泛使用于海量數(shù)據(jù)存儲與高并發(fā)操作場景中，我們將會以SequoiaDB來舉例說明分布式數(shù)據(jù)庫的超大表的優(yōu)化。
2 數(shù)據(jù)存儲規(guī)劃很重要
對于流水類超大表，前期的數(shù)據(jù)存儲規(guī)劃尤為重要，合理的數(shù)據(jù)存儲規(guī)劃能有效利用數(shù)據(jù)庫集群硬件資源，提供更高性能、更高效率的數(shù)據(jù)服務(wù)。
2.1 集群規(guī)模評估與硬件配置搭配
在數(shù)據(jù)庫集群規(guī)劃伊始，需要通過調(diào)研數(shù)據(jù)庫集群支撐應(yīng)用規(guī)模、系統(tǒng)定位和業(yè)務(wù)三至五年的發(fā)展規(guī)劃進(jìn)行摸底，用以評估集群規(guī)模以及各服務(wù)器的CPU、內(nèi)存、硬盤、網(wǎng)卡的合理搭配。
精準(zhǔn)的評估一個數(shù)據(jù)庫集群規(guī)模，是一個宏大且復(fù)雜的綜合工程，需要有的業(yè)務(wù)需求評估數(shù)據(jù)加以支持。通常情況下，由于業(yè)務(wù)需求變化快、業(yè)務(wù)增長普遍高于預(yù)期，小集群規(guī)劃可以按照業(yè)務(wù)調(diào)研信息的1.5~2倍進(jìn)行評估，大集群規(guī)劃可以按1~1.5倍進(jìn)行評估。
集群規(guī)模需要通過業(yè)務(wù)規(guī)模、數(shù)據(jù)存儲規(guī)模、最大流水表3年數(shù)據(jù)規(guī)模，三類信息進(jìn)行評估。業(yè)務(wù)規(guī)模評估需要從業(yè)務(wù)訪問量、數(shù)據(jù)庫各類操作比例、操作時間分布等進(jìn)行調(diào)研，最終得出各類操作的交易TPS和操作并發(fā)度數(shù)據(jù)。
數(shù)據(jù)存儲規(guī)模主要對流水類數(shù)據(jù)進(jìn)行評估，從存量數(shù)據(jù)、3年增量數(shù)據(jù)預(yù)估、數(shù)據(jù)吞吐規(guī)模等信息進(jìn)行調(diào)研，最終得出集群數(shù)據(jù)存儲大小、數(shù)據(jù)吞吐量，并結(jié)合交易TPS估算出磁盤IOPS?；A(chǔ)信息表的數(shù)據(jù)規(guī)模對集群規(guī)模評估影響小，作為一個參考信息只需要出整體規(guī)模上評估即可，例如，集群需存儲1000張基礎(chǔ)表，平均每張0.1GB，整體需要100GB，這個量級在上百TB的集群規(guī)模里可以忽略不計。
具體操作上，可以先敲定集群存儲大小，在根據(jù)IOPS和數(shù)據(jù)吞吐情況平衡使用磁盤還是固態(tài)硬盤，每個硬盤的大小，一臺服務(wù)器掛載幾個硬盤等等，根據(jù)TPS、操作類型比例和并發(fā)度來配置CPU和內(nèi)存。一般情況下，建議CPU內(nèi)存比為1:8，單個硬盤在1.5~3T的容量為主，單個盤容量約大越容易出現(xiàn)IO性能瓶頸，網(wǎng)絡(luò)帶寬根據(jù)集群大小和集群吞吐量可選擇使用千兆網(wǎng)或萬兆網(wǎng)絡(luò)。
2.2 流水表怎么建會更好
流水類數(shù)據(jù)通常包含兩個維度特征：業(yè)務(wù)時間維度和業(yè)務(wù)主鍵維度。對于流水表最普遍的就是創(chuàng)建多維分區(qū)表（如圖1），先在主表集合通過把不同業(yè)務(wù)日期的數(shù)據(jù)切分到不同的子表集合中，以此確保單個集合數(shù)據(jù)量不至于過大；然后，在子表集合通過業(yè)務(wù)主鍵將數(shù)據(jù)打散到集群的各個數(shù)據(jù)節(jié)點中，單集合在單節(jié)點上的數(shù)據(jù)量最好在百萬數(shù)據(jù)量級以內(nèi)。另外，通過業(yè)務(wù)日期進(jìn)行多維度分區(qū)，可以非常簡單的實現(xiàn)集群橫向擴(kuò)容。
需要注意的是，在設(shè)計流水表集合空間時，最好按年或按月創(chuàng)建集合空間，這樣當(dāng)數(shù)據(jù)超過數(shù)據(jù)保存周期時可以快速備份、刪除并釋放存儲空間。
圖1：多維度分區(qū)
2.3 再合理的規(guī)劃也無法一勞永逸
再合理的數(shù)據(jù)存儲規(guī)劃，在急劇增長的數(shù)據(jù)和千變?nèi)f化的業(yè)務(wù)需求面前，都顯得那么無能為力，數(shù)據(jù)的增長總會超出預(yù)期，性能瓶頸總有發(fā)生的那天。這個時候，就需要針對具體性能問題進(jìn)行性能優(yōu)化。
3 硬件資源性能瓶頸分析
集群硬件資源的使用情況，是分析性能瓶頸的一個重要依據(jù)，通過硬件資源使用情況的變化，可以直觀確定發(fā)生變化時集群應(yīng)該發(fā)生了業(yè)務(wù)變更或者操作變更，從變化中梳理出一條分析思路。
3.1 集群硬件資源監(jiān)控數(shù)據(jù)是基礎(chǔ)
集群服務(wù)器各硬件資源的日常性能監(jiān)控很重要，通過日常的監(jiān)控數(shù)據(jù)，可以了解集群性能的波動情況。
nmon監(jiān)控軟件是是一款很出名的開源的系統(tǒng)性能監(jiān)控工具，用于監(jiān)控AIX\linux系統(tǒng)的資源消耗信息，并能把結(jié)果輸出到文件中，然后通過nmon_analyser工具產(chǎn)生數(shù)據(jù)文件與圖形化結(jié)果。如圖2是nmon的運(yùn)行主界面，互聯(lián)網(wǎng)上有許多關(guān)于nmon工具的安裝、實時監(jiān)控、數(shù)據(jù)采集、分析報表生成等一整套教程，感興趣的小伙伴可以了解一下。
圖2：nmon運(yùn)行主界面
3.2 集群硬件資源使用情況多維度分析
硬件資源使用情況分析，分為實時監(jiān)控分析和監(jiān)控報表數(shù)據(jù)分析，兩者需要需要結(jié)合使用。
對于常態(tài)化的性能問題，先使用實時監(jiān)控獲取具體進(jìn)程使用的各硬件資源的情況，再結(jié)合報表分析將監(jiān)控的時間長度拉長，找到出現(xiàn)性能變化的起點，看這種性能變化是否是周期性的、隨機(jī)性的或是漸變的，結(jié)合此時點前后的生產(chǎn)變更情況以及相關(guān)數(shù)據(jù)操作動作來定位問題。
對于已發(fā)生暫時沒有重現(xiàn)的性能問題，先通過監(jiān)控報表分析手段，分析性能問題發(fā)生時點前后的硬件資源變化，再將監(jiān)控的時間長度拉長，嘗試找出資源變化的規(guī)律，然后通過應(yīng)用日志、數(shù)據(jù)庫日志和生產(chǎn)變更情況，找出引發(fā)性能問題的操作。最后，嘗試重新執(zhí)行相關(guān)操作，并進(jìn)行實時性能監(jiān)控，驗證相關(guān)問題猜想。
從硬件資源監(jiān)控中找出性能變化的內(nèi)在邏輯是問題分析的關(guān)鍵所在，掌握硬件資源的變化規(guī)律就初步掌握了集群的性能情況，也是進(jìn)行性能調(diào)優(yōu)的第一步。
4 數(shù)據(jù)庫集群業(yè)務(wù)情況與操作分析
掌握了解硬件資源性能情況是性能優(yōu)化的第一步，還需要結(jié)合集群業(yè)務(wù)情況與各類操作比例與時間分布，才能進(jìn)一步精確的定位性能問題。
4.1 業(yè)務(wù)情況摸底
業(yè)務(wù)情況摸底一般通過業(yè)務(wù)訪問監(jiān)控接口持續(xù)獲取業(yè)務(wù)訪問情況，并結(jié)合業(yè)務(wù)邏輯分析需要執(zhí)行的數(shù)據(jù)庫操作，獲得業(yè)務(wù)TPS、并發(fā)度、數(shù)據(jù)操作類型分布、數(shù)據(jù)吞吐量等信息，以此評估數(shù)據(jù)庫集群壓力。
4.2 數(shù)據(jù)分布情況分析
數(shù)據(jù)分布不均導(dǎo)致的性能問題是一個非常常見問題，流水類超大表出現(xiàn)數(shù)據(jù)分布不均主要是由于業(yè)務(wù)主鍵字段隨機(jī)性弱，無法很好的進(jìn)行哈希打散，可使用其他隨機(jī)性較強(qiáng)的字段代替，或者結(jié)合數(shù)據(jù)特點使用范圍分區(qū)也是一個可以嘗試的方法。
如何確定數(shù)據(jù)是否均勻分布？首先，通過查看主表集合的編目信息，檢查業(yè)務(wù)日期切分是否均衡；然后，查看每個子表集合的編目信息，檢查數(shù)據(jù)是否根據(jù)業(yè)務(wù)主鍵打散到所在數(shù)據(jù)域的各個節(jié)點；最后，抽查2~3張子表集合，檢查子表集合在每個節(jié)點的數(shù)據(jù)量是否相當(dāng)均衡。
4.3 訪問計劃分析
通過query.explain({ Detail : true, Run : true })可獲取查詢的詳細(xì)訪問計劃。通過分析數(shù)據(jù)操作語句的訪問計劃，可以掌握該數(shù)據(jù)操作的涉及到哪些子表集合，每個子表集合的每個節(jié)點的訪問計劃情況，包括訪問計劃的掃描方式、索引使用情況，數(shù)據(jù)情況，資源使用情況等信息。
4.4 查詢監(jiān)控與全表掃描檢測
通過抓取數(shù)據(jù)庫集群會話快照db.snapshot(SDB_SNAP_SESSIONS)，可以捕獲每個查詢的數(shù)據(jù)操作詳細(xì)信息，包括會話狀態(tài)、線程信息、索引數(shù)據(jù)信息、數(shù)據(jù)操作記錄數(shù)、操作耗時、資源使用情況等等信息。
可通過不斷抓取會話快照信息，監(jiān)控會話快照信息中的"LastOpInfo"字段是否包含"tbscan"字樣，來檢測數(shù)據(jù)操作中是否存在全表掃描的情況。
5 性能優(yōu)化指引
流水類超大表的性能優(yōu)化，一般遵循從操作到軟件再到硬件，由簡到繁的一個優(yōu)化思路，優(yōu)化前需要充分了解軟硬件情況，例如數(shù)據(jù)操作情況、數(shù)據(jù)庫配置、系統(tǒng)性能情況等等。
5.1 適量創(chuàng)建高效索引
索引是一種提高數(shù)據(jù)訪問效率的特殊對象。恰當(dāng)?shù)氖褂盟饕商岣邤?shù)據(jù)檢索效率，但索引使用不當(dāng)反而會降低數(shù)據(jù)檢索速度，嚴(yán)重的還會造成數(shù)據(jù)庫整體服務(wù)性能下降。
利用索引對流水類超大表進(jìn)行性能調(diào)優(yōu)，是最為經(jīng)濟(jì)、簡單、高效的一種方式。那么，如何恰到好處的創(chuàng)建索引，即能提高數(shù)據(jù)操作效率，又不會對數(shù)據(jù)庫服務(wù)性能造成影響？
首先，需要了解索引的可供調(diào)優(yōu)參考的部分特性，以及相關(guān)性能開銷成本。
部分相關(guān)特性：
· 使用二分查找，可快速定位數(shù)據(jù)，平均復(fù)雜度是O(logN)。
· 索引數(shù)據(jù)信息大小遠(yuǎn)小于表數(shù)據(jù)大小，索引數(shù)據(jù)可長時間緩存在內(nèi)存。
使用B樹結(jié)構(gòu)，三層的B樹可以表示上百萬的數(shù)據(jù)，通過索引檢索數(shù)據(jù)可減少磁盤I/O次數(shù)，數(shù)據(jù)字段越小索引效率越好。
I/O的次數(shù)取決于B樹的高度H，假設(shè)當(dāng)前數(shù)據(jù)表的數(shù)據(jù)為N，每個磁盤塊的數(shù)據(jù)項的數(shù)量是M，則有：H=log(M+1)N，當(dāng)數(shù)據(jù)量N一定的情況下，M越大，H越??；而M=磁盤塊大小/數(shù)據(jù)項大小，磁盤塊大小也就是一個數(shù)據(jù)頁的大小，是固定的，如果數(shù)據(jù)項占的空間越小，數(shù)據(jù)項的數(shù)量越多，樹的高度也就越低。這也就是為什么每個數(shù)據(jù)項，即索引字段要盡量的小，比如int占4個字節(jié)，要比bigint的8個字節(jié)小一半。這也是為什么B樹要求把真實數(shù)據(jù)放在葉子節(jié)點內(nèi)而不是內(nèi)層節(jié)點內(nèi)，一旦放到內(nèi)層節(jié)點內(nèi)，磁盤塊的數(shù)據(jù)項會大幅度的下降，導(dǎo)致樹層級的增高。當(dāng)數(shù)據(jù)項為1時，B樹會退化成線性表。
· 圖3：B樹數(shù)據(jù)結(jié)構(gòu)面
· 索引具有最左匹配特性，創(chuàng)建復(fù)合索引要根據(jù)數(shù)據(jù)重復(fù)率和查詢使用的字段情況進(jìn)行創(chuàng)建。
B樹的數(shù)據(jù)項是復(fù)合性數(shù)據(jù)結(jié)構(gòu)，按照從左到右的順序來建立搜索樹的，例如：當(dāng)（小張，22，女）這樣的數(shù)據(jù)來檢索的時候，B樹會優(yōu)先比較name來確定下一步的搜索方向，如果name相同再依次比較age和gender，最后得到檢索的數(shù)據(jù)。但是，當(dāng)（22，女）這樣沒有name的數(shù)據(jù)來的時候，B樹就不知道下一步該查哪個節(jié)點，因為建立搜索樹的時候，name就是第一個比較因子，必須根據(jù)name來搜索才知道下一步去哪里查詢。比如，當(dāng)（小張，男）這樣的數(shù)據(jù)來檢索時，B樹就可以根據(jù)name來指定搜索方向，但下一字段age缺失，所以只能把名字是"小張"的所有數(shù)據(jù)都找到，然后再匹配性別是"男"的數(shù)據(jù)了。
· 索引數(shù)據(jù)是有序的，支持順、逆排序，合理利用可優(yōu)化查詢排序和分組效率。
· 數(shù)據(jù)重復(fù)率越低索引使用效率越高。
相關(guān)性能開銷：
· 對數(shù)據(jù)操作都需要額外對索引進(jìn)行維護(hù)，索引越多維護(hù)性能開銷越大。
· 創(chuàng)建索引需要排序，需要額外存儲空間，會獲取表鎖，創(chuàng)建時會消耗大量內(nèi)存、CPU。
· 一次數(shù)據(jù)查詢操作，至少產(chǎn)生2次IO操作，一次查詢索引數(shù)據(jù)，一次訪問表數(shù)據(jù)。
· 一次數(shù)據(jù)插入操作，至少產(chǎn)生1+n（n為索引個數(shù)）次IO操作，當(dāng)索引當(dāng)葉結(jié)點過滿時會觸發(fā)結(jié)點遞歸分裂時，IO操作會劇增。
· 一次數(shù)據(jù)刪除操作，至少產(chǎn)生3+n（n為索引個數(shù)）次IO操作，當(dāng)索引當(dāng)葉結(jié)點過空時會觸發(fā)結(jié)點遞歸合并時，IO操作會劇增。
· 一次數(shù)據(jù)更新操作，如果更新字段不是索引字段，則產(chǎn)生3次IO操作，如果更新字段為索引字段，則產(chǎn)生3+n（n為索引個數(shù)）次IO操作，且索引結(jié)點的分裂與合并均有可能發(fā)生（變長數(shù)據(jù)類型字段）。
掌握了索引相關(guān)特性和性能開銷，結(jié)合流水類超大表的特點，通過評估確定數(shù)據(jù)插入、更新和查詢操作的比例，調(diào)研更新字段與查詢字段是否有重合等信息，以此來確定是否需要創(chuàng)建索引，創(chuàng)建哪些索引。
一般來說，流水類超大表都需要創(chuàng)建流水主鍵索引，以確保流水?dāng)?shù)據(jù)唯一性。其他的索引創(chuàng)建需要可根據(jù)更新、查詢條件、數(shù)據(jù)規(guī)模等信息進(jìn)行評估，通常創(chuàng)建2~3個索引效率性能比較為理想。如果數(shù)據(jù)查詢操作為主，可酌情增加索引數(shù)量。對于多個字段組成的查詢條件，可根據(jù)條件字段的重復(fù)率情況創(chuàng)建復(fù)合索引；對于有數(shù)據(jù)排序、數(shù)據(jù)分組的字段，可按排序分組字段創(chuàng)建復(fù)合索引。
5.2 優(yōu)化查詢語句
對于流水類超大表的查詢優(yōu)化，有兩個基本原則：一是通過索引調(diào)優(yōu)，強(qiáng)制數(shù)據(jù)查詢走指定索引，二是通過限制查詢的業(yè)務(wù)日期范圍，減少查詢檢索的數(shù)據(jù)規(guī)模。
索引調(diào)優(yōu)可以結(jié)合本文 "適量創(chuàng)建高效索引"章節(jié)所述合理創(chuàng)建索引，并通過查看執(zhí)行計劃確保查詢走索引。
合理的利用巨杉數(shù)據(jù)庫主子表的特點，在查詢時確定查詢數(shù)據(jù)的業(yè)務(wù)日期維度，可以極大的減少檢索數(shù)據(jù)規(guī)模，減少節(jié)省數(shù)據(jù)庫集群資源，舉個例子：應(yīng)用需要通過流水號（主鍵）查詢該流水號對應(yīng)的流水?dāng)?shù)據(jù)，該流水號記有業(yè)務(wù)日期信息。通常情況下，簡單的使用流水號就可以準(zhǔn)確快速的查詢到該條流水，但對于一個流水類超大表來說，可能存放著十年幾十年的流水?dāng)?shù)據(jù)，數(shù)據(jù)可能存儲在上百張子表中，如果單單使用流水號查詢，那么數(shù)據(jù)庫就需要對每個子表進(jìn)行一次索引檢索，最后只會有一張表檢索到數(shù)據(jù)，但如果把流水號中的業(yè)務(wù)日期截取出來作為一個查詢條件，那么數(shù)據(jù)庫就可以通過主表的業(yè)務(wù)日期分區(qū)信息定位到該流水?dāng)?shù)據(jù)所在的子表，數(shù)據(jù)庫僅會對該子表進(jìn)行索引檢索。
另外，對于對大范圍業(yè)務(wù)日期查詢，且需要分頁處理的，可每次查詢一個業(yè)務(wù)日期分區(qū)，分多次完成查詢。對于查詢數(shù)據(jù)結(jié)果集很大的查詢，通常使用分頁查詢，單頁數(shù)據(jù)量在數(shù)百以內(nèi)為佳。
總的來說，查詢語句的調(diào)優(yōu)沒有一套固定標(biāo)準(zhǔn)的操作方法，它是一個循序漸進(jìn)的過程，只有通過不斷的測試、優(yōu)化、再測試、再優(yōu)化，在不斷迭代中逐步提高查詢效率。
5.3 調(diào)整數(shù)據(jù)切分粒度
流水類超大表什么時候需要調(diào)整數(shù)據(jù)切分粒度，可能是本節(jié)內(nèi)容的最大挑戰(zhàn)，需要綜合考慮集群硬件資源使用情況、查詢優(yōu)化情況，子表單節(jié)點數(shù)據(jù)大小、索引大小等等一系列問題。
從硬件資源使用角度考慮，硬盤使用率在70%以下，超過70%可以考慮直接進(jìn)行集群擴(kuò)容，在集群CPU、內(nèi)存基本保持在60%以下，只有IOPS居高不下，且IO讀緊張IO寫正常，查詢業(yè)務(wù)TPS遠(yuǎn)低于IOPS，此現(xiàn)象說明1次查詢會產(chǎn)生非常多的IO讀；從查詢優(yōu)化情況看，已無全表掃描的查詢，查詢語句已做了足夠的優(yōu)化，但查詢依然無法滿足需求；以單子表單個節(jié)點的數(shù)據(jù)規(guī)模進(jìn)行評估，數(shù)據(jù)規(guī)模需要控制在百萬級別，單條數(shù)據(jù)記錄的字段數(shù)與數(shù)據(jù)長度對數(shù)據(jù)檢索也有影響，特別是數(shù)據(jù)更新操作，數(shù)據(jù)字段越多、數(shù)據(jù)長度越長更新效率越低；評估查詢語句中的業(yè)務(wù)日期范圍，查詢越精確，切分粒度的調(diào)整彈性就越大；另外，根據(jù)創(chuàng)建的索引的字段類型以及實際索引大小，評估索引是否可以完全緩存至內(nèi)存，盡可能將數(shù)據(jù)切分粒度調(diào)整至索引數(shù)據(jù)可完全緩存至內(nèi)存。
實際上，調(diào)整流水類超大表的數(shù)據(jù)切分粒度，就是提高數(shù)據(jù)并發(fā)度，減少單子表在單節(jié)點的索引數(shù)據(jù)規(guī)模，使得整個索引數(shù)據(jù)可以常駐內(nèi)存，最大程度減少IO開銷，故而，調(diào)整數(shù)據(jù)切分粒度會增加內(nèi)存、CPU資源的消耗。
如何調(diào)整數(shù)據(jù)切分粒度是需要探討的另一個問題，對于按本文介紹的主子表建表規(guī)則創(chuàng)建流水類超大表，很簡單的就可以完成調(diào)整動作，只需要將主表的每個業(yè)務(wù)日期區(qū)間，拆分成多個切分區(qū)間，即一個子表數(shù)據(jù)拆分成多個子表。關(guān)鍵的問題是，拆成多少個子表合理，一般建議一個子表拆分成2~3個子表較為合理，不過，最可靠的方式是——模擬生產(chǎn)測試。
5.4 升級短板硬件
服務(wù)器停機(jī)升級短板硬件，對于天然具備容災(zāi)高可用特性的巨杉數(shù)據(jù)庫來說，是一件不能再簡單的事情，只需將需要升級的服務(wù)器的數(shù)據(jù)庫主節(jié)點切換到其他服務(wù)器，就可以停掉數(shù)據(jù)庫服務(wù)然后進(jìn)行停機(jī)升級；如果是替換硬盤，在重啟完成新硬盤掛載并創(chuàng)建相應(yīng)數(shù)據(jù)目錄后，重啟數(shù)據(jù)庫服務(wù)后，數(shù)據(jù)庫會自動同步數(shù)據(jù)。
通過硬件資源的性能瓶頸分析，可以很清晰的看出硬件資源瓶頸，可根據(jù)業(yè)務(wù)需要酌情升級短板硬件，如添加內(nèi)存條，將磁盤替換成固態(tài)硬盤，甚至可直接將整臺服務(wù)器置換掉。
5.5 集群擴(kuò)容
當(dāng)數(shù)據(jù)庫集群存儲空間不足，或者上述優(yōu)化手段都不能很好的解決性能瓶頸問題時，可以著手進(jìn)行集群擴(kuò)容。
在集群擴(kuò)容時，需要根據(jù)現(xiàn)有集群情況加以調(diào)整優(yōu)化，例如，原有數(shù)據(jù)域有3臺服務(wù)器，由于增量數(shù)據(jù)劇增，后續(xù)規(guī)劃的數(shù)據(jù)域就需要6臺或者更多服務(wù)器。又例如，新服務(wù)器參照舊服務(wù)器的硬件資源使用情況，需要調(diào)整硬件配置，降低空閑的配置要求，提升短板硬件資源的配置等等。由于有了一個現(xiàn)成的參考對象，集群擴(kuò)容的規(guī)模評估和硬件配置評估就可以簡單很多。
對于流水類超大表的集群擴(kuò)容操作是非常簡單的，只需在安裝好巨杉數(shù)據(jù)庫軟件的服務(wù)器按規(guī)范新增數(shù)據(jù)節(jié)點，將新增節(jié)點添加進(jìn)原有集群并作為一個新的數(shù)據(jù)域，然后將后續(xù)業(yè)務(wù)日期的子表集合創(chuàng)建在新的數(shù)據(jù)域，再將子表集合按規(guī)范掛載到主表集合上，到此為止已經(jīng)完成了集群擴(kuò)容的所有步驟。如下圖所示，當(dāng)數(shù)據(jù)域1各類硬件資源不夠使用，可新增一個數(shù)據(jù)域2存儲2030年以后的流水?dāng)?shù)據(jù)。
圖4：集群擴(kuò)容，新增數(shù)據(jù)域2
6 總結(jié)
流水類超大表的性能優(yōu)化，是一個持續(xù)迭代的過程，需要建立在對數(shù)據(jù)庫集群的業(yè)務(wù)層、數(shù)據(jù)層、硬件資源層有充分的了解的基礎(chǔ)上，依次對硬件資源分析、集群操作分析與檢測、業(yè)務(wù)分析，完成對性能問題的定位。
同時，對于分布式數(shù)據(jù)庫的用戶，在處理超大表優(yōu)化問題時，可以合理利用 SequoiaDB 巨杉數(shù)據(jù)庫多維分區(qū)特性和簡易的橫向擴(kuò)展機(jī)制，輕松解決超大表的性能問題，面對超大表的性能優(yōu)化再也不用愁。
