国产一级a片免费看高清,亚洲熟女中文字幕在线视频,黄三级高清在线播放,免费黄色视频在线看

背景

前段時(shí)間國內(nèi)外對(duì)NoSQL的討論非常熱烈，Digg和Reddit使用Cassandra，F(xiàn)acebook經(jīng)過一些變化后依然對(duì)NoSQL進(jìn)行測(cè)評(píng)，NoSQL取代SQL的呼聲高漲，因?yàn)榛ヂ?lián)網(wǎng)行業(yè)使用MySQL的概率非常高，加之Oracle收購的消息，一時(shí)間似乎MySQL將成為NoSQL數(shù)據(jù)庫的犧牲品，一場(chǎng)轟轟烈烈的技術(shù)革命就要到來了。之所以有如此動(dòng)向是因?yàn)榛贛ySQL + sharding + cache的構(gòu)架隨著數(shù)據(jù)量爆炸式增長(zhǎng)，重構(gòu)的人力成本太高，換用擴(kuò)展性更好的NoSQL數(shù)據(jù)庫，以達(dá)到控制人力成本的目的，從而減少總體成本。

幾個(gè)月過去了，NoSQL并沒有像大家所想象的那樣席卷全球，很多人設(shè)想中的MySQL與NoSQL的戰(zhàn)爭(zhēng)也僅存于設(shè)想中，國內(nèi)不要說使用了，測(cè)評(píng)NoSQL的機(jī)構(gòu)也是寥寥，究其原因，筆者認(rèn)為：MySQL與NoSQL是兩種不通性質(zhì)的技術(shù)，它們代表的是兩種完全不通的技術(shù)思想，均有其適應(yīng)的土壤，究竟孰優(yōu)孰劣，取決于諸多因素，而它們是否適用的根本因素，是“人”與“物”的成本變化。

什么是NoSQL

在“NoSQL”一詞，實(shí)際上是一個(gè)叫Racker的人創(chuàng)造的，當(dāng)約翰埃文斯埃里克要組織一次活動(dòng)來討論開源的分布式數(shù)據(jù)庫。這個(gè)名稱和概念都由此而來。

有些人反對(duì)NoSQL術(shù)語，因?yàn)樗犉饋硐裎覀兌x自己是什么．在一定程度，但長(zhǎng)期仍然是有價(jià)值的，因?yàn)楫?dāng)一個(gè)關(guān)系數(shù)據(jù)庫是唯一的工具，你知道，每一個(gè)問題，看起來像一個(gè)大拇指。 NoSQL是讓人們知道有其他選擇哪里。但我們并不反對(duì)關(guān)系數(shù)據(jù)庫，因?yàn)楫?dāng)這確實(shí)是工作的最佳工具.

一個(gè)與NoSQL名稱真正關(guān)注的是，它是一個(gè)很大的帳篷，有非常不同的設(shè)計(jì)空間。如果這不是在討論清楚的，它在各種產(chǎn)品混亂的結(jié)果。因此，我要建議沿著三個(gè)軸的思考很多數(shù)據(jù)庫選項(xiàng)：可擴(kuò)展性，數(shù)據(jù)和查詢模型和持久性的設(shè)計(jì)。

前所未有的數(shù)據(jù)量正推動(dòng)企業(yè)關(guān)注傳統(tǒng)的關(guān)系數(shù)據(jù)庫技術(shù)，已服務(wù)了30多年良好替代品。總的來說，這些替代品已被稱作“NoSQL數(shù)據(jù)庫。”

最根本的問題是關(guān)系數(shù)據(jù)庫不能處理很多數(shù)據(jù)量。有三個(gè)具體的問題：擴(kuò)大向像Digg新聞評(píng)論網(wǎng)站的（3TB綠色徽章）或Facebook的（50TB收件箱中的搜索）或EBay（整體2PB），

并支持每個(gè)服務(wù)器性能和嚴(yán)格的架構(gòu)設(shè)計(jì)。

像許多關(guān)注這一領(lǐng)域的人一樣，我不喜歡從本質(zhì)上將SQL與NoSQL這一術(shù)語對(duì)立起來。同時(shí)我對(duì)該術(shù)語現(xiàn)有的解釋”Not Only SQL”也不甚滿意。對(duì)我來說，我們這里所討論的并非是是否使用SQL。(相反的是，我們?nèi)匀豢梢赃x擇類似SQL這樣的查詢接口(缺少對(duì)join等的支持)來與這些數(shù)據(jù)庫交互，使用現(xiàn)有的資源和技術(shù)來管理開發(fā)伸縮性和可維護(hù)性。) 這一運(yùn)動(dòng)是要找到存儲(chǔ)和檢索數(shù)據(jù)的其他高效的途徑，而不是盲目地在任何情況下都把關(guān)系數(shù)據(jù)庫當(dāng)作萬金油。因此，我認(rèn)為’Non Relational Database’(非關(guān)系型數(shù)據(jù)庫)能夠更好的表達(dá)這一思想。

無論采用哪個(gè)名字，“非關(guān)系型數(shù)據(jù)庫”這一范圍所傳達(dá)出來的“囊括所有”類型的意味，使得這一概念比較模糊(并且它還是否定型的)。這又使得人們(特別是企業(yè)中的決策者)對(duì)于哪些是屬于這個(gè)范圍，哪些不是，更重要的是，對(duì)他們來說這到底意味著什么，感到非常迷惑。

為了解答這些疑問，我嘗試通過以下幾點(diǎn)特征的描述，來刻畫“非關(guān)系型數(shù)據(jù)庫”的內(nèi)在本質(zhì)。

所謂“非關(guān)系型數(shù)據(jù)庫”指的是

1. 使用松耦合類型、可擴(kuò)展的數(shù)據(jù)模式來對(duì)數(shù)據(jù)進(jìn)行邏輯建模(Map，列，文檔，圖表等)，而不是使用固定的關(guān)系模式元組來構(gòu)建數(shù)據(jù)模型。
2. 以遵循于CAP定理（能保證在一致性，可用性和分區(qū)容忍性三者中中達(dá)到任意兩個(gè)）的跨多節(jié)點(diǎn)數(shù)據(jù)分布模型而設(shè)計(jì)，支持水平伸縮。這意味著對(duì)于多數(shù)據(jù)中心和動(dòng)態(tài)供應(yīng)（在生產(chǎn)集群中透明地加入/刪除節(jié)點(diǎn)）的必要支持，也即彈性(Elasticity)。
3. 擁有在磁盤或內(nèi)存中，或者在這兩者中都有的，對(duì)數(shù)據(jù)持久化的能力，有時(shí)候還可以使用可熱插拔的定制存儲(chǔ)。
4. 支持多種的’Non-SQL’接口(通常多于一種)來進(jìn)行數(shù)據(jù)訪問。

圍繞著圖中四個(gè)特征的（數(shù)據(jù)持久性、邏輯數(shù)據(jù)模型、數(shù)據(jù)分布模型和接口）“非關(guān)系型數(shù)據(jù)庫”的各種變形，在最近的一些文章中有詳盡的描述，并且在因特網(wǎng)上有著廣泛的傳播。所以我就不做過多繁復(fù)的描述，而是通過一些例子對(duì)關(guān)鍵的方向進(jìn)行總結(jié)，供快速參考：

接口——REST (HBase，CouchDB，Riak等)，MapReduce (HBase，CouchDB，MongoDB，Hypertable等)，Get/Put (Voldemort，Scalaris等)，Thrift (HBase，Hypertable，Cassandra等)，語言特定的API(MongoDB)。

邏輯數(shù)據(jù)模型——面向鍵值對(duì)的(Voldemort，Dynomite 等)，面向Column Family的(BigTable，HBase，Hypertable 等)，面向文檔的(Couch DB，MongoDB等)，面向圖的(Neo4j， Infogrid等)

數(shù)據(jù)分布模型——一致性和可用性(HBase，Hypertable， MongoDB等)， 可用性和可分區(qū)性(Cassandra等)。一致性和可分區(qū)性的組合會(huì)導(dǎo)致一些非額定的節(jié)點(diǎn)產(chǎn)生可用性的損失。有趣的是目前還沒有一個(gè)“非關(guān)系型數(shù)據(jù)庫”支持這一組合。

數(shù)據(jù)持久性——基于內(nèi)存的(如Redis，Scalaris， Terrastore)，基于磁盤的(如MongoDB，Riak等)，或內(nèi)存及磁盤二者的結(jié)合(如HBase，Hypertable，Cassandra)。存儲(chǔ)的類型有助于我們辨別該解決方案適用于哪種類型。然而，在大多數(shù)情況下人們發(fā)現(xiàn)基于組合方案的解決方案是最佳的選擇。既能通過內(nèi)存數(shù)據(jù)存儲(chǔ)支持高性能，又能在寫入足夠多的數(shù)據(jù)后存儲(chǔ)到磁盤來保證持續(xù)性。

隨著網(wǎng)站的持續(xù)發(fā)展，NOSQL成為大網(wǎng)站發(fā)展的必然性選擇

隨著數(shù)據(jù)量和訪問量的增長(zhǎng)，網(wǎng)站構(gòu)架大致有這么幾個(gè)發(fā)展階段(以PHP+MySQL+Memcached為例)：

1: PHP + MySQL
2: PHP + MySQL (Master + Slaves)
3: PHP + MySQL (Master + Slaves) + Memcached (Middleware)
4: PHP + MySQL (Sharding + Master + Slaves) + Memcached (Middleware)
5: PHP + MySQL (Sharding + Master + Slaves) + Memcached (Middleware) + NoSQL

從上面的發(fā)展歷程可以看出，隨著復(fù)雜度的增加，開發(fā)難度和復(fù)雜性也隨之提升，數(shù)據(jù)量增加之后每次重構(gòu)需要的人力成本急劇增加，因此為了控制成本，增長(zhǎng)重構(gòu)的周期，將一些數(shù)據(jù)量龐大，增長(zhǎng)快速的業(yè)務(wù)遷移至NoSQL上存儲(chǔ)。
因此大家不必要言必NoSQL，NoSQL也不會(huì)取代MySQL，不同的業(yè)務(wù)有它最適合的低成本存儲(chǔ)方式，最終選擇什么數(shù)據(jù)庫是由系統(tǒng)成本決定的。

MySQL的優(yōu)勢(shì)在此不再贅述，其最大的特點(diǎn)是盡可能的壓榨機(jī)器的性能，在上世紀(jì)末互聯(lián)網(wǎng)泡沫破滅時(shí)，壓縮成本的意識(shí)就已經(jīng)深入每一個(gè)互聯(lián)網(wǎng)公司的血液，MySQL順應(yīng)時(shí)代的需求，為幸存的互聯(lián)網(wǎng)公司盡可能的節(jié)約著每一分資金，不知有多少互聯(lián)網(wǎng)故事都有以下的開頭“XX年，幾個(gè)剛畢業(yè)的大學(xué)生用兩臺(tái)服務(wù)器創(chuàng)辦了XXX”，那時(shí)，無論是在美國，還是在中國，硬件的成本相比人力資源，都是比較高的，特別是在中國，一臺(tái)中等配置服務(wù)器的價(jià)格，幾乎相當(dāng)于一個(gè)技術(shù)新手一年甚至更多的薪水。雖然SQL型數(shù)據(jù)庫在擴(kuò)展的時(shí)候有諸多不便，業(yè)務(wù)重構(gòu)、代碼重寫、壓力測(cè)試、上線，意味著網(wǎng)站開發(fā)、運(yùn)維人員無數(shù)個(gè)不眠之夜，但人力成本較之買服務(wù)器的成本來說，可能當(dāng)時(shí)絕大部分互聯(lián)網(wǎng)公司都會(huì)選擇前者。

再看十幾年后的今天，網(wǎng)站的數(shù)據(jù)量比過去更大，用戶更多，應(yīng)用更復(fù)雜，業(yè)務(wù)的變化更加快速，人力資源的成本不斷上漲，即便是金融危機(jī)之后的美國，一個(gè)普通MySQL DBA的工資依然在十幾萬美元以上，至于高級(jí)開發(fā)，架構(gòu)師的成本更是以數(shù)十萬美元計(jì)，而硬件的成本卻大大降低，NoSQL雖然在執(zhí)行效率上遠(yuǎn)低于SQL型數(shù)據(jù)庫，但其擴(kuò)展的便利性導(dǎo)致不需要投入更多的人力來對(duì)系統(tǒng)和應(yīng)用進(jìn)行重構(gòu)與改寫，間接的降低了人員的成本，對(duì)于許多已經(jīng)有成百上千臺(tái)服務(wù)器和上百萬用戶的美國互聯(lián)網(wǎng)公司來說，節(jié)約下的人力成本，足夠買上百臺(tái)服務(wù)器來彌補(bǔ)NoSQL效率上的缺陷，這樣的好事，當(dāng)然許多公司都是希望進(jìn)行嘗試的。

如何將其與企業(yè)IT融合

如今的企業(yè)中，并非所有用例都直觀地傾向于使用關(guān)系型數(shù)據(jù)庫，或者都需要嚴(yán)格的ACID屬性(特別是一致性和隔離性)。在80年代及90年代，絕大部分存儲(chǔ)在企業(yè)數(shù)據(jù)庫里的數(shù)據(jù)都是結(jié)構(gòu)化的業(yè)務(wù)事務(wù)的“記錄”，必須用受控的方式來生成或訪問，而如今它已一去不復(fù)返了。無可爭(zhēng)辯的是，仍有這一類型的數(shù)據(jù)在那里，并將繼續(xù)也應(yīng)該通過關(guān)系型數(shù)據(jù)庫來建模，存儲(chǔ)和訪問。但對(duì)于過去15年以來，隨著Web的發(fā)展，電子商務(wù)和社交計(jì)算的興起所引起的企業(yè)里不受控的非結(jié)構(gòu)化并且面向信息的數(shù)據(jù)大爆炸，該如何應(yīng)對(duì)呢？企業(yè)確實(shí)不需要關(guān)系型數(shù)據(jù)庫來管理這些數(shù)據(jù)，因?yàn)殛P(guān)系型數(shù)據(jù)庫的特點(diǎn)決定了它不適用于這些數(shù)據(jù)的性質(zhì)和使用方式。

上圖總結(jié)了現(xiàn)今以web為中心的企業(yè)中信息管理的新興模式。而“非關(guān)系型數(shù)據(jù)庫” 是處理這些趨勢(shì)的最佳選擇(較之關(guān)系型數(shù)據(jù)庫來說)，提供了對(duì)非結(jié)構(gòu)化數(shù)據(jù)的支持，擁有支持分區(qū)的水平伸縮性，支持高可用性等等。

以下是支持這一觀點(diǎn)的一些實(shí)際應(yīng)用場(chǎng)景：

日志挖掘——集群里的多個(gè)節(jié)點(diǎn)都會(huì)產(chǎn)生服務(wù)器日志、應(yīng)用程序日志和用戶活動(dòng)日志等。對(duì)于解決生產(chǎn)環(huán)境中的問題，日志挖掘工具非常有用，它能訪問跨服務(wù)器的日志記錄，將它們關(guān)聯(lián)起來并進(jìn)行分析。使用“非關(guān)系型數(shù)據(jù)庫”來定制這樣的解決方案將會(huì)非常容易。

分析社交計(jì)算——許多企業(yè)如今都為用戶(內(nèi)部用戶、客戶和合作伙伴)提供通過消息論壇，博客等方式來進(jìn)行社交計(jì)算的能力。挖掘這些非結(jié)構(gòu)化的數(shù)據(jù)對(duì)于獲得用戶的喜好偏向以及進(jìn)一步提升服務(wù)有著至關(guān)重要的作用。使用“非關(guān)系型數(shù)據(jù)庫” 可以很好的解決這一需求。

外部數(shù)據(jù)feed聚合——許多情況下企業(yè)需要消費(fèi)來自合作伙伴的數(shù)據(jù)。顯然，就算經(jīng)過了多輪的討論和協(xié)商，企業(yè)對(duì)于來自合作伙伴的數(shù)據(jù)的格式仍然沒有發(fā)言權(quán)。同時(shí)，許多情況下，基于合作伙伴業(yè)務(wù)的變更，這些數(shù)據(jù)格式也頻繁的發(fā)生變化。通過“非關(guān)系型數(shù)據(jù)庫”來開發(fā)或定制一個(gè)ETL解決方案能夠非常成功的解決這一問題。

高容量的EAI系統(tǒng)——許多企業(yè)的EAI系統(tǒng)都有高容量傳輸流(不管是基于產(chǎn)品的還是定制開發(fā)的)。出于可靠性和審計(jì)的目的，這些通過EAI系統(tǒng)的消息流通常都需要持久化。對(duì)于這一場(chǎng)景，“非關(guān)系型數(shù)據(jù)庫” 再次體現(xiàn)出它十分適用于底層的數(shù)據(jù)存儲(chǔ)，只要能給定環(huán)境中源系統(tǒng)和目標(biāo)系統(tǒng)的數(shù)據(jù)結(jié)構(gòu)更改和所需的容量。

前端訂單處理系統(tǒng)——隨著電子商務(wù)的膨脹，通過不同渠道流經(jīng)零售商、銀行和保險(xiǎn)供應(yīng)商、娛樂服務(wù)供應(yīng)商、物流供應(yīng)商等等的訂單、應(yīng)用、服務(wù)請(qǐng)求的容量十分巨大。同時(shí)，由于不同渠道的所關(guān)聯(lián)的行為模式的限制，每種情況下系統(tǒng)所使用的信息結(jié)構(gòu)都有所差異，需要加上不同的規(guī)則類型。在此之上，絕大部分?jǐn)?shù)據(jù)不需要即時(shí)的處理和后端對(duì)帳。所需要的是，當(dāng)終端用戶想要從任何地方推送這些數(shù)據(jù)時(shí)，這些請(qǐng)求都能夠被捕獲并且不會(huì)被打斷。隨后，通常會(huì)有一個(gè)對(duì)帳系統(tǒng)將其更新到真正的后端源系統(tǒng)并更新終端用戶的訂單狀態(tài)。這又是一個(gè)可以應(yīng)用“非關(guān)系型數(shù)據(jù)庫”的場(chǎng)景，可用于初期存儲(chǔ)終端用戶的輸入。這一場(chǎng)景是體現(xiàn)“非關(guān)系型數(shù)據(jù)庫”的應(yīng)用的極佳例子，它具有高容量，異構(gòu)的輸入數(shù)據(jù)類型和對(duì)帳的”最終一致性”等等特點(diǎn)。

企業(yè)內(nèi)容管理服務(wù)——出于各種各樣的目的，內(nèi)容管理在企業(yè)內(nèi)部得到了廣泛的應(yīng)用，橫跨多個(gè)不同的功能部門比如銷售、市場(chǎng)、零售和人力資源等。企業(yè)大多數(shù)時(shí)間所面臨的挑戰(zhàn)是用一個(gè)公共的內(nèi)容管理服務(wù)平臺(tái)，將不同部門的需求整合到一起，而它們的元數(shù)據(jù)是各不相同的。這又是“非關(guān)系型數(shù)據(jù)庫”發(fā)揮作用的地方。

合并和收購——企業(yè)在合并與收購中面臨巨大的挑戰(zhàn)，因?yàn)樗麄冃枰獙⑦m應(yīng)于相同功能的系統(tǒng)整合起來。“非關(guān)系型數(shù)據(jù)庫” 可解決這一問題，不管是快速地組成一個(gè)臨時(shí)的公共數(shù)據(jù)存儲(chǔ)，或者是架構(gòu)一個(gè)未來的數(shù)據(jù)存儲(chǔ)來調(diào)和合并的公司之間現(xiàn)有公共應(yīng)用程序的結(jié)構(gòu)。

但我們?nèi)绾尾拍軠?zhǔn)確的描述，相對(duì)于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫，企業(yè)使用“非關(guān)系型數(shù)據(jù)庫”帶來的好處呢？下面是可通過非關(guān)系型數(shù)據(jù)庫的核心特點(diǎn)(正如上一節(jié)所討論的)而獲得的一些主要的好處，即企業(yè)的任何IT決策都會(huì)參考的核心參數(shù)——成本削減，更好的周轉(zhuǎn)時(shí)間和更優(yōu)良的質(zhì)量。

業(yè)務(wù)靈活性——更短的周轉(zhuǎn)時(shí)間

“非關(guān)系型數(shù)據(jù)庫”能夠以兩種基本的方式帶來業(yè)務(wù)靈活性。

• 模式自由的邏輯數(shù)據(jù)模型有助于在為任何業(yè)務(wù)進(jìn)行調(diào)整時(shí)帶來更快的周轉(zhuǎn)時(shí)間，把對(duì)現(xiàn)有應(yīng)用和功能造成影響減到最少。在大多數(shù)情況下因任意的變更而給你帶來的遷移工作幾乎為零。
• 水平伸縮性能夠在當(dāng)越來越多的用戶負(fù)載造成負(fù)載周期性變化，或者應(yīng)用突然變更的使用模式時(shí)，提供堅(jiān)固的保障。面向水平伸縮性的架構(gòu)也是邁向基于SLA構(gòu)建(例如云)的第一步，這樣才能保證在不斷變化的使用情形下業(yè)務(wù)的延續(xù)性。

更佳的終端用戶體驗(yàn)——更優(yōu)越的質(zhì)量

在現(xiàn)今企業(yè)IT中，應(yīng)用的質(zhì)量主要由終端用戶的滿意度來決定。“非關(guān)系型數(shù)據(jù)庫”通過解決如下終端用戶的考慮因素，能夠達(dá)到同樣的效果，而這些因素也是最容易發(fā)生和最難以處理的。

• “非關(guān)系型數(shù)據(jù)庫” 為提升應(yīng)用的性能帶來了極大的機(jī)會(huì)。分布式數(shù)據(jù)的核心概念是保證磁盤I/O(尋道速率)絕不能成為應(yīng)用性能的瓶頸。盡管性能更多的是由傳輸速率來決定。在此之上，絕大部分解決方案支持各種不同的新一代的高速計(jì)算的范式，比如MapReduce，排序列，Bloom Filter，僅可追加的B樹，Memtable等。
• 現(xiàn)今用戶滿意度的另一個(gè)重要的方面就是可靠性。終端用戶希望在想要訪問應(yīng)用時(shí)就能訪問到，并且至少是在當(dāng)他們分配到時(shí)間的時(shí)候能隨時(shí)執(zhí)行他們的任務(wù)。所以不可用的應(yīng)用需要不惜代價(jià)的避免。許多現(xiàn)代的“非關(guān)系型數(shù)據(jù)庫”都能適應(yīng)并支持這一類有著嚴(yán)格和最終一致性的可用性的需求。

更低的所有者總成本

在如今的競(jìng)爭(zhēng)市場(chǎng)中，企業(yè)IT支出隨時(shí)都要仔細(xì)審查，以合理的成本獲取合理的質(zhì)量才值得贊許。在這一領(lǐng)域中“非關(guān)系型數(shù)據(jù)庫”在一定程度上勝于傳統(tǒng)的數(shù)據(jù)庫，特別是當(dāng)存儲(chǔ)和處理的數(shù)據(jù)容量很大時(shí)。

• 水平伸縮性的基本前提保證了它們可以運(yùn)行于廉價(jià)機(jī)器之上。這不僅削減了硬件資本的成本，同時(shí)還削減了諸如電力，維護(hù)等運(yùn)維成本。同時(shí)這還進(jìn)一步的為利用諸如云、虛擬數(shù)據(jù)中心等下一代低成本的基礎(chǔ)設(shè)施打下了基礎(chǔ)。
• 從長(zhǎng)期來看，更少的維護(hù)能帶來更多的運(yùn)維成本優(yōu)勢(shì)。對(duì)于關(guān)系型數(shù)據(jù)庫，這絕對(duì)是一個(gè)需要存儲(chǔ)大容量數(shù)據(jù)的場(chǎng)景。為大容量的數(shù)據(jù)調(diào)優(yōu)數(shù)據(jù)庫需要高超的技藝，也就意味著更高的成本。相較之下，“非關(guān)系型數(shù)據(jù)庫”始終提供快速和響應(yīng)的特點(diǎn)，就算是在數(shù)據(jù)大幅上升的情況下。索引和緩存也以同樣的方式工作。開發(fā)者不必過多擔(dān)心硬件、磁盤、重新索引及文件布局等，而是把更多的精力投入了應(yīng)用程序的開發(fā)上。

企業(yè)采用中所面臨的挑戰(zhàn)

拋開所有這些長(zhǎng)遠(yuǎn)的好處，在企業(yè)擁抱“非關(guān)系型數(shù)據(jù)庫”之前，當(dāng)然還需要經(jīng)歷各種各樣的挑戰(zhàn)。

不考慮因現(xiàn)有思想的轉(zhuǎn)換和缺乏信心而產(chǎn)生的來自高層的阻力，目前我認(rèn)為的最主要的戰(zhàn)術(shù)性挑戰(zhàn)是：

為“非關(guān)系型數(shù)據(jù)庫”認(rèn)定正確的應(yīng)用/使用場(chǎng)景

盡管從理論上容易論證并非所有的企業(yè)數(shù)據(jù)都需要基于關(guān)系和ACID的系統(tǒng)，然而由于關(guān)系型數(shù)據(jù)庫與企業(yè)數(shù)據(jù)間多年的綁定關(guān)系，要作出所有的數(shù)據(jù)可以通過非關(guān)系的解決方案而解耦的決定仍然有很多困難。許多時(shí)候IT經(jīng)理(以及其它對(duì)于應(yīng)用程序負(fù)有核心的底線責(zé)任的各級(jí)人員)不明白他們將會(huì)失去什么，這樣的擔(dān)憂對(duì)于從關(guān)系型數(shù)據(jù)庫轉(zhuǎn)變出來比較不利。企業(yè)IT最有價(jià)值的資產(chǎn)就是數(shù)據(jù)。因此，要作出決定使用一種不太明確或者未被廣泛采用的解決方案來管理同樣的數(shù)據(jù)，這種能力不僅需要轉(zhuǎn)換思維方式，同時(shí)還需要來自高層的強(qiáng)大的支持(和推動(dòng))。

我們?nèi)绾芜x擇最適合我們的產(chǎn)品/解決方案

另一個(gè)重大的挑戰(zhàn)是找出合適的產(chǎn)品/工具來提供“非關(guān)系型數(shù)據(jù)庫”。正如前面所提到的那樣，現(xiàn)今業(yè)界里面有多于25種不同的產(chǎn)品和解決方案，它們?cè)谒膫€(gè)方面有著不同的特點(diǎn)。正因?yàn)槊總€(gè)產(chǎn)品在這四個(gè)方面特點(diǎn)各異，所以要選擇一個(gè)產(chǎn)品來應(yīng)對(duì)所有的需求顯得尤為困難。有的時(shí)候，可能在企業(yè)的不同部門使用到多種類型的非關(guān)系型數(shù)據(jù)庫，最后人們可能會(huì)完全出于對(duì)標(biāo)準(zhǔn)的需要而轉(zhuǎn)向關(guān)系型數(shù)據(jù)庫。

如何獲得規(guī)模經(jīng)濟(jì)

這一想法本質(zhì)上是從前一個(gè)問題分支出來的。如果一個(gè)組織需要使用多個(gè)非關(guān)系型數(shù)據(jù)庫解決方案(由于單個(gè)方案的適用問題)，那么保證在技術(shù)(開發(fā)者，管理者，支持人員)，基礎(chǔ)設(shè)施(硬件成本，軟件許可成本，支持成本，咨詢成本)，以及工件(公共組件和服務(wù))方面的規(guī)模經(jīng)濟(jì)就是一個(gè)大問題。這一方面與傳統(tǒng)的關(guān)系型數(shù)據(jù)庫解決方案比較起來確實(shí)更為嚴(yán)峻，因?yàn)榇蟛糠謺r(shí)間組織的數(shù)據(jù)存儲(chǔ)都是以共享服務(wù)的模式在運(yùn)行的。

我們?nèi)绾伪ＷC解決方案的可移植性

從“非關(guān)系型數(shù)據(jù)庫”的發(fā)展來看，我們可以很直觀地推測(cè)在未來的幾年中這一領(lǐng)域會(huì)有許多變化，比如供應(yīng)商的合并，功能的進(jìn)步以及標(biāo)準(zhǔn)化。所以對(duì)于企業(yè)來說一個(gè)更好的策略是不要把寶押在某個(gè)特定的產(chǎn)品/解決方案上，以后才可以更靈活的轉(zhuǎn)換到一個(gè)更好的經(jīng)過考驗(yàn)的產(chǎn)品。 由于現(xiàn)在的非關(guān)系型產(chǎn)品/解決方案大部分是私有的，因此IT決策者在考慮嘗試“非關(guān)系型數(shù)據(jù)庫”之前，不得不認(rèn)真考慮可移植性這一重要的問題。這純粹是出于保護(hù)現(xiàn)有投資的需要。

我們?nèi)绾潍@得合適的產(chǎn)品支持類型

現(xiàn)在的“非關(guān)系型數(shù)據(jù)庫”能通過外部組織而提供支持方案的少之又少。就算有，也無法與Oracle，IBM或者微軟等相比。特別是在數(shù)據(jù)恢復(fù)，備份和特定的數(shù)據(jù)恢復(fù)方面，由于許多“非關(guān)系型數(shù)據(jù)庫”在這些方面未能提供一個(gè)健壯而易于使用的機(jī)制，對(duì)于企業(yè)決策者來說，仍存在很大的問題。

我們?nèi)绾晤A(yù)算整體成本

與重量級(jí)的關(guān)系型數(shù)據(jù)庫相比，“非關(guān)系型數(shù)據(jù)庫”通常在性能和伸縮性特征方面能提供的數(shù)據(jù)更少。我也沒有發(fā)現(xiàn)有TPC基準(zhǔn)程序方面和類似的其它方面的數(shù)據(jù)。這將企業(yè)決策者置于了一個(gè)“沒有方向”的情況下，因?yàn)樗麄儾恢佬枰谟布?、軟件許可、基礎(chǔ)設(shè)施管理和支持等方面支出多大的費(fèi)用。要得出一個(gè)預(yù)算估計(jì)，缺乏判斷的數(shù)據(jù)就成了一個(gè)主要的障礙。因此在項(xiàng)目啟動(dòng)階段，大部分情況下決策者還是會(huì)選擇基于熟悉的關(guān)系型數(shù)據(jù)庫的解決方案。

有時(shí)候，就算可以得到這些數(shù)字，但也不足以用來形成TCO模型并與傳統(tǒng)的基于關(guān)系型數(shù)據(jù)庫的數(shù)據(jù)存儲(chǔ)和非關(guān)系型數(shù)據(jù)存儲(chǔ)進(jìn)行整體的成本分析(Capex+Opex)比較。通常情況下水平伸縮性所要求的大量的硬件機(jī)器(以及軟件許可成本，支持成本)，如果與垂直伸縮性乍一比較，會(huì)讓人覺得戰(zhàn)戰(zhàn)兢兢，除非由此帶來的好處經(jīng)過基于TCO模型的全方位比較仍然被證明是可以持續(xù)的。

關(guān)于如何采用NoSQL的兩點(diǎn)思考

這是否意味著目前來看企業(yè)應(yīng)該對(duì)NoSQL運(yùn)動(dòng)持觀望的態(tài)度呢？并非如此。誠然，“非關(guān)系型數(shù)據(jù)庫”對(duì)于廣泛的采用來說還未到完全成熟的階段。但“非關(guān)系型數(shù)據(jù)庫”作為未來企業(yè)骨架的潛力仍不能忽視。特別是不遠(yuǎn)的將來企業(yè)將更多地處理大容量的半結(jié)構(gòu)化/非結(jié)構(gòu)化以及最終一致性的數(shù)據(jù)，而不是相對(duì)而言小容量的，嚴(yán)格結(jié)構(gòu)化的遵循ACID的數(shù)據(jù)。 所以現(xiàn)在而言至關(guān)重要的是做企業(yè)的關(guān)鍵決策人的思想工作，讓他們明白企業(yè)的數(shù)據(jù)處理需要使用“非關(guān)系型數(shù)據(jù)庫”。在這一過程中，要采取一些漸進(jìn)的步驟把“非關(guān)系型數(shù)據(jù)庫”應(yīng)用到企業(yè)IT的一些關(guān)鍵的方面(技術(shù)，人員和流程)，并產(chǎn)生一定的價(jià)值。這樣，就可以用一種緩慢而穩(wěn)健的方式從整體上來解決我們之前所總結(jié)出來的一系列問題。

采用一個(gè)產(chǎn)品/解決方案

如今市場(chǎng)上的選擇非常多樣化，可根據(jù)“非關(guān)系型數(shù)據(jù)庫”側(cè)重的面不同而進(jìn)行差異化的處理。與此同時(shí)，企業(yè)應(yīng)用場(chǎng)景可能需要不同類型的特點(diǎn)。然而以不同的解決方案來處理不同的應(yīng)用/使用場(chǎng)景從規(guī)模經(jīng)濟(jì)的角度出發(fā)對(duì)于企業(yè)是不適宜的。因此最好是根據(jù)目標(biāo)應(yīng)用的需要最終落實(shí)到某一個(gè)具體的產(chǎn)品/解決方案上。需要注意的是大多數(shù)的解決方案在特性上都會(huì)有一些折中，有些特性可能在其它的產(chǎn)品中可以獲得，有些可能只是在發(fā)展路線圖當(dāng)中暫時(shí)設(shè)定了一個(gè)位置。因?yàn)榇蟛糠值漠a(chǎn)品會(huì)在不久的將來不斷趨于成熟，因此可以通過不同配置來提供不同的解決方案。所以只要現(xiàn)有的解決方案能適合目前大部分的需要，不妨作為一個(gè)起點(diǎn)將其采納。

選擇產(chǎn)品/解決方案的經(jīng)驗(yàn)法則

• 支持所需要的邏輯數(shù)據(jù)模型應(yīng)當(dāng)被給予更高的權(quán)重。這將從實(shí)質(zhì)上決定該解決方案在當(dāng)前或未來能否靈活地適應(yīng)不同的業(yè)務(wù)需求。
• 調(diào)查該產(chǎn)品所支持的物理數(shù)據(jù)模型的合適與否，據(jù)此對(duì)這一解決方案所需要的水平伸縮性、可靠性、一致性和分區(qū)性作出合理的評(píng)估。這同樣能表明備份和恢復(fù)機(jī)制的可能性。
• 接口支持需要與企業(yè)標(biāo)準(zhǔn)的運(yùn)行環(huán)境對(duì)齊。由于這些產(chǎn)品支持多樣的接口，所以這一點(diǎn)可以得到很好的處理。
• 只要產(chǎn)品支持水平伸縮性，對(duì)于持久化模型的選擇就不再重要了。

這里有一份一系列“非關(guān)系型數(shù)據(jù)庫”的對(duì)照表。對(duì)于現(xiàn)在正認(rèn)真考慮采用的企業(yè)來說，這是一個(gè)不錯(cuò)的起點(diǎn)。為了更貼近企業(yè)本身的情況，從25+的集合中挑選出的子集所用到的的關(guān)鍵選擇標(biāo)準(zhǔn)是：

1. 最重要的一點(diǎn)首先是企業(yè)應(yīng)用程序必須支持有一定復(fù)雜程度的數(shù)據(jù)結(jié)構(gòu)。否則的話，應(yīng)用程序管理復(fù)雜性的責(zé)任將變得非常大。我認(rèn)為比較合理的應(yīng)當(dāng)是介于純粹的鍵值對(duì)與關(guān)系型模式中間的一種方案。出于這方面的考慮像Vlodemort，Tokyo Cabinet等產(chǎn)品就排除在了我的列表之外。
2. 第二點(diǎn)是以低成本的分片/分區(qū)為大容量數(shù)據(jù)提供水平支持。缺乏這樣的支持就使得解決方案與任何關(guān)系型數(shù)據(jù)庫無異了。因此像Neo4J(盡管他有豐富的基于圖的模型)，Redis，CouchDB等此時(shí)此刻就被過濾出我的列表之外了。
3. 最后一條評(píng)判標(biāo)準(zhǔn)，在企業(yè)級(jí)推廣之前我會(huì)考慮一定程度的商業(yè)支持。否則的話，一旦出現(xiàn)生產(chǎn)環(huán)境的問題，我該去找誰呢？出于這一點(diǎn)，我不得不將現(xiàn)在的一些明星產(chǎn)品排除在外，比如Cassandra(盡管有很大的可能不久的將來Rackspace或者Cloudera就會(huì)對(duì)其提供支持，因?yàn)樗呀?jīng)被用于一些生產(chǎn)環(huán)境里邊了，比如Twitter，Digg，F(xiàn)acebook)。

有了這些過濾標(biāo)準(zhǔn)，我可以精簡(jiǎn)這一列表，符合目前企業(yè)可用的產(chǎn)品有 MongoDB (下一版本就會(huì)提供shards支持)，Riak，Hypertable和HBase。下面這個(gè)表格中總結(jié)了這四個(gè)產(chǎn)品的主要特性。一個(gè)企業(yè)可以基于自己具體的實(shí)際情況從中作出選擇，找到最適合自己需要的特性。

數(shù)據(jù)訪問抽象

為數(shù)據(jù)訪問創(chuàng)建一個(gè)單獨(dú)的抽象層對(duì)于“非關(guān)系型數(shù)據(jù)庫”來說是必須的。它可以帶來多方面的好處。首先，應(yīng)用開發(fā)者可以與底層解決方案的細(xì)節(jié)完全隔離開來。這對(duì)于技術(shù)方面的伸縮性帶來了好處。同時(shí)未來如果需要更改底層的解決方案也很方便。這也以一個(gè)標(biāo)準(zhǔn)的方式滿足了多個(gè)應(yīng)用的要求(即去掉了Join，Group by等復(fù)雜特性的SQL)。

為性能和伸縮性創(chuàng)建模型

不管選擇怎樣的解決方案，使用標(biāo)準(zhǔn)技術(shù)(比如排隊(duì)網(wǎng)絡(luò)模型，分層排隊(duì)網(wǎng)絡(luò)等)來對(duì)性能和伸縮性進(jìn)行建模都是高度推薦的。它能夠?yàn)榛镜姆?wù)器規(guī)劃、拓?fù)湟约罢w的軟件許可證成本，管理運(yùn)行等提供必要的數(shù)據(jù)。這將實(shí)質(zhì)上成為所有預(yù)算計(jì)劃的主要參考數(shù)據(jù)，并對(duì)作出決策提供幫助。

構(gòu)建顯式的冗余

要防止數(shù)據(jù)丟失，除了將數(shù)據(jù)復(fù)制到備份服務(wù)器上，沒有其它的辦法了。盡管許多非關(guān)系型數(shù)據(jù)庫提供自動(dòng)復(fù)制功能，但仍然存在主節(jié)點(diǎn)單點(diǎn)失效的風(fēng)險(xiǎn)。因此最好是使用次節(jié)點(diǎn)備份，并準(zhǔn)備好用于數(shù)據(jù)恢復(fù)和自動(dòng)數(shù)據(jù)修復(fù)的腳本。出于這樣的目的，應(yīng)當(dāng)充分的了解目標(biāo)解決方案的物理數(shù)據(jù)模型，找出可能的恢復(fù)機(jī)制備選方案，基于企業(yè)的整體需求和實(shí)踐來對(duì)這些選項(xiàng)作出評(píng)估。

構(gòu)建公共數(shù)據(jù)服務(wù)平臺(tái)

就像公共共享服務(wù)的關(guān)系型數(shù)據(jù)庫一樣，也可以構(gòu)建非關(guān)系型數(shù)據(jù)庫的公共數(shù)據(jù)服務(wù)來促進(jìn)規(guī)模經(jīng)濟(jì)效應(yīng)，滿足基礎(chǔ)設(shè)施和支持的需要。這對(duì)于未來進(jìn)一步演化和更改也有幫助。這可以作為愿望列表上的最終目標(biāo)，通過中期或長(zhǎng)期的努力來達(dá)到這一成熟水平。然而，初始階段就設(shè)立這樣的遠(yuǎn)景有助于在整個(gè)過程中作出正確的決策。

壯大企業(yè)的技術(shù)力量

每個(gè)組織都有一部分人對(duì)于學(xué)習(xí)新生的和非傳統(tǒng)的事物充滿熱忱。成立這樣的小組，并挑選人員(全職的或兼職的)，密切關(guān)注這方面的動(dòng)向，了解問題和挑戰(zhàn)，進(jìn)行前瞻性的思考，能夠?yàn)槭褂眠@些技術(shù)的項(xiàng)目提供方向和幫助。同時(shí)，這個(gè)小組還可以為決策者澄清炒作的疑云，提供來自真實(shí)數(shù)據(jù)的觀點(diǎn)。

建立與產(chǎn)品社區(qū)的關(guān)系

選擇了產(chǎn)品之后，與產(chǎn)品社區(qū)建立起良好的關(guān)系對(duì)于雙方的成功都有極大的好處。許多非關(guān)系型數(shù)據(jù)庫目前都有十分活躍的社區(qū)，非常愿意相互幫助。企業(yè)與社區(qū)之間的良好合作能給大家?guī)硪粋€(gè)雙贏的局面。 如能提前對(duì)問題和解決方案有了解，那么企業(yè)在對(duì)某些特性或版本作出決策時(shí)就能成竹在胸。反過來，企業(yè)又能對(duì)產(chǎn)品特性的路線圖產(chǎn)生影響作用，這對(duì)他們自身和社區(qū)都是有利的。另一方面，社區(qū)也能從實(shí)際層次的問題中得到反饋，從而豐富和完善產(chǎn)品。來自大型企業(yè)的成功案例同樣能讓他們處于領(lǐng)先。

迭代前進(jìn)

考慮到非關(guān)系型數(shù)據(jù)庫相對(duì)的成熟度，風(fēng)險(xiǎn)最小的采用策略就是遵循迭代開發(fā)的方法論。構(gòu)建公共數(shù)據(jù)服務(wù)平臺(tái)和標(biāo)準(zhǔn)化數(shù)據(jù)訪問抽象不可能是一蹴而就的。相反，通過迭代和面向重構(gòu)的方式能更好的達(dá)到目標(biāo)。運(yùn)用不太成熟的技術(shù)進(jìn)行轉(zhuǎn)型的過程，中途改變解決方案也不會(huì)太意外的。與此同時(shí)，采用敏捷的方式來看待事物，能夠幫助建立起一個(gè)能從管理和實(shí)現(xiàn)兩方面不斷吸引改進(jìn)的開放態(tài)度。

然而，在這一問題上實(shí)現(xiàn)迭代，非常重要的一點(diǎn)是定義一個(gè)決策條件矩陣。比如操作指南(和例子)，來判斷一個(gè)應(yīng)用的對(duì)象模型是否適合關(guān)系型或非關(guān)系的范圍，對(duì)基礎(chǔ)設(shè)施規(guī)劃作出指導(dǎo)，列出必需的測(cè)試用例等等。

一個(gè)簡(jiǎn)單的NoSQL實(shí)例

NoSQL的好處是可伸縮性

即對(duì)數(shù)據(jù)庫規(guī)模的擴(kuò)大以支持并發(fā)讀取與復(fù)制更容易，比如到多臺(tái)機(jī)器自動(dòng)分區(qū)的數(shù)據(jù)，是一種“分布式數(shù)據(jù)庫。”這其中包括Cassandra，HBase，Riak，Scalaris，Voldemort，等等。如果你不想手動(dòng)分區(qū)管理并且如果你寫卷或數(shù)據(jù)容量超過一臺(tái)機(jī)器可處理，那么這些是你的唯一選擇。

有兩件事情看在分布式數(shù)據(jù)庫：1）支持多種數(shù)據(jù)中心和2）能夠添加新的機(jī)器現(xiàn)場(chǎng)集群的應(yīng)用程序的透明。

企業(yè)的非關(guān)系型數(shù)據(jù)庫采用過程中最大的挑戰(zhàn)就是轉(zhuǎn)變決策者的思想觀念——讓他們相信并非所有的數(shù)據(jù)/對(duì)象都適合關(guān)系型數(shù)據(jù)庫。 最能證明這一點(diǎn)就是選擇合適的用例去嘗試非關(guān)系型數(shù)據(jù)庫，進(jìn)而證實(shí)在合適的背景下，非關(guān)系型數(shù)據(jù)庫是比關(guān)系型數(shù)據(jù)庫更有效的解決方案。 找到一些“非關(guān)鍵業(yè)務(wù)”(但能立竿見影的)適合于非關(guān)系型數(shù)據(jù)庫的項(xiàng)目。這些項(xiàng)目的成功(甚至失敗)都能有助于觀念的改變。這也能有助于不斷學(xué)習(xí)如何才能以一種不同的方式來更好的采用非關(guān)系型數(shù)據(jù)庫。這些少兒學(xué)步般的嘗試所作出的努力與投入都是值得的，如果企業(yè)想要在將來使用“非關(guān)系型數(shù)據(jù)庫”來重塑其信息管理體系的話。

我選擇了一些作為NoSQL數(shù)據(jù)庫的例子

NoSQL數(shù)據(jù)庫使用

1． NoSQL數(shù)據(jù)和查詢模型

非分布式NoSQL數(shù)據(jù)庫包括CouchDB，MongoDB，Neo4j，Redis，和Tokyo Cabinet。這些可以作為分布式系統(tǒng)持久層; MongoDB提供有限的共享支持，做了單獨(dú)的休息室為CouchDB項(xiàng)目，和Tokyo Cabinet可作為Voldemort存儲(chǔ)引擎使用。

數(shù)據(jù)和查詢模型

在NoSQL里有很多不同的數(shù)據(jù)模型和數(shù)據(jù)庫的查詢API.

一些重點(diǎn)：

該columnfamily模型Cassandra共享和HBase的是由谷歌的Bigtable文件，第2節(jié)描述的啟發(fā)。 （Cassandra下降，歷史版本，并添加超級(jí)列。）在這兩個(gè)系統(tǒng)，你必須像你行和列習(xí)以為常，但稀疏行：每一行可以有許多或盡可能少列的需要，以及列不必須提前定義。

鍵/值模型是最簡(jiǎn)單和最容易實(shí)現(xiàn)的，但效率低，只有當(dāng)你在查詢或更新的值的一部分感興趣。這也是難以執(zhí)行的分布式圈頂更復(fù)雜的結(jié)構(gòu)/價(jià)值。

文檔數(shù)據(jù)庫基本上是下一階段重點(diǎn)/值，允許嵌套的值與每個(gè)鍵關(guān)聯(lián)。文件數(shù)據(jù)庫支持查詢的效率比每次返回了整個(gè)BLOB更簡(jiǎn)單。

Neo4J有一個(gè)真正獨(dú)特的數(shù)據(jù)模型，對(duì)象存儲(chǔ)在圖和節(jié)點(diǎn)和邊的關(guān)系。對(duì)于查詢適合這個(gè)模型（例如，分層數(shù)據(jù)），它們可以是1000倍速度比替代品。

Scalaris是獨(dú)特的，提供跨多個(gè)鍵分布式事務(wù)。 （討論與貿(mào)易之間的一致性和可用性權(quán)衡超出了這個(gè)職位的范圍，但另一個(gè)方面就是要牢記在評(píng)價(jià)分布式系統(tǒng)。）

持久性設(shè)計(jì)

通過持續(xù)的設(shè)計(jì)，“如何在內(nèi)部存儲(chǔ)的數(shù)據(jù)？” 持久性模型告訴我們很多這些數(shù)據(jù)庫能夠善于什么樣的工作量.

在內(nèi)存數(shù)據(jù)庫是非常，非常快的（Redis達(dá)到每秒超過100,000操作一臺(tái)計(jì)算機(jī)上），但不能與數(shù)據(jù)集的工作，超出可用的RAM。耐久性（保留數(shù)據(jù)，即使服務(wù)器崩潰或斷電）也將是一個(gè)問題的數(shù)據(jù)量，可以預(yù)期損失之間的沖（復(fù)制數(shù)據(jù)到磁盤）可能非常大。 Scalaris，其他內(nèi)存數(shù)據(jù)庫，我們的名單上，意向處理與復(fù)制耐久性問題，但由于它不支持多個(gè)數(shù)據(jù)中心的數(shù)據(jù)將仍然容易受到停電的事情一樣。

Memtables和SSTables緩存在內(nèi)存中寫入（1“memtable”）后，以書面追加只承諾為耐久性日志。當(dāng)寫夠已被接受的memtable排序并寫入到磁盤上的所有一次作為“sstable。”這提供近內(nèi)存中的表現(xiàn)，因?yàn)闆]有涉及要求，同時(shí)避免了純粹的耐久性問題，在內(nèi)存的方法。 （這是詳細(xì)描述在第5.3和先前提及的5.4 Bigtable的文件，以及在該日志結(jié)構(gòu)合并樹。）

B-樹已被用于從數(shù)據(jù)庫中實(shí)際上是時(shí)間的起點(diǎn)。索引他們提供強(qiáng)大的支持，但表現(xiàn)欠佳的旋轉(zhuǎn)盤（這仍然是迄今為止最具有成本效益，因?yàn)槎啵┮笞x或?qū)懯裁垂ぷ鳌?/p>

一個(gè)有趣的變體是CouchDB的追加，只有B -樹，它避免了管理費(fèi)用的目的在限制CouchDB一寫一時(shí)間成本.

本文來自網(wǎng)絡(luò)上的內(nèi)容整合。