巴西人Henrique Lobo Weissmann(還有個名字叫Kico Lobo)是咨詢公司itexto的聯(lián)合創(chuàng)始人，他還在2008年創(chuàng)立了Grails Brasil——巴西最大的Groovy and Grails 用戶組織，當下成員已超過1700個，仍處于飛速增長階段。近日Kico在其博客上發(fā)表了多篇NoSQL精彩博文，這里為大家分享他對NoSQL一些常見宣傳的看法。

[[84932]]

以下為譯文：

與許多流行詞一樣，NoSQL在大肆宣傳后，許多荒謬的觀點產(chǎn)生，本篇文章將揭穿其中廣被認同的5個。

流言1：NoSQL是新鮮事物

從根本上說，NoSQL數(shù)據(jù)庫系統(tǒng)的幾大屬性都不是出于關(guān)系模型，而關(guān)系模型首次揭露是在1970年Codd發(fā)布的文章中。

那么，這是否就意味著在1970年之前不存在任何其它的數(shù)據(jù)庫系統(tǒng)?不容爭論的是，這些數(shù)據(jù)庫卻是真實存在，比如CODASYL系統(tǒng)，它顯然不是關(guān)系型數(shù)據(jù)庫;基于其主要屬性，NoSQL的誕生其實明顯早于傳統(tǒng)關(guān)系型數(shù)據(jù)庫。

流言2：遺棄數(shù)據(jù)結(jié)構(gòu)模型

從長遠上看，這個流言的影響更為惡劣。雖然許多NoSQL解決方案都不會強迫你使用嚴格的數(shù)據(jù)結(jié)構(gòu)模型，但是絕對不意味它可以忽視。而在實際操作中也是恰恰相反的，隨著時間的流逝，你必須明白你為什么要使用這些屬性。

有些情況可能會更加危險，舉個MongoDB的例子：作為一個良好的實踐，許多經(jīng)驗豐富的用戶都會建議去建立文檔的屬性，在文檔大小改變時，通過預(yù)分配大小去避免文檔的完整拷貝。還有在查詢優(yōu)化時，你必須要清楚你的結(jié)構(gòu)模型以便做索引。

流言3：NoSQL的擴展性永遠都是卓越的

高擴展性是NoSQL的主要賣點之一，但是僅僅選擇一個NoSQL解決方案并不意味著擴展性問題的解決，真正解決問題的是優(yōu)秀的架構(gòu)。

不錯，這里確實存在通過選擇NoSQL讓系統(tǒng)擴展性得到了大幅度的提升。然而勝利的背后依稀可見的是數(shù)據(jù)結(jié)構(gòu)的變化，在特定場景下使用正確的結(jié)構(gòu)替換錯的。

這個流言中有趣的地方是忽略了同樣提供優(yōu)秀擴展性的關(guān)系型數(shù)據(jù)庫，不錯，使用NoSQL方案進行擴展確實非常容易，但是NoSQL的選擇絕對不是問題解決的唯一功臣。

流言4：不公平的基準

你如何才能公平的比較兩個完全不同的持久化方案，比如：鍵值、關(guān)系、文檔等等。而當下許多NoSQL與關(guān)系型數(shù)據(jù)庫的對比也并不公平。

當你的查詢只涉及一個鍵時，NoSQL數(shù)據(jù)庫的性能明顯要優(yōu)于關(guān)系型數(shù)據(jù)庫。公平的基準應(yīng)該建立在同類型產(chǎn)品的比較之上，類似MySQL與MongoDB的對比根本無任何意義。即使系統(tǒng)性能取得了巨大提升，也只是開始時使用了錯誤的數(shù)據(jù)結(jié)構(gòu)模型而已。

流言5：NoSQL可以大幅度的提高生產(chǎn)力

這一點只發(fā)生在夢中，或者是開始選擇了錯誤的工具。在選擇NoSQL之前，我們已經(jīng)使用了多年的關(guān)系型數(shù)據(jù)庫，這里只存在團隊花大量精力去適應(yīng)NoSQL的情況。

很少人談及這一點， NoSQL采用最大的挑戰(zhàn)是文化，而不是技術(shù)。新事物之所以難以接受，是因為“老伙計”用起來很舒服，即使新事物更加得優(yōu)秀。生產(chǎn)力源于實踐，而不是魔術(shù)。

總結(jié)

對比近年來研發(fā)領(lǐng)域發(fā)生的事件，NoSQL絕對可以稱得上最有意義之一;然而需要銘記的是，任何提升都需要付出同等的代價。