建站
咨詢
售后
建站咨詢
新聞中心
隨著現(xiàn)代互聯(lián)網(wǎng)的發(fā)展，數(shù)據(jù)量已經(jīng)越來越大，并且存儲和處理數(shù)據(jù)的速度成為了業(yè)務發(fā)展的瓶頸。在這種情況下，采用數(shù)據(jù)庫水平切分的技術來提高數(shù)據(jù)存儲和處理效率成為了必然選擇。
創(chuàng)新互聯(lián)建站網(wǎng)站建設公司，提供成都做網(wǎng)站、網(wǎng)站制作，網(wǎng)頁設計，建網(wǎng)站，PHP網(wǎng)站建設等專業(yè)做網(wǎng)站服務;可快速的進行網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴展；專業(yè)做搜索引擎喜愛的網(wǎng)站，是專業(yè)的做網(wǎng)站團隊，希望更多企業(yè)前來合作!
一、什么是數(shù)據(jù)庫水平切分
數(shù)據(jù)庫水平切分是指將一個邏輯數(shù)據(jù)庫按照某種規(guī)則分成多個物理數(shù)據(jù)庫實例，每個實例存儲部分數(shù)據(jù)，并且每個實例都可以獨立地進行操作和擴展。這種方式可以提高數(shù)據(jù)庫的吞吐量，同時也能夠避免單點故障的問題。
二、為什么采用數(shù)據(jù)庫水平切分
1. 數(shù)據(jù)量過大
在數(shù)據(jù)量過大的情況下，單個數(shù)據(jù)庫實例可能無法承載全部數(shù)據(jù)，導致性能下降。采用水平切分的方式，可以將數(shù)據(jù)分成多個實例，從而提高性能。
2. 數(shù)據(jù)處理效率低下
當并發(fā)請求量過大時，單個數(shù)據(jù)庫實例可能無法承載全部請求，導致處理效率低下。采用水平切分的方式，可以將請求分散到多個實例上，從而提高處理效率。
3. 避免單點故障
當單個數(shù)據(jù)庫實例出現(xiàn)故障時，整個系統(tǒng)將無法正常工作。采用水平切分的方式，可以將單個實例故障所帶來的影響降到更低。
三、水平切分的實現(xiàn)方式
1. 基于分區(qū)的切分
采用分區(qū)方式進行水平切分，可以將數(shù)據(jù)按照某個規(guī)則進行分區(qū)，每個區(qū)域分配到一個數(shù)據(jù)庫實例中。這種方式最適合按照時間、地域等規(guī)則進行分區(qū)的數(shù)據(jù)。
2. 基于哈希的切分
采用哈希方式進行水平切分，可以將數(shù)據(jù)按照某個規(guī)則進行哈希處理，每個哈希值分配到一個數(shù)據(jù)庫實例中。這種方式最適合無固定規(guī)律的數(shù)據(jù)，但是需要考慮到哈希的均衡問題。
3. 基于數(shù)據(jù)表的切分
采用數(shù)據(jù)表方式進行水平切分，可以將每個數(shù)據(jù)表分配到不同的數(shù)據(jù)庫實例上。這種方式最適合數(shù)據(jù)表之間有很少交互的場景，但是需要考慮到數(shù)據(jù)表之間關聯(lián)的問題。
四、使用水平切分的注意事項
1. 數(shù)據(jù)庫設計
在進行水平切分之前，需要對數(shù)據(jù)庫進行充分的設計，包括數(shù)據(jù)表結構、字段類型、索引等。同時，需要考慮到數(shù)據(jù)的訪問規(guī)則，選擇合適的切分方式。
2. 數(shù)據(jù)遷移
在進行水平切分之前，需要充分考慮數(shù)據(jù)遷移的問題，避免數(shù)據(jù)丟失或者數(shù)據(jù)一致性問題。同時，需要采用合適的數(shù)據(jù)遷移工具和方式，確保數(shù)據(jù)穩(wěn)定可靠。
3. 負載均衡
在進行水平切分之后，需要采用負載均衡的方式，確保請求能夠均衡分布到不同的數(shù)據(jù)庫實例上。一般可以采用負載均衡軟件或者硬件來實現(xiàn)。
四、水平切分的優(yōu)缺點
1. 優(yōu)點
（1）提高數(shù)據(jù)庫的吞吐量，提高數(shù)據(jù)處理效率；
（2）避免單點故障的問題，提高系統(tǒng)的穩(wěn)定性；
（3）能夠靈活擴展系統(tǒng)，在業(yè)務發(fā)展中具有較強的可擴展性。
2. 缺點
（1）系統(tǒng)復雜度增加，維護和管理難度加大；
（2）數(shù)據(jù)分散到不同的數(shù)據(jù)庫實例中，數(shù)據(jù)一致性和數(shù)據(jù)完整性的維護難度加大；
（3）需要增加負載均衡的控制，增加系統(tǒng)的復雜程度。
五、水平切分的應用場景
1. 電商平臺
在電商平臺中，商品信息、訂單信息、用戶信息等數(shù)據(jù)量很大，需要進行水平切分。
2. 游戲平臺
在游戲平臺中，玩家信息、游戲記錄、虛擬物品等數(shù)據(jù)量很大，需要進行水平切分。
3. 社交平臺
在社交平臺中，用戶信息、關系信息、消息記錄等數(shù)據(jù)量很大，需要進行水平切分。
綜上所述，數(shù)據(jù)庫水平切分是提高數(shù)據(jù)存儲和處理效率的一種有效手段。但是，在進行水平切分之前需要充分考慮數(shù)據(jù)庫設計、數(shù)據(jù)遷移、負載均衡等問題，同時需要靈活選擇合適的切分方式和應用場景。
相關問題拓展閱讀：
- 淘寶為什么使用HBase及如何優(yōu)化的
淘寶為什么使用HBase及如何優(yōu)化的
1 前言
hbase是從hadoop中 分離出來的apache頂級開源項目。由于它很好地用java實現(xiàn)了google的bigtable系統(tǒng)大部分特性，因此在數(shù)據(jù)量猛增的今天非常受到歡 迎。對于淘寶而言，隨著市場規(guī)模的擴大，產(chǎn)品與技術的發(fā)展，業(yè)務數(shù)據(jù)量越來越大，對海量數(shù)據(jù)的高效插入和讀取變得越來越重要。由于淘寶擁有也許是國內更大 的單一hadoop集群(云梯)，因此對hadoop系列的產(chǎn)品有比較深入的了解，也就自然希望使用hbase來做這樣一種海量數(shù)據(jù)讀寫服務。本篇文章將 對淘寶最近一年來在online應用上使用和優(yōu)化hbase的情況做一次小結。
2 原因
為什么要使用hbase？
淘寶在2023年之前所有的后端持久化存儲基本上都是在mysql上進行的(不排除少量oracle/bdb/tair/mongdb等)，mysql由于開源，并且生態(tài)系統(tǒng)良好，本身擁有分庫分表等多種解決方案，因此很長一段時間內都滿足淘寶大量業(yè)務的需求。
但是由于業(yè)務的多樣化發(fā)展，有越來越多的業(yè)務系統(tǒng)的需求開始發(fā)生了變化。一般來說有以下幾類變化：
a) 數(shù)據(jù)量變得越來越多，事實上現(xiàn)在淘寶幾乎任何一個與用戶相關的在線業(yè)務的數(shù)據(jù)量都在億級別，每日系統(tǒng)調用次數(shù)從億到百億都有，且歷史數(shù)據(jù)不能輕易刪除。這需要有一個海量分布式文件系統(tǒng)，能對TB級甚至PB級別的數(shù)據(jù)提供在線服務
b) 數(shù)據(jù)量的增長很快且不一定能準確預計，大多數(shù)應用系統(tǒng)從上線起在一段時間內數(shù)據(jù)量都呈很快的上升趨勢，因此從成本的角度考慮對系統(tǒng)水平擴展能力有比較強烈的需求，且不希望存在單點制約老坦
c) 只需要簡單的kv讀取，沒有復雜的join等需求。但對系統(tǒng)的并叢含正發(fā)能力以及吞吐量、響應延時有滲悔非常高的需求，并且希望系統(tǒng)能夠保持強一致性
d) 通常系統(tǒng)的寫入非常頻繁，尤其是大量系統(tǒng)依賴于實時的日志分析
e) 希望能夠快速讀取批量數(shù)據(jù)
f ) schema靈活多變，可能經(jīng)常更新列屬性或新增列
g) 希望能夠方便使用，有良好且語義清晰的java接口
以上需求綜合在一起，我們認為hbase是一種比較適合的選擇。首先它的數(shù)據(jù)由hdfs天然地做了數(shù)據(jù)冗余，云梯三年的穩(wěn)定運行，數(shù)據(jù)100%可靠 己經(jīng)證明了hdfs集群的安全性，以及服務于海量數(shù)據(jù)的能力。其次hbase本身的數(shù)據(jù)讀寫服務沒有單點的限制，服務能力可以隨服務器的增長而線性增長， 達到幾十上百臺的規(guī)模。L-Tree模式的設計讓hbase的寫入性能非常良好，單次寫入通常在1-3ms內即可響應完成，且性能不隨數(shù)據(jù)量的增長而 下降。
region（相當于數(shù)據(jù)庫的分表）可以ms級動態(tài)的切分和移動，保證了負載均衡性。由于hbase上的數(shù)據(jù)模型是按rowkey排序存儲的，而讀 取時會一次讀取連續(xù)的整塊數(shù)據(jù)做為cache，因此良好的rowkey設計可以讓批量讀取變得十分容易，甚至只需要1次io就能獲取幾十上百條用戶想要的 數(shù)據(jù)。最后，淘寶大部分工程師是java背景的同學，因此hbase的api對于他們來說非常容易上手，培訓成本相對較低。
當然也必須指出，在大數(shù)據(jù)量的背景下銀彈是不存在的，hbase本身也有不適合的場景。比如，索引只支持主索引（或看成主組合索引），又比如服務是 單點的，單臺機器宕機后在master恢復它期間它所負責的部分數(shù)據(jù)將無法服務等。這就要求在選型上需要對自己的應用系統(tǒng)有足夠了解。
3 應用情況
我們從2023年3月開始研究hbase如何用于在線服務。盡管之前在一淘搜索中己經(jīng)有了幾十節(jié)點的離線服務。這是因為hbase早期版本的目標就 是一個海量數(shù)據(jù)中的離線服務。2023年9月發(fā)布的0.20.0版本是一個里程碑，online應用正式成為了hbase的目標，為此hbase引入了 zookeeper來做為backupmaster以及regionserver的管理。2023年1月0.90.0版本是另一個里程碑，基本上我們今天 看到的各大網(wǎng)站，如facebook/ebay/yahoo內所使用于生產(chǎn)的hbase都是基于這一個版本(fb所采用的0.89版本結構與0.90.x 相近)。bloomfilter等諸多屬性加入了進來，性能也有極大提升?；诖?，淘寶也選用了0.90.x分支作為線上版本的基礎。
之一個上線的應用是數(shù)據(jù)魔方中的prom。prom原先是基于redis構建的，因為數(shù)據(jù)量持續(xù)增大以及需求的變化，因此我們用hbase重構了它 的存儲層。準確的說prom更適合0.92版本的hbase，因為它不僅需要高速的在線讀寫，更需要count/group by等復雜應用。但由于當時0.92版本尚未成熟，因此我們自己單獨實現(xiàn)了coprocessor。prom的數(shù)據(jù)導入是來源于云梯，因此我們每天晚上花 半個小時將數(shù)據(jù)從云梯上寫入hbase所在的hdfs，然后在web層做了一個client轉發(fā)。經(jīng)過一個月的數(shù)據(jù)比對，確認了速度比之redis并未有 明顯下降，以及數(shù)據(jù)的準確性，因此得以順利上線。
第二個上線的應用是TimeTunnel，TimeTunnel是一個高效的、可靠的、可擴展的實時數(shù)據(jù)傳輸平臺，廣泛應用于實時日志收集、數(shù)據(jù)實 時監(jiān)控、廣告效果實時反饋、數(shù)據(jù)庫實時同步等領域。它與prom相比的特點是增加了在線寫。動態(tài)的數(shù)據(jù)增加使hbase上compact/balance /split/recovery等諸多特性受到了極大的挑戰(zhàn)。TT的寫入量大約一天20TB，讀的量約為此的1.5倍，我們?yōu)榇藴蕚淞?0臺 regionserver的集群，當然底層的hdfs是公用的，數(shù)量更為龐大（下文會提到）。每天TT會為不同的業(yè)務在hbase上建不同的表，然后往該 表上寫入數(shù)據(jù)，即使我們將region的大小上限設為1GB，更大的幾個業(yè)務也會達到數(shù)千個region這樣的規(guī)模，可以說每一分鐘都會有數(shù)次 split。在TT的上線過程中，我們修復了hbase很多關于split方面的bug，有好幾個commit到了hbase社區(qū)，同時也將社區(qū)一些最新 的patch打在了我們的版本上。split相關的bug應該說是hbase中會導致數(shù)據(jù)丟失更大的風險之一，這一點對于每個想使用hbase的開發(fā)者來 說必須牢記。hbase由于采用了L-Tree模型，從架構原理上來說數(shù)據(jù)幾乎沒有丟失的可能，但是在實際使用中不小心謹慎就有丟失風險。原因后面會 單獨強調。TT在預發(fā)過程中我們分別因為Meta表損壞以及split方面的bug曾經(jīng)丟失過數(shù)據(jù)，因此也單獨寫了meta表恢復工具，確保今后不發(fā)生類 似問題(hbase-0.90.5以后的版本都增加了類似工具)。另外，由于我們存放TT的機房并不穩(wěn)定，發(fā)生過很多次宕機事故，甚至發(fā)生過假死現(xiàn)象。因 此我們也著手修改了一些patch，以提高宕機恢復時間，以及增強了監(jiān)控的強度。
CTU以及會員中心項目是兩個對在線要求比較高的項目，在這兩個項目中我們特別對hbase的慢響應問題進行了研究。hbase的慢響應現(xiàn)在一般歸 納為四類原因：網(wǎng)絡原因、gc問題、命中率以及client的反序列化問題。我們現(xiàn)在對它們做了一些解決方案(后面會有介紹)，以更好地對慢響應有控制 力。
和Facebook類似，我們也使用了hbase做為實時計算類項目的存儲層。目前對內部己經(jīng)上線了部分實時項目，比如實時頁面點擊系 統(tǒng)，galaxy實時交易推薦以及直播間等內部項目，用戶則是散布到公司內各部門的運營小二們。與facebook的puma不同的是淘寶使用了多種方式 做實時計算層，比如galaxy是使用類似affa的actor模式處理交易數(shù)據(jù)，同時關聯(lián)商品表等維度表計算排行(TopN)，而實時頁面點擊系統(tǒng)則是 基于twitter開源的storm進行開發(fā)，后臺通過TT獲取實時的日志數(shù)據(jù)，計算流將中間結果以及動態(tài)維表持久化到hbase上，比如我們將 rowkey設計為url+userid，并讀出實時的數(shù)據(jù)，從而實現(xiàn)實時計算各個維度上的uv。
最后要特別提一下歷史交易訂單項目。這個項目實際上也是一個重構項目，目的是從以前的solr+bdb的方案上遷移到hbase上來。由于它關系到 己買到頁面，用戶使用頻率非常高，重要程度接近核心應用，對數(shù)據(jù)丟失以及服務中斷是零容忍。它對compact做了優(yōu)化，避免大數(shù)據(jù)量的compact在 服務時間內發(fā)生。新增了定制的filter來實現(xiàn)分頁查詢，rowkey上對應用進行了巧妙的設計以避免了冗余數(shù)據(jù)的傳輸以及90%以上的讀轉化成了順序 讀。目前該集群存儲了超過百億的訂單數(shù)據(jù)以及數(shù)千億的索引數(shù)據(jù)，線上故障率為0。
隨著業(yè)務的發(fā)展，目前我們定制的hbase集群己經(jīng)應用到了線上超過二十個應用，數(shù)百臺服務器上。包括淘寶首頁的商品實時推薦、廣泛用于賣家的實時量子統(tǒng)計等應用，并且還有繼續(xù)增多以及向核心應用靠近的趨勢。
4 部署、運維和監(jiān)控
Facebook之前曾經(jīng)透露過Facebook的hbase架構，可以說是非常不錯的。如他們將message服務的hbase集群按用戶分為數(shù) 個集群，每個集群100臺服務器，擁有一臺namenode以及分為5個機架，每個機架上一臺zookeeper?？梢哉f對于大數(shù)據(jù)量的服務這是一種優(yōu)良 的架構。對于淘寶來說，由于數(shù)據(jù)量遠沒有那么大，應用也沒有那么核心，因此我們采用公用hdfs以及zookeeper集群的架構。每個hdfs集群盡量 不超過100臺規(guī)模（這是為了盡量限制namenode單點問題）。在其上架設數(shù)個hbase集群，每個集群一個master以及一個 backupmaster。公用hdfs的好處是可以盡量減少compact的影響，以及均攤掉硬盤的成本，因為總有集群對磁盤空間要求高，也總有集群對 磁盤空間要求低，混合在一起用從成本上是比較合算的。zookeeper集群公用，每個hbase集群在zk上分屬不同的根節(jié)點。通過zk的權限機制來保 證hbase集群的相互獨立。zk的公用原因則僅僅是為了運維方便。
由于是在線應用，運維和監(jiān)控就變得更加重要，由于之前的經(jīng)驗接近0，因此很難招到專門的hbase運維人員。我們的開發(fā)團隊和運維團隊從一開始就很重視該問題，很早就開始自行培養(yǎng)。以下講一些我們的運維和監(jiān)控經(jīng)驗。
我們定制的hbase很重要的一部分功能就是增加監(jiān)控。hbase本身可以發(fā)送ganglia監(jiān)控數(shù)據(jù)，只是監(jiān)控項遠遠不夠，并且ganglia的 展示方式并不直觀和突出。因此一方面我們在代碼中侵入式地增加了很多監(jiān)控點，比如compact/split/balance/flush隊列以及各個階 段的耗時、讀寫各個階段的響應時間、讀寫次數(shù)、region的open/close，以及具體到表和region級別的讀寫次數(shù)等等。仍然將它們通過 socket的方式發(fā)送到ganglia中，ganglia會把它們記錄到rrd文件中，rrd文件的特點是歷史數(shù)據(jù)的精度會越來越低，因此我們自己編寫 程序從rrd中讀出相應的數(shù)據(jù)并持久化到其它地方，然后自己用js實現(xiàn)了一套監(jiān)控界面，將我們關心的數(shù)據(jù)以趨勢圖、餅圖等各種方式重點匯總和顯示出來，并 且可以無精度損失地查看任意歷史數(shù)據(jù)。在顯示的同時會把部分非常重要的數(shù)據(jù)，如讀寫次數(shù)、響應時間等寫入數(shù)據(jù)庫，實現(xiàn)波動報警等自定義的報警。經(jīng)過以上措 施，保證了我們總是能先于用戶發(fā)現(xiàn)集群的問題并及時修復。我們利用redis高效的排序算法實時地將每個region的讀寫次數(shù)進行排序，能夠在高負載的 情況下找到具體請求次數(shù)排名較高的那些region，并把它們移到空閑的regionserver上去。在高峰期我們能對上百臺機器的數(shù)十萬個 region進行實時排序。
為了隔離應用的影響，我們在代碼層面實現(xiàn)了可以檢查不同client過來的連接，并且切斷某些client的連接，以在發(fā)生故障時，將故障隔離在某個應用內部而不擴大化。mapreduce的應用也會控制在低峰期運行，比如在白天我們會關閉jobtracker等。
此外，為了保障服務從結果上的可用，我們也會定期跑讀寫測試、建表測試、hbck等命令。hbck是一個非常有用的工具，不過要注意它也是一個很重 的工操作，因此盡量減少hbck的調用次數(shù)，盡量不要并行運行hbck服務。在0.90.4以前的hbck會有一些機率使hbase宕機。另外為了確保 hdfs的安全性，需要定期運行fsck等以檢查hdfs的狀態(tài)，如block的replica數(shù)量等。
我們會每天根蹤所有線上服務器的日志，將錯誤日志全部找出來并且郵件給開發(fā)人員，以查明每一次error以上的問題原因和fix。直至錯誤降低為0。另外 每一次的hbck結果如果有問題也會郵件給開發(fā)人員以處理掉。盡管并不是每一次error都會引發(fā)問題，甚至大部分error都只是分布式系統(tǒng)中的正?，F(xiàn) 象，但明白它們問題的原因是非常重要的。
5 測試與發(fā)布
因為是未知的系統(tǒng)，我們從一開始就非常注重測試。測試從一開始就分為性能測試和功能測試。性能測試主要是注意基準測試，分很多場景，比如不同混合讀 寫比例，不同k/v大小，不同列族數(shù)，不同命中率，是否做presharding等等。每次運行都會持續(xù)數(shù)小時以得到準確的結果。因此我們寫了一套自動化 系統(tǒng)，從web上選擇不同的場景，后臺會自動將測試參數(shù)傳到各臺服務器上去執(zhí)行。由于是測試分布式系統(tǒng)，因此client也必須是分布式的。
我們判斷測試是否準確的依據(jù)是同一個場景跑多次，是否數(shù)據(jù)，以及運行曲線達到99%以上的重合度，這個工作非常煩瑣，以至于消耗了很多時間，但后來 的事實證明它非常有意義。因為我們對它建立了100%的信任，這非常重要，比如后期我們的改進哪怕只提高2%的性能也能被準確捕捉到，又比如某次代碼修改 使compact隊列曲線有了一些起伏而被我們看到，從而找出了程序的bug，等等。
功能測試上則主要是接口測試和異常測試。接口測試一般作用不是很明顯，因為hbase本身的單元測試己經(jīng)使這部分被覆蓋到了。但異常測試非常重要， 我們絕大部分bug修改都是在異常測試中發(fā)現(xiàn)的，這幫助我們去掉了很多生產(chǎn)環(huán)境中可能存在的不穩(wěn)定因素，我們也提交了十幾個相應的patch到社區(qū)，并受 到了重視和commit。分布式系統(tǒng)設計的難點和復雜度都在異常處理上，我們必須認為系統(tǒng)在通訊的任何時候都是不可靠的。某些難以復現(xiàn)的問題我們會通過查 看代碼大體定位到問題以后，在代碼層面強行拋出異常來復現(xiàn)它。事實證明這非常有用。
為了方便和快速定位問題，我們設計了一套日志收集和處理的程序，以方便地從每臺服務器上抓取相應的日志并按一定規(guī)律匯總。這非常重要，避免浪費大量的時間到登錄不同的服務器以尋找一個bug的線索。
由于hbase社區(qū)在不停發(fā)展，以及線上或測試環(huán)境發(fā)現(xiàn)的新的bug，我們需要制定一套有規(guī)律的發(fā)布模式。它既要避免頻繁的發(fā)布引起的不穩(wěn)定，又要 避免長期不發(fā)布導致生產(chǎn)版本離開發(fā)版本越來越遠或是隱藏的bug爆發(fā)。我們強行規(guī)定每兩周從內部trunk上release一個版本，該版本必須通過所有 的測試包括回歸測試，并且在release后在一個小型的集群上24小時不受甘擾不停地運行。每個月會有一次發(fā)布，發(fā)布時采用最新release的版本， 并且將現(xiàn)有的集群按重要性分級發(fā)布，以確保重要應用不受新版本的潛在bug影響。事實證明自從我們引入這套發(fā)布機制后，由發(fā)布帶來的不穩(wěn)定因素大大下降 了，并且線上版本也能保持不落后太多。
6 改進和優(yōu)化
Facebook是一家非常值得尊敬的公司，他們毫無保留地對外公布了對hbase的所有改造，并且將他們內部實際使用的版本開源到了社區(qū)。 facebook線上應用的一個重要特點是他們關閉了split，以降低split帶來的風險。與facebook不同，淘寶的業(yè)務數(shù)據(jù)量相對沒有如此龐 大，并且由于應用類型非常豐富，我們并們并沒有要求用戶強行選擇關閉split，而是盡量去修改split中可能存在的bug。到目前為止，雖然我們并不 能說完全解決了這個問題，但是從0.90.2中暴露出來的諸多跟split以及宕機相關的可能引發(fā)的bug我們的測試環(huán)境上己經(jīng)被修復到接近了0，也為社 區(qū)提交了10數(shù)個穩(wěn)定性相關的patch，比較重要的有以下幾個：
還有其它一些，我們主要將patch提交到0.92版本，社區(qū)會有commitor幫助我們backport回0.90版本。所以社區(qū)從 0.90.2一直到0.90.6一共發(fā)布了5個bugfix版本后，0.90.6版本其實己經(jīng)比較穩(wěn)定了。建議生產(chǎn)環(huán)境可以考慮這個版本。
split這是一個很重的事務，它有一個嚴重的問題就是會修改meta表（當然宕機恢復時也有這個問題）。如果在此期間發(fā)生異常，很有可能meta 表、rs內存、master內存以及hdfs上的文件會發(fā)生不一致，導致之后region重新分配時發(fā)生錯誤。其中一個錯誤就是有可能同一個region 被兩個以上的regionserver所服務，那么就可能出現(xiàn)這一個region所服務的數(shù)據(jù)會隨機分別寫到多臺rs上，讀取的時候也會分別讀取，導致數(shù) 據(jù)丟失。想要恢復原狀，必須刪除掉其中一個rs上的region，這就導致了不得不主動刪掉數(shù)據(jù)，從而引發(fā)數(shù)據(jù)丟失。
前面說到慢響應的問題歸納為網(wǎng)絡原因、gc問題、命中率以及client的反序列化問題。網(wǎng)絡原因一般是網(wǎng)絡不穩(wěn)定引起的，不過也有可能是tcp參 數(shù)設置問題，必須保證盡量減少包的延遲，如nodelay需要設置為true等，這些問題我們通過tcpdump等一系列工具專門定位過，證明tcp參數(shù) 對包的組裝確實會造成慢連接。gc要根據(jù)應用的類型來，一般在讀比較多的應用中新生代不能設置得太小。命中率極大影響了響應的時間，我們會盡量將 version數(shù)設為1以增加緩存的容量，良好的balance也能幫助充分應用好每臺機器的命中率。我們?yōu)榇嗽O計了表級別的balance。
由于hbase服務是單點的，即宕機一臺，則該臺機器所服務的數(shù)據(jù)在恢復前是無法讀寫的。宕機恢復速度決定了我們服務的可用率。為此主要做了幾點優(yōu) 化。首先是將zk的宕機發(fā)現(xiàn)時間盡量縮短到1分鐘，其次改進了master恢復日志為并行恢復，大大提高了master恢復日志的速度，然后我們修改了 openhandler中可能出現(xiàn)的一些超時異常，以及死鎖，去掉了日志中可能發(fā)生的open…too long等異常。原生的hbase在宕機恢復時有可能發(fā)生10幾分鐘甚至半小時無法重啟的問題己經(jīng)被修復掉了。另外，hdfs層面我們將 socket.timeout時間以及重試時間也縮短了，以降低datanode宕機引起的長時間block現(xiàn)象。
hbase本身讀寫層面的優(yōu)化我們目前并沒有做太多的工作，唯一打的patch是region增加時寫性能嚴重下降的問題。因為由于hbase本身 良好的性能，我們通過大量測試找到了各種應用場景中比較優(yōu)良的參數(shù)并應用于生產(chǎn)環(huán)境后，都基本滿足需求。不過這是我們接下來的重要工作。
7 將來計劃
我們目前維護著淘寶內基于社區(qū)0.90.x而定制的hbase版本。接下來除繼續(xù)fix它的bug外，會維護基于0.92.x修改的版本。之所以這 樣，是因為0.92.x和0.90.x的兼容性并不是非常好，而且0.92.x修改掉的代碼非常多，粗略統(tǒng)計會超過30%。0.92中有我們非?？粗氐囊?些特性。
0.92版本改進了hfile為hfileV2，v2版本的特點是將索引以及bloomfilter進行了大幅改造，以支持單個大hfile文 件。現(xiàn)有的HFile在文件大到一定程度時，index會占用大量的內存，并且加載文件的速度會因此下降非常多。而如果HFile不增大的 話，region就無法擴大，從而導致region數(shù)量非常多。這是我們想盡量避免的事。
0.92版本改進了通訊層協(xié)議，在通訊層中增加了length，這非常重要，它讓我們可以寫出nio的客戶端，使反序列化不再成為影響client性能的地方。
0.92版本增加了coprocessor特性，這支持了少量想要在rs上進行count等的應用。
還有其它很多優(yōu)化，比如改進了balance算法、改進了compact算法、改進了scan算法、compact變?yōu)镃F級別、動態(tài)做ddl等等特性。
除了0.92版本外，0.94版本以及最新的trunk(0.96)也有很多不錯的特性，0.94是一個性能優(yōu)化版本。它做了很多革命性工作，比如去掉root表，比如HLog進行壓縮，replication上支持多個slave集群，等等。
我們自己也有一些優(yōu)化，比如自行實現(xiàn)的二級索引、backup策略等都會在內部版本上實現(xiàn)。
另外值得一提的是hdfs層面的優(yōu)化也非常重要，hadoop-1.0.0以及cloudera-3u3的改進對hbase非常有幫助，比如本地化 讀、checksum的改進、datanode的keepalive設置、namenode的HA策略等。我們有一支優(yōu)秀的hdfs團隊來支持我們的 hdfs層面工作，比如定位以及fix一些hdfs層面的bug,幫助提供一些hdfs上參數(shù)的建議，以及幫助實現(xiàn)namenode的HA等。最新的測試 表明，3u3的checksum+本地化讀可以將隨機讀性能提升至少一倍。
我們正在做的一件有意義的事是實時監(jiān)控和調整regionserver的負載，能夠動態(tài)地將負載不足的集群上的服務器挪到負載較高的集群中，而整個過程對用戶完全透明。
總的來說，我們的策略是盡量和社區(qū)合作，以推動hbase在整個apache生態(tài)鏈以及業(yè)界的發(fā)展，使其能更穩(wěn)定地部署到更多的應用中去，以降低使用門檻以及使用成本。
關于數(shù)據(jù)庫 水平切分的介紹到此就結束了，不知道你從中找到你需要的信息了嗎 ？如果你還想了解更多這方面的信息，記得收藏關注本站。
成都網(wǎng)站設計制作選創(chuàng)新互聯(lián)，專業(yè)網(wǎng)站建設公司。
成都創(chuàng)新互聯(lián)10余年專注成都高端網(wǎng)站建設定制開發(fā)服務,為客戶提供專業(yè)的成都網(wǎng)站制作,成都網(wǎng)頁設計,成都網(wǎng)站設計服務;成都創(chuàng)新互聯(lián)服務內容包含成都網(wǎng)站建設，小程序開發(fā)，營銷網(wǎng)站建設，網(wǎng)站改版，服務器托管租用等互聯(lián)網(wǎng)服務。
網(wǎng)站欄目：數(shù)據(jù)庫水平切分：提高數(shù)據(jù)存儲和處理效率 (數(shù)據(jù)庫 水平切分)
標題鏈接：http://m.5511xx.com/article/dheddoj.html
