想必在數(shù)據(jù)量情況少的情況下我們首先想到的時(shí)擅長(zhǎng)于存儲(chǔ)的常見數(shù)據(jù)庫如MySQL或者oracle,甚至我們可以將企業(yè)的web Server,db Server都裝載到一個(gè)服務(wù)中，但是隨著時(shí)間或者公司的成長(zhǎng)數(shù)據(jù)庫會(huì)越來越滿。
這時(shí)候我們想到了讀寫分離，使用Master/salve架構(gòu)，使用Master負(fù)責(zé)寫操作，使用幾個(gè)Salve負(fù)責(zé)寫操作。
但是隨著壓力增大，Master節(jié)點(diǎn)壓力也變大，一般我們采用的是進(jìn)行垂直分庫，就是將沒有邏輯關(guān)系的數(shù)據(jù)表，分布在不同的數(shù)據(jù)庫中。當(dāng)數(shù)據(jù)一直增大導(dǎo)致一張表的數(shù)據(jù)會(huì)特別大，這樣也會(huì)使得一個(gè)數(shù)據(jù)表的查詢變得特別慢，我們只能采取的水平分區(qū)的辦法，將一個(gè)表的數(shù)據(jù)量限制在10W,來減輕庫的壓力。
畢竟不是最終的解決辦法，不能解決數(shù)據(jù)一直激增的存儲(chǔ)問題。Hadoop是通過集群的方式，即通過增加機(jī)器的方式解決了數(shù)據(jù)的存儲(chǔ)問題。
目前oracle雖然可以搭建集群 但是當(dāng)數(shù)據(jù)量達(dá)到一定限度之后查詢處理速度會(huì)變得很慢 且對(duì)機(jī)器性能要求很高。
SQL數(shù)據(jù)庫和Hadoop 區(qū)別
用向外擴(kuò)展代替向上擴(kuò)展
Hadoop集群就是增加更多的機(jī)器。一個(gè)Hadoop集群的標(biāo)配是十至數(shù)百臺(tái)計(jì)算機(jī)。而不是專注于提高單臺(tái)服務(wù)器的性能用鍵/值對(duì)代替關(guān)系表
SQL 針對(duì)結(jié)構(gòu)化查詢語句 是結(jié)構(gòu)化數(shù)據(jù)，hadoop針對(duì)的是非結(jié)構(gòu)化數(shù)據(jù)，文本形式
關(guān)系數(shù)據(jù)庫是 有一定格式，而存放文本、圖片和xml文件 則應(yīng)該用鍵值對(duì)的方式用函數(shù)式編程（MapReduce）代替聲明式查詢（SQL）
hadoop讀取出的數(shù)據(jù)，可以建立復(fù)雜的模型或者改變圖片格式用離線批量處理代替在線處理
Hadoop是專為離線處理和大規(guī)模數(shù)據(jù)分析而設(shè)計(jì)的，它并不適合那種對(duì)幾個(gè)記錄隨機(jī)讀寫的在線事務(wù)處理模式。
同時(shí)在設(shè)計(jì)Hadoop時(shí)考慮的是對(duì)大量數(shù)據(jù)的存儲(chǔ)和操作，雖然在小量的數(shù)據(jù)上Hadoop可能不如RDMS,但是大量數(shù)據(jù)存儲(chǔ)情況下，如HDFS可以存儲(chǔ)超大的文件，更新或修改大部分?jǐn)?shù)據(jù)時(shí)MapReduce效率大于常見數(shù)據(jù)的B樹查詢。
為什么不通過使用數(shù)據(jù)庫加上更多磁盤來做大規(guī)模批量分析？為什么我們還需要MapReduce？
1、磁盤驅(qū)動(dòng)器尋址時(shí)間的速度遠(yuǎn)遠(yuǎn)慢于傳輸速率的提高速度，尋址就是將磁頭移動(dòng)到特定位置進(jìn)行讀寫操作的工序，它的特點(diǎn)是磁盤操作有延遲，而傳輸速率對(duì)應(yīng)磁盤的帶寬。如果數(shù)據(jù)的訪問受限于磁盤的
尋址，勢(shì)必會(huì)導(dǎo)致它花更長(zhǎng)的時(shí)間來讀或?qū)懘蟛糠謹(jǐn)?shù)據(jù)。
2、在更新一小部分?jǐn)?shù)據(jù)的情況下，傳統(tǒng)的B樹效果很好，但在更新大部分?jǐn)?shù)據(jù)時(shí)，B樹的效率就沒有MapReduce的高，因?yàn)樗枰褂门判?合并來重建數(shù)據(jù)庫。
在很多情況下，MapReduce能夠被視為一種RDBMS的補(bǔ)充，MapReduce很適合處理那些需要分析整個(gè)數(shù)據(jù)集的問題，以批處理的方式，尤其是Ad Hoc（自主或即時(shí)）分析。RDBMS適用于點(diǎn)查詢和更新
（其中，數(shù)據(jù)集已經(jīng)被索引以提供低延遲的檢索和短時(shí)間的少量數(shù)據(jù)更新）。MapReduce適合數(shù)據(jù)被一次寫入和多次讀取的應(yīng)用，而RDBMS更適合持續(xù)更新的數(shù)據(jù)集。
為什么數(shù)據(jù)庫使用B樹索引而非散列索引？
一般關(guān)系型數(shù)據(jù)庫使用B+樹來做索引，NoSQL數(shù)據(jù)庫用哈希來做索引。MySQL就普遍使用B+Tree實(shí)現(xiàn)其索引結(jié)構(gòu)。
因?yàn)樗饕旧硪埠艽?，不可能全部存?chǔ)在內(nèi)存中，因此索引往往以索引文件的形式存儲(chǔ)的磁盤上。這樣的話，索引查找過程中就要產(chǎn)生磁盤I/O消耗，相對(duì)于內(nèi)存存取，I/O存取的消耗要高幾個(gè)數(shù)量級(jí)，所以評(píng)價(jià)一個(gè)數(shù)據(jù)結(jié)構(gòu)作為索引的優(yōu)劣最重要的指標(biāo)就是在查找過程中磁盤I/O操作次數(shù)的漸進(jìn)復(fù)雜度。
因此為了提高效率，要盡量減少磁盤I/O。
為了達(dá)到這個(gè)目的，磁盤往往不是嚴(yán)格按需讀取，而是每次都會(huì)預(yù)讀，即使只需要一個(gè)字節(jié)，磁盤也會(huì)從這個(gè)位置開始，順序向后讀取一定長(zhǎng)度的數(shù)據(jù)放入內(nèi)存。這樣做的理論依據(jù)是計(jì)算機(jī)科學(xué)中著名的局部性原理：
當(dāng)一個(gè)數(shù)據(jù)被用到時(shí)，其附近的數(shù)據(jù)也通常會(huì)馬上被使用。程序運(yùn)行期間所需要的數(shù)據(jù)通常比較集中。
根據(jù)B Tree的定義，可知檢索一次最多需要訪問h個(gè)節(jié)點(diǎn)。數(shù)據(jù)庫系統(tǒng)的設(shè)計(jì)者巧妙利用了磁盤預(yù)讀原理，將一個(gè)節(jié)點(diǎn)的大小設(shè)為等于一個(gè)頁，這樣每個(gè)節(jié)點(diǎn)只需要一次I/O就可以完全載入。為了達(dá)到這個(gè)目的，在實(shí)際實(shí)現(xiàn)中B-Tree在每次新建節(jié)點(diǎn)時(shí)，直接申請(qǐng)一個(gè)頁的空間，這樣就保證一個(gè)節(jié)點(diǎn)物理上也存儲(chǔ)在一個(gè)頁里，加之計(jì)算機(jī)存儲(chǔ)分配都是按頁對(duì)齊的，就實(shí)現(xiàn)了一個(gè)node只需一次I/O。
B-Tree中一次檢索最多需要h-1次I/O（根節(jié)點(diǎn)常駐內(nèi)存），漸進(jìn)復(fù)雜度為O(h)=O(logdN)。一般實(shí)際應(yīng)用中，出度d是非常大的數(shù)字，通常超過100，因此h非常?。ㄍǔ２怀^3）。
綜上所述， 用B-Tree作為索引結(jié)構(gòu)效率是非常高的。
而紅黑樹這種結(jié)構(gòu)，h明顯要深的多。由于邏輯上很近的節(jié)點(diǎn)（父子）物理上可能很遠(yuǎn)，無法利用局部性，所以紅黑樹的I/O漸進(jìn)復(fù)雜度也為O(h)，效率明顯比B-Tree差很多。
B+Tree更適合外存索引，原因和內(nèi)節(jié)點(diǎn)出度d有關(guān)。從上面分析可以看到，d越大索引的性能越好，而出度的上限取決于節(jié)點(diǎn)內(nèi)key和data的大小，由于B+Tree內(nèi)節(jié)點(diǎn)去掉了data域，因此可以擁有更大的出度，擁有更好的性能
