請(qǐng)不要誤會(huì)。我們目前仍然在不斷地嘗試創(chuàng)建一個(gè)簡單的數(shù)據(jù)存儲(chǔ)機(jī)制，也仍然在挖掘MongoDB、CouchDB、Cassandra、Riak和其他NoSQL數(shù)據(jù)庫的深層次價(jià)值。我們?nèi)匀辉谝?guī)劃將最重要的數(shù)據(jù)存儲(chǔ)在NoSQL數(shù)據(jù)庫中，因?yàn)樗鼈冋谌找鎻?qiáng)大，也越來越經(jīng)得起考驗(yàn)。

    不過，我們也開始察覺到了一些問題，NoSQL似乎沒有我們想象中的那么完美，它們甚至經(jīng)常令人感到惱火。明智的開發(fā)者明白這一切只是剛剛開始。

    他們沒有扔掉SQL操作手冊(cè)，也沒有中斷與他們?cè)?jīng)信任的SQL數(shù)據(jù)庫供應(yīng)商之間的聯(lián)系。他們將NoSQL理解為“Not Only SQL”。

    以下是NoSQL目前面臨問題的列表，這些問題或大或小。我們這樣做的目的是向公眾展現(xiàn)實(shí)際的情況并澄清事實(shí)。

    只有坦然面對(duì)這些問題，才能夠更好地理解NoSQL的優(yōu)勢與不足。

    真相1：一致性困擾

    人們對(duì)SQL系統(tǒng)的一個(gè)不滿意地方，是在兩個(gè)表單間執(zhí)行一個(gè)連接（JOIN）所需的計(jì)算成本。其理念是在一個(gè)，即唯一的一個(gè)地方存儲(chǔ)數(shù)據(jù)。如果你保存一個(gè)客戶名單，將他們的住址保存在一張表單上，而在其他的每一張表單上使用客戶的ID。當(dāng)你拖動(dòng)數(shù)據(jù)時(shí)，JOIN將所有ID與住址連接在一起，讓所有的數(shù)據(jù)保持一致性。

    問題是JOIN非常昂貴，一些DBA（數(shù)據(jù)庫管理員）使用極為復(fù)雜的JOIN命令，它們能讓最好的硬件也會(huì)變成垃圾。NoSQL開發(fā)者是這么解決JOIN不足的：讓我們將客戶的地址像其他所有的東西一樣都存儲(chǔ)在相同的表單上。NoSQL的做法是存儲(chǔ)與每個(gè)人配對(duì)的鍵值，在需要時(shí)，你可以檢索到它們。

    不幸的是，希望讓自己的表單保持一致的人們?nèi)匀恍枰狫OIN。一旦開始存儲(chǔ)客戶的地址，你需要經(jīng)常將這些地址的多個(gè)拷貝保存在每張表單中。你擁有多個(gè)拷貝，并且需要同時(shí)升級(jí)它們。如果你沒有這么做，那么NoSQL將不會(huì)幫你進(jìn)行事務(wù)處理。

    真相2：事務(wù)處理復(fù)雜性

    如果說你能夠習(xí)慣沒有JOIN的表單，那是因?yàn)槟阆Ｍ@得更高的速度。這種取舍還是可以接受的。有時(shí)候，SQL的DBA就是出于這種原因才使用非規(guī)范化表單的，問題是NoSQL難以保持各種條目的一致性。很多時(shí)候，沒有一個(gè)事務(wù)處理可以確保能同時(shí)對(duì)多個(gè)表單做出調(diào)整。出于這種原因，你只有依靠自己，一個(gè)崩潰將會(huì)導(dǎo)致表單變得前后矛盾。

    最早的NoSQL部署無視這些交易。除非沒有設(shè)定一致性，否則它們將提供保持一致性的數(shù)據(jù)列表。換句話說，他們追求的是最低價(jià)值的數(shù)據(jù)。在這種情下，錯(cuò)誤不會(huì)導(dǎo)致任何重大差異。

    真相3：靈活性怪圈

    許多NoSQL程序員喜歡吹噓他們的代碼如何簡潔，工作機(jī)制運(yùn)行的速度有多快，等等。當(dāng)任務(wù)像NoSQL那樣簡單時(shí)，通常他們的說法是對(duì)的，但是當(dāng)問題復(fù)雜之后，情況就改變了。

    我們應(yīng)該考慮到JOIN的挑戰(zhàn)。一旦NoSQL程序員開始在他們自己的邏輯中加入自己的JOIN命令，他們就會(huì)開始嘗試更為有效地做這項(xiàng)工作。SQL數(shù)據(jù)庫開發(fā)者花了數(shù)十年的時(shí)間開發(fā)出巧妙的引擎，以便讓JOIN命令盡可能地高效化。

    一個(gè)SQL數(shù)據(jù)庫開發(fā)者告訴我，他正在嘗試讓自己的代碼與硬盤轉(zhuǎn)速同步。這樣一來，他就能夠僅在磁頭處于正確位置時(shí)請(qǐng)求數(shù)據(jù)。這看起來有些極端，但是SQL數(shù)據(jù)庫開發(fā)者為此已經(jīng)努力了十余年的時(shí)間。

    毫無疑問，程序員們已經(jīng)絞盡腦汁組織他們的SQL查詢，以便利用所有的潛在優(yōu)勢。其中的過程可能很艱辛，但是當(dāng)程序員找到了解決辦法，這些數(shù)據(jù)庫就能夠真正煥發(fā)出活力。

    真相4：訪問模式過多

    在理論上，SQL被認(rèn)為是一種標(biāo)準(zhǔn)的語言。如果你在一個(gè)數(shù)據(jù)庫中使用SQL，你應(yīng)該能夠在另外一個(gè)兼容版本中執(zhí)行相同的查詢。這一說法可能僅對(duì)一些簡單的查詢有效，但是每個(gè)DBA都清楚，他們需要花上數(shù)年時(shí)間才能掌握不同版本數(shù)據(jù)庫的SQL的特點(diǎn)。關(guān)鍵詞被重新定義，在一個(gè)版本中正常運(yùn)行的查詢，在另一個(gè)版本中可能就無法正常運(yùn)行。

    NoSQL更為神秘莫測，它們就如同通天塔一樣。從一開始，NoSQL開發(fā)者就在竭盡全力地想要設(shè)計(jì)出最佳語言，但是他們的設(shè)想有著很大的差別。起初實(shí)驗(yàn)效果還是不錯(cuò)的，但是當(dāng)你嘗試在工具間切換時(shí)，情況就變了。CouchDB查詢被表述為用于映射與約簡的JavaScript功能。Cassandra早期版本使用了一個(gè)原始而低級(jí)的API（應(yīng)用編程接口），即Thrift。新版本推出了CQL，一種與SQL類似的查詢語言，它必須要被服務(wù)器所解析和理解。每一個(gè)產(chǎn)品的設(shè)計(jì)原理都不盡相同。

    真相5：綱要靈活性存在問題

    NoSQL的一個(gè)重要理念是不需要綱要。換句話說，程序員不需要提前決定表單中的每一個(gè)行需要使用哪個(gè)列。一個(gè)條目可能有20個(gè)相關(guān)的字符串，另一個(gè)可能有12個(gè)整數(shù)類型，另一個(gè)可能完全是空白。程序員能夠在需要存儲(chǔ)時(shí)隨時(shí)做出決定，他們不需要獲得DBA的許可，也不需要填寫所有的文檔，以增加一個(gè)新的列。

    這些自由聽起來非常具有誘惑力，并且能夠加快開發(fā)速度。但是對(duì)于需要三個(gè)開發(fā)團(tuán)隊(duì)的數(shù)據(jù)庫來說，這真的是一個(gè)好主意嗎？對(duì)于可能持續(xù)六個(gè)月以上時(shí)間的數(shù)據(jù)庫來說，它們是否可行？

    換句話說，開發(fā)者可能希望利用這些自由將老的Pair（對(duì)）加入到數(shù)據(jù)庫中。

    但是，在四名開發(fā)者已經(jīng)選擇了他們自己的鍵后，你希望成為第五名開發(fā)者嗎？我們可以想象一下“birthday”（生日）的多種表達(dá)方式。在添加用戶生日進(jìn)入條目中時(shí)，每名開發(fā)者都會(huì)選擇他們自己的表示方式。一個(gè)開發(fā)團(tuán)隊(duì)幾乎可能會(huì)想到所有的表示形式，例如“bday”、“b-day”和“birthday”。NoSQL架構(gòu)并不支持限制這一問題，因?yàn)檫@意味著要重新設(shè)計(jì)綱要。它們不希望對(duì)個(gè)性化的開發(fā)者加以限制。

    真相6：沒有附加功能

    你不希望把所有的數(shù)據(jù)存儲(chǔ)在所有的行中，你希望得到單選索引的總數(shù)。SQL用戶能夠通過SUM操作執(zhí)行一個(gè)查詢，然后向你反饋一個(gè)數(shù)字。

    NoSQL用戶則將所有的數(shù)據(jù)反饋至他們那里，然后自己進(jìn)行添加。添加并不是問題，因?yàn)樵谌魏螜C(jī)器上增加數(shù)字都需要花上相同的時(shí)間。但是數(shù)據(jù)反饋卻非常慢。反饋所有數(shù)據(jù)所需要的帶寬也非常的昂貴。

    NoSQL數(shù)據(jù)庫中幾乎沒有附加功能。除了存儲(chǔ)和檢索數(shù)據(jù)外，如果你想做任何事情，你可能需要自己動(dòng)手。在許多案例中，通過完整的數(shù)據(jù)復(fù)制，你可以在不同的機(jī)器上做這些事情。真正的問題是，它對(duì)在保留有數(shù)據(jù)的機(jī)器上進(jìn)行計(jì)算有幫助。因?yàn)榭梢允∪?shù)據(jù)反饋的時(shí)間，但是對(duì)于你來說卻是非常的困難。

    MongoDB提供的映射與約簡查詢架構(gòu)可以讓你通過任意的JavaScript架構(gòu)來簡化數(shù)據(jù)。在擁有數(shù)據(jù)的機(jī)器間分發(fā)計(jì)算方面，Hadoop是一個(gè)強(qiáng)大的機(jī)制。它是一個(gè)快速演進(jìn)的架構(gòu)，可以為創(chuàng)建復(fù)雜的分析快速提供改良的工具。這聽起來非?？?，但是Hadoop技術(shù)本身卻非常新。盡管Hadoop與NoSQL之間的差別正在消失，但是在技術(shù)上，Hadoop是一個(gè)與NoSQL完全不同的東西。

    真相7：工具太少

    你能夠在服務(wù)器上部署NoSQL并運(yùn)行它們。當(dāng)然，你也能夠編寫你自己自定義的代碼以讀寫數(shù)據(jù)。但是如果你希望做更多的事，那它們會(huì)怎么樣呢？如果你想購買一個(gè)報(bào)告套件，一個(gè)繪圖套件或是下載一些用于創(chuàng)建圖表的開源工具，它們又會(huì)怎么樣呢？

    很不幸，大多數(shù)工具都是針對(duì)SQL數(shù)據(jù)庫編寫的。如果你想生成報(bào)告，創(chuàng)建圖表，或是利用NoSQL堆棧中的數(shù)據(jù)做一些事情，你需要重新進(jìn)行編寫。目前已經(jīng)有了用于處理來自甲骨文數(shù)據(jù)庫、微軟SQL Server、MySQL和Postgres等SQL數(shù)據(jù)庫中數(shù)據(jù)的標(biāo)準(zhǔn)工具。你的數(shù)據(jù)是NoSQL類型的嗎？目前工具制造商們正在努力解決這些問題。

    市場上已經(jīng)有20多個(gè)不同的NoSQL選擇，這些選擇都擁有自己的理念和處理數(shù)據(jù)的方式。對(duì)于工具制造商而言，他們難以支持SQL的特點(diǎn)和不一致性。

    然而與之相比，為NoSQL解決方案制造相關(guān)工具則更為困難。

    當(dāng)然，這一問題會(huì)慢慢被消滅。開發(fā)者們已經(jīng)意識(shí)到了NoSQL的優(yōu)勢，他們將修改自己的工具，以適合這些新的系統(tǒng)，不過這要花上些時(shí)間?；蛟S他們會(huì)針對(duì)MongoDB開發(fā)出一些工具，但是這對(duì)于使用Cassandra的用戶而言沒有絲毫的幫助。在這種情況下，標(biāo)準(zhǔn)就顯得尤為重要。但是在這一方面，NoSQL并不擅長。（完）

該文章在 2012/8/31 9:51:57 編輯過