關(guān)于大型網(wǎng)站技術(shù)演進(jìn)的思考5--存儲(chǔ)的瓶頸5

Patagonia

　　
上文里我遺留了兩個(gè)問題，一個(gè)問題是數(shù)據(jù)庫做了水平拆分以后，如果我們對(duì)主鍵的設(shè)計(jì)采取一種均勻分布的策略，那么它對(duì)于被水平拆分出的表后續(xù)的查詢操作將有何種影響，第二個(gè)問題就是水平拆分的擴(kuò)容問題。這兩個(gè)問題在深入下去，本系列就越來越技術(shù)化了，可能最終很多朋友讀完后還是沒有找到解決實(shí)際問題的啟迪，而且我覺得這些問題都是像BAT這樣巨型互聯(lián)網(wǎng)公司才會(huì)認(rèn)真思考的，因此本篇我打算換個(gè)角度來闡述本文的后續(xù)內(nèi)容。
　　這里我們首先要明確一個(gè)問題，到底是什么因素促使我們?nèi)プ鰯?shù)據(jù)庫的垂直拆分和水平拆分的呢？答案很簡單就是業(yè)務(wù)發(fā)展的需求，前文里的水平拆分技術(shù)方案基本都是拋棄千變?nèi)f化的業(yè)務(wù)規(guī)則的限制，盡量將水平拆分的問題歸為一個(gè)簡單的技術(shù)實(shí)現(xiàn)方案，而純技術(shù)手段時(shí)常是看起來很美，但是到了面對(duì)現(xiàn)實(shí)問題時(shí)候，常常會(huì)變得那么蒼白和無力。
　　水平拆分的難題里我還有個(gè)難題沒有講述，就是水平拆分后對(duì)查詢操作的影響，特別是對(duì)單表查詢的影響，這點(diǎn)估計(jì)也是大伙最為關(guān)心的問題，今天我不在延著水平拆分的技術(shù)手段演進(jìn)是闡述上文的遺留問題，而是我要把前面提到的技術(shù)手段和一些典型場景結(jié)合起來探討如何解決網(wǎng)站存儲(chǔ)的瓶頸問題。
　　前文中我總結(jié)過一個(gè)解決存儲(chǔ)瓶頸的脈絡(luò)，具體如下：
　　單庫數(shù)據(jù)庫-->數(shù)據(jù)庫讀寫分離-->緩存技術(shù)-->搜索技術(shù)-->數(shù)據(jù)的垂直拆分-->數(shù)據(jù)的水平拆分
　　這個(gè)脈絡(luò)給一些朋友產(chǎn)生了誤解，就是認(rèn)為這個(gè)過程應(yīng)該是個(gè)串行的過程，其實(shí)在實(shí)際的場景下這個(gè)過程往往是并行的，但是里面有一個(gè)元素應(yīng)該是串行的或者說思考時(shí)候有個(gè)先后問題，那就是對(duì)數(shù)據(jù)庫層的操作，具體如下：
　　單庫數(shù)據(jù)庫-->數(shù)據(jù)庫讀寫分離-->數(shù)據(jù)的垂直拆分-->數(shù)據(jù)的水平拆分
　　而緩存技術(shù)和搜索技術(shù)在數(shù)據(jù)庫的任意階段里都可以根據(jù)實(shí)際的業(yè)務(wù)需求隨時(shí)切入其中幫助數(shù)據(jù)庫減輕不必要的壓力。例如，當(dāng)網(wǎng)站的后臺(tái)數(shù)據(jù)庫還是單庫的時(shí)候，數(shù)據(jù)庫漸漸出現(xiàn)了瓶頸問題，而這個(gè)瓶頸又沒有達(dá)到需要采取大張旗鼓做讀寫分離方案的程度，那么我這個(gè)時(shí)候可以考慮引入緩存機(jī)制。不過要合理的使用緩存我們首先要明確緩存本身的特點(diǎn)，這些特點(diǎn)如下所示：
　　特點(diǎn)一：緩存主要是適用于讀操作，并且緩存的讀操作的效率要遠(yuǎn)遠(yuǎn)高于從數(shù)據(jù)庫以及硬盤讀取數(shù)據(jù)的效率。
　　特點(diǎn)二：緩存的數(shù)據(jù)是存儲(chǔ)在內(nèi)存當(dāng)中，因此當(dāng)系統(tǒng)重啟，宕機(jī)等等異常場景下，緩存數(shù)據(jù)就會(huì)不可逆的丟失，且無法恢復(fù)，因此緩存不能作為可靠存儲(chǔ)設(shè)備，這就導(dǎo)致一個(gè)問題，緩存里的數(shù)據(jù)必須首先從數(shù)據(jù)庫里同步到內(nèi)存中，而使用緩存的目的就是為了解決數(shù)據(jù)庫的讀操作效率低下的問題，數(shù)據(jù)庫的數(shù)據(jù)同步到緩存的操作會(huì)因?yàn)閿?shù)據(jù)庫的效率低下而在性能上大打折扣，所以緩存適合的場景是那些固定不變的數(shù)據(jù)以及業(yè)務(wù)對(duì)實(shí)時(shí)性變化要求不高的數(shù)據(jù)。
　　根據(jù)緩存的上述兩個(gè)特點(diǎn)，我們可以把數(shù)據(jù)庫里和上述描述類似操作的相關(guān)數(shù)據(jù)遷移到緩存里，那樣我們就從數(shù)據(jù)庫上剝離了那些對(duì)數(shù)據(jù)庫價(jià)值不高的操作，讓數(shù)據(jù)庫專心做有價(jià)值的操作，這樣也是減輕數(shù)據(jù)庫壓力的一種手段。
　　不過這個(gè)手段局限性很強(qiáng)，局限性主要是一臺(tái)計(jì)算機(jī)了用于存儲(chǔ)緩存的內(nèi)存的大小都是遠(yuǎn)遠(yuǎn)要低于硬盤，并且內(nèi)存的價(jià)格要遠(yuǎn)貴于硬盤，如果我們將大規(guī)模的數(shù)據(jù)從硬盤往內(nèi)存遷移，從資源成本和利用率角度考慮性價(jià)比還是很低的，因此緩存往往都是用于轉(zhuǎn)存那些不會(huì)經(jīng)常變化的數(shù)據(jù)字典，以及經(jīng)常會(huì)被讀，而修改較少的數(shù)據(jù)，但是這些數(shù)據(jù)的規(guī)模也是有一定限度的，因此當(dāng)單庫數(shù)據(jù)庫出現(xiàn)了瓶頸時(shí)候馬上就著手進(jìn)行讀寫分離方案的設(shè)計(jì)性價(jià)比還是很高的。
　　前文我講到我們之所以選擇數(shù)據(jù)庫讀寫分離是主要原因是因?yàn)閿?shù)據(jù)庫的讀寫比例嚴(yán)重失衡所致，但是做了讀寫分離必然有個(gè)問題不可避免，寫庫向讀庫同步數(shù)據(jù)一定會(huì)存在一定的時(shí)間差，如果我們想減小讀庫和寫庫數(shù)據(jù)的時(shí)間差，那么任然會(huì)導(dǎo)致讀庫因?yàn)閷懙牧６冗^細(xì)而發(fā)生部分性能的損失，但是時(shí)間差過大，或許又會(huì)無法滿足實(shí)際的業(yè)務(wù)需求，因此這個(gè)時(shí)間差的設(shè)計(jì)一定要基于實(shí)際的業(yè)務(wù)需求合理的設(shè)計(jì)。
　　同步的時(shí)間差的問題還是個(gè)小問題，也比較好解決，但是如何根據(jù)實(shí)際的業(yè)務(wù)需求做讀寫分離這其實(shí)還是非常有挑戰(zhàn)性的，這里我舉個(gè)很常見的例子來說明讀寫分離的難度問題，我們這里以淘寶為例，淘寶是個(gè)C2C的電商網(wǎng)站，它是互聯(lián)網(wǎng)公司提供一個(gè)平臺(tái)，商家自助接入這個(gè)平臺(tái)，在這個(gè)平臺(tái)上賣東西，這個(gè)和線下很多大賣場的模式類似。淘寶是個(gè)大平臺(tái)，它的交易表里一定是要記下所有商戶的交易數(shù)據(jù)，但是針對(duì)單個(gè)商家他們只會(huì)關(guān)心自己的網(wǎng)店的銷售數(shù)據(jù)，這就有一個(gè)問題了，如果某一個(gè)商家要查詢自己的交易信息，淘寶就要從成千上萬的交易信息里檢索出該商家的交易信息，那么如果我們把所有交易信息放在一個(gè)交易表里，肯定有商家會(huì)有這樣的疑問，我的網(wǎng)店每天交易額不大，為什么我查詢交易數(shù)據(jù)的速度和那些大商家一樣慢了？那么我們到底該如何是解決這樣的場景了？
　　碰到這樣的情況，當(dāng)網(wǎng)站的交易規(guī)模變大后就算我們把交易表做了讀寫分離估計(jì)也是沒法解決實(shí)際的問題，就算我們做的徹底點(diǎn)把交易表垂直拆分出來估計(jì)還是解決不了問題，因?yàn)橐粋�(gè)業(yè)務(wù)數(shù)據(jù)庫擁有很多張表，但是真正壓力大的表畢竟是少數(shù)，這個(gè)符合28原則，而數(shù)據(jù)庫大部分的關(guān)鍵問題又都是在那些數(shù)據(jù)壓力大的表里，就算我們把這些表單獨(dú)做讀寫分離甚至做垂直拆分，其實(shí)只是把數(shù)據(jù)庫最大的問題遷移出原來數(shù)據(jù)庫，而不是在解決該表的實(shí)際問題。
　　如果我們要解決交易表的問題我們首先要對(duì)交易表做業(yè)務(wù)級(jí)的拆分，那么我們要為交易表增加一個(gè)業(yè)務(wù)維度：實(shí)時(shí)交易和歷史交易，一般而言實(shí)時(shí)交易以當(dāng)天及當(dāng)天24小時(shí)為界，歷史交易則是除去當(dāng)天交易外的所有歷史交易數(shù)據(jù)。實(shí)時(shí)交易數(shù)據(jù)和歷史交易數(shù)據(jù)有著很大不同，實(shí)時(shí)交易數(shù)據(jù)讀與寫是比較均衡的，很多時(shí)候估計(jì)寫的頻率會(huì)遠(yuǎn)高于讀的頻率，但是歷史交易表這點(diǎn)上和實(shí)時(shí)交易就完全不同了，歷史交易表的讀操作頻率會(huì)遠(yuǎn)大于寫操作頻率，如果我們將交易表做了實(shí)時(shí)交易和歷史交易的拆分后，那么讀寫分離方案適合的場景是歷史交易查詢而非實(shí)時(shí)交易查詢，不過歷史交易表的數(shù)據(jù)是從實(shí)時(shí)交易表里同步過來的，根據(jù)這兩張表的業(yè)務(wù)特性，我們可以按如下方案設(shè)計(jì)，具體如下：
　　我們可以把實(shí)時(shí)交易表設(shè)計(jì)成兩張表，把它們分別叫做a表和b表，a表和b表按天交替進(jìn)行使用，例如今天我們用a表記錄實(shí)時(shí)交易，明天我們就用b表記錄實(shí)時(shí)交易，當(dāng)然我們事先可以用個(gè)配置表記錄今天到底使用那張表進(jìn)行實(shí)時(shí)交易記錄，為什么要如此麻煩的設(shè)計(jì)實(shí)時(shí)交易表了？這么做的目的是為了實(shí)時(shí)交易數(shù)據(jù)同步到歷史數(shù)據(jù)時(shí)候提供便利，一般我們會(huì)在凌晨0點(diǎn)切換實(shí)時(shí)交易表，過期的實(shí)時(shí)交易表數(shù)據(jù)會(huì)同步到歷史交易表里，這個(gè)時(shí)候需要數(shù)據(jù)遷移的實(shí)時(shí)交易表是全表數(shù)據(jù)遷移，效率是非常低下，假如實(shí)時(shí)交易表的數(shù)據(jù)量很大的時(shí)候，這種導(dǎo)入同步操作會(huì)變得十分耗時(shí)，所以我們設(shè)計(jì)兩張實(shí)時(shí)交易表進(jìn)行切換來把數(shù)據(jù)同步的風(fēng)險(xiǎn)降到最低。由此可見，歷史交易表每天基本都只做一次寫操作，除非同步出了問題，才會(huì)重復(fù)進(jìn)行寫操作，但是寫的次數(shù)肯定是很低的，所以歷史交易表的讀寫比例失衡是非常嚴(yán)重的。不過實(shí)時(shí)交易表的切換也是有技術(shù)和業(yè)務(wù)風(fēng)險(xiǎn)的，為了保證實(shí)時(shí)交易表的高效性，我們一般在數(shù)據(jù)同步操作成功后會(huì)清空實(shí)時(shí)交易表的數(shù)據(jù)，但是我們很難保證這個(gè)同步會(huì)不會(huì)有問題，因此同步時(shí)候我們最好做下備份，此外，兩個(gè)表切換的時(shí)候肯定會(huì)碰到這樣的場景，就是有人在凌晨0點(diǎn)前做了交易，但是這個(gè)交易是在零點(diǎn)后做完，假如實(shí)時(shí)交易表會(huì)記錄交易狀態(tài)的演變過程，那么在切換時(shí)候就有可能兩個(gè)實(shí)時(shí)表的數(shù)據(jù)沒有做好接力，因此我們同步到歷史交易表的數(shù)據(jù)一定要保持一個(gè)原則就是已經(jīng)完成交易的數(shù)據(jù)，沒有完成的交易數(shù)據(jù)兩張實(shí)時(shí)交易還要完成一個(gè)業(yè)務(wù)上的接力，這就是業(yè)界常說的數(shù)據(jù)庫日切的問題。
　　歷史交易表本身就是為讀使用的，所以我們從業(yè)務(wù)角度將交易表拆分成實(shí)時(shí)交易表和歷史交易表本身就是在為交易表做讀寫分離，居然了設(shè)計(jì)了歷史交易表我們就做的干脆點(diǎn)，把歷史交易表做垂直拆分，將它從原數(shù)據(jù)庫里拆分出來獨(dú)立建表，隨著歷史交易的增大，上文里所說的某個(gè)商戶想快速檢索出自己的數(shù)據(jù)的難題并沒有得到根本的改善，為了解決這個(gè)難題我們就要分析下難題的根源在那里。這個(gè)根源很簡單就是我們把所有商戶的數(shù)據(jù)不加區(qū)別的放進(jìn)了一張表里，不管是交易量大的商戶還是交易量小的商戶，想要查詢出自己的數(shù)據(jù)都要進(jìn)行全表檢索，而關(guān)系數(shù)據(jù)庫單表記錄達(dá)到一定數(shù)據(jù)量后全表檢索就會(huì)變的異常低效，例如DB2當(dāng)數(shù)據(jù)量超過了1億多，mysql單表超過了100萬條后那么全表查詢這些表的記錄都會(huì)存在很大的效率問題，那么我們就得對(duì)歷史交易表進(jìn)一步拆分，因?yàn)閱栴}根源是單表數(shù)據(jù)量太大了，那我們就可以對(duì)單表的數(shù)據(jù)進(jìn)行拆分，把單表分成多表，這個(gè)場景就和前面說的水平拆分里把原表變成邏輯表，原表的數(shù)據(jù)分散到各個(gè)獨(dú)立的邏輯表里的方式一致，不過這里我們沒有一開始做水平拆分，那是會(huì)把問題變麻煩，我們只要在一個(gè)數(shù)據(jù)庫下對(duì)單表進(jìn)行拆分即可，這樣也能滿足我們的要求，并且避免了水平拆分下的跨庫寫作的難題。接下來我們又有一個(gè)問題了那就是我們按什么維度拆分這張單表呢？
　　我們按照前文講到的水平拆分里主鍵設(shè)計(jì)方案執(zhí)行嗎？當(dāng)然不行哦，因?yàn)槟切┓桨该黠@提升不了商戶檢索數(shù)據(jù)的效率問題，所以我們要首先分析下商戶檢索數(shù)據(jù)的方式，商戶一般會(huì)按這幾個(gè)維度檢索數(shù)據(jù)，這些維度分別是：商戶號(hào)、交易時(shí)間、交易類型，當(dāng)然還有其他的維度，我這里就以這三個(gè)維度為例闡述下面的內(nèi)容，商戶查詢數(shù)據(jù)效率低下的根本原因是全表檢索，其實(shí)商戶查詢至少有一個(gè)維度那就是商戶號(hào)來進(jìn)行查詢，如果我們把該商戶的數(shù)據(jù)存入到一張單獨(dú)的表里，自然查詢的效率會(huì)有很大的提升，但是在實(shí)際系統(tǒng)開發(fā)里我們很少通過商戶號(hào)進(jìn)行拆分表，這是為什么呢？因?yàn)橐粋�(gè)電商平臺(tái)的商戶是個(gè)動(dòng)態(tài)的指標(biāo)，會(huì)經(jīng)常發(fā)生變化，其次，商戶號(hào)的粒度很細(xì)，如果使用商戶號(hào)拆分表的必然會(huì)有這樣的后果那就是我們可能要頻繁的建表，隨著商戶的增加表的數(shù)量也會(huì)增加，造成數(shù)據(jù)的碎片化，同時(shí)不同的商戶交易量是不一樣的，按商戶建表會(huì)造成數(shù)據(jù)存儲(chǔ)的嚴(yán)重不平衡。如果使用交易類型來拆分表，雖然維度的粒度比商戶號(hào)小，但是會(huì)造成數(shù)據(jù)的分散化，也就是說我們查詢一個(gè)商戶的全部交易數(shù)據(jù)會(huì)存在很大問題。由此可見拆表時(shí)候如何有效的控制維度的粒度以及數(shù)據(jù)的聚集度是拆分的關(guān)鍵所在，因?yàn)槭褂媒灰讜r(shí)間這個(gè)維度就會(huì)讓拆分更加合理，不過時(shí)間的維度的設(shè)計(jì)也是很有學(xué)問的，下面我們看看騰訊分析的維度，如下所示：


　　騰訊分析的維度是今天這個(gè)其實(shí)相當(dāng)于實(shí)時(shí)交易查詢，除此之外都是對(duì)歷史數(shù)據(jù)查詢，它們分為昨天、最近7天和最近30天，我們?nèi)绻�要�?duì)歷史交易表進(jìn)行拆分也是可以參照騰訊分析的維度進(jìn)行，不過不管我們選擇什么維度拆分?jǐn)?shù)據(jù)，那么都是犧牲該維度成全了其他維度，例如我們按騰訊分析的維度拆分?jǐn)?shù)據(jù)，那么我們想靈活使用時(shí)間查詢數(shù)據(jù)將會(huì)受到限制。
　　我們把歷史交易數(shù)據(jù)通過交易時(shí)間維度進(jìn)行了拆分，雖然得到了效率提升，但是歷史交易數(shù)據(jù)表是個(gè)累積表，隨著時(shí)間推移，首先是月表，接下來是周表都會(huì)因?yàn)閿?shù)據(jù)累積產(chǎn)生查詢效率低下的問題，這個(gè)時(shí)候我們又該如何解決了？這個(gè)時(shí)候我們需要再引進(jìn)一個(gè)維度，那么這個(gè)時(shí)候我們可以選擇商戶號(hào)這個(gè)維度，但是商戶號(hào)作為拆分維度是有一定問題的，因?yàn)闀?huì)造成數(shù)據(jù)分布不均衡，那么我們就得將維度的粒度由小變粗，其實(shí)一個(gè)電商平臺(tái)上往往少數(shù)商戶是完成了大部分電商平臺(tái)的交易，因此我們可以根據(jù)一定指標(biāo)把重要商戶拆分出來，單獨(dú)建表，這樣就可以平衡了數(shù)據(jù)的分布問題。
　　我們總結(jié)下上面的案例，我們會(huì)得到很多的啟迪，我將這些啟迪總結(jié)如下：
　　啟迪一：數(shù)據(jù)庫的讀寫分離不是簡單的把主庫數(shù)據(jù)導(dǎo)入到讀庫里就能解決問題，讀數(shù)據(jù)庫和寫數(shù)據(jù)的分離的目的是為了讓讀和寫操作不能相互影響效率。
　　啟迪二：解決讀的瓶頸問題的本質(zhì)是減少數(shù)據(jù)的檢索范圍，數(shù)據(jù)檢索的范圍越小，讀的效率也就越高；
　　啟迪三：數(shù)據(jù)庫的垂直拆分和水平拆分首先不應(yīng)該從技術(shù)角度進(jìn)行，而是通過業(yè)務(wù)角度進(jìn)行，如果數(shù)據(jù)庫進(jìn)行業(yè)務(wù)角度的水平拆分，那么拆分的維度往往是要根據(jù)該表的某個(gè)字段進(jìn)行的，這個(gè)字段選擇要有一定原則，這個(gè)原則主要是該字段的維度的粒度不能過細(xì)，該字段的維度范圍不能經(jīng)常的動(dòng)態(tài)發(fā)生變化，最后就是該維度不能讓數(shù)據(jù)分布嚴(yán)重失衡。
　　回到現(xiàn)實(shí)的開發(fā)里，對(duì)于一個(gè)數(shù)據(jù)庫做拆表，分表的工作其實(shí)是一件很讓人惱火的工作，這主要是有以下原因所造成的，具體如下所述：
　　原因一：一個(gè)數(shù)據(jù)庫其實(shí)容納多少張表是有一定限制的，就算沒有超過這個(gè)限制，如果原庫本來有30張表，我們拆分后變成了60張，接著是120張，那么數(shù)據(jù)庫本身管理這么多表也會(huì)消耗很多性能，因此公司的DBA往往會(huì)控制那些過多分表的行為。
　　原因二：每次拆表后，都會(huì)牽涉到歷史數(shù)據(jù)的遷移問題，這個(gè)遷移風(fēng)險(xiǎn)很大，遷移方案如果設(shè)計(jì)的不完善可能會(huì)導(dǎo)致數(shù)據(jù)丟失或者損壞，如果關(guān)鍵數(shù)據(jù)發(fā)生了丟失和損壞，結(jié)果可能非常致命。因此在設(shè)計(jì)數(shù)據(jù)庫分表分庫方案時(shí)候我們要盡量讓受影響的數(shù)據(jù)范圍變得最小。
　　原因三：每次拆表和分表都會(huì)讓系統(tǒng)的相關(guān)方繃緊神經(jīng)，方案執(zhí)行后，會(huì)有很長時(shí)間的監(jiān)控和觀察期，所以拆數(shù)據(jù)庫時(shí)常是一件令人討厭的事情。
　　原因四：為了保證新方案執(zhí)行后確保系統(tǒng)沒有問題，我們常常會(huì)讓新舊系統(tǒng)并行運(yùn)行一段時(shí)間，這樣可以保證如果新方案出現(xiàn)問題，問題的影響面最低，但是這種做法也有一個(gè)惡果就是會(huì)導(dǎo)致數(shù)據(jù)遷移方案要進(jìn)行動(dòng)態(tài)調(diào)整，從而增加遷移數(shù)據(jù)的風(fēng)險(xiǎn)
　　因此當(dāng)公司不得不做這件事情時(shí)候，公司都會(huì)很自然去考慮第三種解決方案，第三種解決方案是指盡量不改變原數(shù)據(jù)庫的功能，而是另起爐灶，使用新技術(shù)來解決我們的問題，例如前文所說的搜索技術(shù)解決數(shù)據(jù)庫like的低效問題就是其中方案之一，該方案只要我們將數(shù)據(jù)庫的表按一定時(shí)間導(dǎo)入到文件系統(tǒng)，然后對(duì)文件建立倒排索引，讓like查詢效率更好，這樣就不用改變原數(shù)據(jù)庫的功能，又能減輕數(shù)據(jù)庫的壓力。
　　現(xiàn)在常用的第三種解決方案就是使用NoSql數(shù)據(jù)庫，NoSql數(shù)據(jù)庫大多都是針對(duì)文件進(jìn)行的，因此我們可以和使用搜索引擎那樣把數(shù)據(jù)導(dǎo)入到文件里就行了，NoSql基本都采用Key/Value這種簡單的數(shù)據(jù)結(jié)構(gòu)，這種數(shù)據(jù)結(jié)構(gòu)和關(guān)系數(shù)據(jù)庫比起來更加的靈活，對(duì)原始數(shù)據(jù)的約束最少，所以在NoSql數(shù)據(jù)庫里建表我們可以很靈活的把列和行的特性交叉起來用，這句話可能很多人不太理解，下面我舉個(gè)例子解釋下，例如hadoop技術(shù)體系里的hbase，hbase是一個(gè)基于列族的數(shù)據(jù)庫，使用hbase時(shí)候我們就可以通過列來靈活的拆分?jǐn)?shù)據(jù)，比如我們可以把中國的省份作為一個(gè)列，將該省份的數(shù)據(jù)都放入到這個(gè)列下面，在省這個(gè)維度下我們可以接著在定義一個(gè)列的維度，例如軟件行業(yè)，屬于軟件行業(yè)的數(shù)據(jù)放在這個(gè)列下面，最終提供用戶查詢時(shí)候我們就可以減少數(shù)據(jù)檢索的范圍，最終達(dá)到提升查詢效率的目的。由此可見當(dāng)我們用慣了關(guān)系數(shù)據(jù)庫后，學(xué)習(xí)像hbase這樣的Nosql數(shù)據(jù)庫我們會(huì)非常的不適應(yīng)，因?yàn)殛P(guān)系數(shù)據(jù)庫的表有固定模式，也就是我們常說的結(jié)構(gòu)化數(shù)據(jù)，當(dāng)表的定義好了后，就算里面沒有數(shù)據(jù)，那么這個(gè)結(jié)構(gòu)也就固定了，我們使用表的時(shí)候都是按這個(gè)模型下面，我們幾乎感覺不到它，但是到了hbase的使用就不同了，hbase使用時(shí)候我們都在不停的為數(shù)據(jù)增加結(jié)構(gòu)化模型，而且這個(gè)維度是以列為維度的，而關(guān)系數(shù)據(jù)庫里列確定后我們使用時(shí)候是無法改變的，這就是學(xué)習(xí)hbase的最大困難之一。Hbase之所以這么麻煩的設(shè)計(jì)這樣的計(jì)算模型，終極目的就是為了讓海量數(shù)據(jù)按不同維度存儲(chǔ)起來，使用時(shí)候盡全力檢索數(shù)據(jù)檢索的數(shù)量，從而達(dá)到海量數(shù)據(jù)快速讀取的目的。
　　好了，今天就寫到這里，祝大家生活愉快。
轉(zhuǎn)自
http://www.cnblogs.com/sharpxiajun/p/4265853.html
                       
                               
                    
                               
                       
                       
                       
                                時(shí)間:2015-02-02 21:34來源:博客園 作者:夏天的森林責(zé)任編輯:zhangkai

本文來自ChinaUnix新聞?lì)l道，如果查看原文請點(diǎn)：http://news.chinaunix.net/opensource/2015/0203/3234098.shtml