你的應(yīng)用應(yīng)該用什么?

　　關(guān)鍵是要意識到不同的應(yīng)用需要不同的數(shù)據(jù)模型和產(chǎn)品。選擇合適的數(shù)據(jù)模型和產(chǎn)品。

　　要了解你的應(yīng)用需要什么樣的數(shù)據(jù)模型可以看 What The Heck Are You Actually Using NoSQL For? 在這篇文章里我總結(jié)了一些特色各異的非常規(guī)的使用場景。

　　適應(yīng)你的需求和應(yīng)用場景。依次而為你就能找到最適合你的架構(gòu)的產(chǎn)品。無論NoSQL還是SQL都不重要。

　　綜合考慮數(shù)據(jù)模型、產(chǎn)品特性和應(yīng)用情景。不同產(chǎn)品功能各異，只憑數(shù)據(jù)模型來決定選擇誰是不可能的。

　　哪個產(chǎn)品具有你最需要的特點哪個就是***的。

　　假如你的應(yīng)用有以下需求：

　　復(fù)雜事物，如果你不能承受數(shù)據(jù)丟失的風(fēng)險或者你想要一個簡單的事務(wù)編程模型可以選擇關(guān)系數(shù)據(jù)庫和網(wǎng)格數(shù)據(jù)庫。

　　例子：一個庫存系統(tǒng)需要完整的ACID特性。如果我在買了一個東西后才被告知它已經(jīng)售罄我會非常不快。不不想要補(bǔ)償，我只要我買的東西。

　　擴(kuò)展性，NoSQL或SQL皆可，目標(biāo)產(chǎn)品要支持水平擴(kuò)展、分區(qū)、在線增減硬件、負(fù)載均衡、自動分片、數(shù)據(jù)平衡和容錯等特性。

　　追求高可用性，可用Bigtable類型的等支持最終一致性的數(shù)據(jù)庫。

　　需要處理長期的快速讀寫，可以看看文檔數(shù)據(jù)庫，Key-value數(shù)據(jù)庫或者內(nèi)存數(shù)據(jù)庫，還可以考慮SSD。

　　要實現(xiàn)社會化網(wǎng)絡(luò)，***選擇應(yīng)該是圖數(shù)據(jù)庫。其次像Riak這樣支持關(guān)系的數(shù)據(jù)庫也可以。一個支持簡單SQL join操作的內(nèi)存關(guān)系數(shù)據(jù)庫能夠處理數(shù)據(jù)量不大的情況。Redis’ set 和list 操作就是這樣。

　　假如你的應(yīng)用有以下需求：

　　需要不同的訪問方式和數(shù)據(jù)類型的話可以看看文檔數(shù)據(jù)庫，它們在這方面很靈活。

　　大數(shù)據(jù)量的離線分析首先應(yīng)該考慮Hadoop，其次是其他支持MapReduce的產(chǎn)品。當(dāng)然，支持MapReduce與擅長MapReduce處理不是一回事。

　　如需跨越多個數(shù)據(jù)中心，可選用基于Bigtable模型的產(chǎn)品，或其分布式的，能解決延遲問題，分區(qū)容錯性問題的產(chǎn)品

　　CRUD類型的應(yīng)用可以考慮文檔數(shù)據(jù)庫，這樣不需要join就可訪問復(fù)雜的數(shù)據(jù)結(jié)構(gòu)。

　　搜索可以考慮Riak。

　　需要lists, sets, queues, publish-subscribe等數(shù)據(jù)結(jié)構(gòu)的話，可以考慮Redis，它的分布式鎖等特性也非常有用。

　　編程友好，如果要使用JSON, HTTP, REST, Javascript等程序員喜聞樂見的數(shù)據(jù)類型，***選擇就是文檔數(shù)據(jù)庫和Key-value數(shù)據(jù)庫。

　　假如你的應(yīng)用有以下需求：

　　用于實時事務(wù)處理的物化視圖，可以考慮VoltDB，非常適合于快速處理大量事務(wù)。

　　企業(yè)級支持及服務(wù)級協(xié)議 ，可以尋找市場上以此為賣點的產(chǎn)品，如Membase。

　　要記錄連續(xù)的大量數(shù)據(jù)，又對一致性無太高要求，可以看看Bigtable類型數(shù)據(jù)庫，因為它工作在分布式文件系統(tǒng)上，可以處理大規(guī)模的寫入請求。

　　需要盡可能使用簡單，請考慮PAAS方案，用這種方案你自己幾乎不需要做什么。

　　如果你的產(chǎn)品要賣給企業(yè)客戶請考慮關(guān)系數(shù)據(jù)庫，因為他們習(xí)慣于關(guān)系數(shù)據(jù)庫。

　　要動態(tài)構(gòu)建對象間的關(guān)系，對象的屬性能夠動態(tài)加減，可以考慮圖數(shù)據(jù)庫，因為它不需要schema，可以在代碼中隨需建模。

　　要支持大影音文件，可以看看像S3這樣的存儲服務(wù)。NoSQL不適于存儲BLOBS，盡管MongoDB也提供了文件服務(wù)。

　　假如你的應(yīng)用有以下需求：

　　要快速批量上傳大量數(shù)據(jù)，得尋找支持這種場景的產(chǎn)品。但是大多數(shù)產(chǎn)品都不支持批量操作。

　　易于變化，要選擇支持動態(tài)schema的文檔數(shù)據(jù)庫和 Key-value數(shù)據(jù)庫。它支持可選域，不需要修改schema即可增加、減少域。

　　為了支持完整性約束，選擇支持SQL DDL的數(shù)據(jù)庫，可以在存儲過程或者應(yīng)用代碼中實現(xiàn)。

　　深度連接用圖數(shù)據(jù)庫，它支持實體鍵間的快速定位。

　　為了讓計算靠近數(shù)據(jù)，減少數(shù)據(jù)在網(wǎng)絡(luò)中傳送的開銷，可以考慮存儲過程。關(guān)系數(shù)據(jù)庫，網(wǎng)個數(shù)據(jù)庫，文檔數(shù)據(jù)庫和Key-value數(shù)據(jù)庫都支持存儲過程。

　　假如你的應(yīng)用有以下需求：

　　要存儲BLOB數(shù)據(jù)，可選擇Key-value數(shù)據(jù)庫。它可以存儲網(wǎng)頁或者復(fù)雜對象，后者在關(guān)系數(shù)據(jù)庫中要用join才能獲取，代價高昂。還可以降低延遲。

　　選擇一個經(jīng)過驗證的成熟產(chǎn)品，在處理擴(kuò)展性問題的時候的時候選擇通用的方案(縱向擴(kuò)展、調(diào)優(yōu)、緩存、數(shù)據(jù)分片、反范式等等)

　　多變的數(shù)據(jù)類型，數(shù)據(jù)不規(guī)整，列數(shù)不固定，復(fù)雜的數(shù)據(jù)結(jié)構(gòu)等，考慮文檔數(shù)據(jù)庫，Key-value數(shù)據(jù)庫，和Bigtable型數(shù)據(jù)庫。它們的數(shù)據(jù)類型都比較靈活。

　　需要快速的關(guān)系查詢，但是又不想自己實現(xiàn)，那么就選擇支持SQL的數(shù)據(jù)庫。

　　能夠在云中操作，自動利用云的一切特性和好處，目前還沒有這樣的東西。

　　假如你的應(yīng)用有以下需求：

　　支持二級索引，通過不同的鍵來檢索，可以考慮關(guān)系數(shù)據(jù)庫和 Cassandra，后者新增了對二級索引的支持。

　　規(guī)模不斷增長(真正的大數(shù)據(jù)場景)，但是訪問不頻繁的數(shù)據(jù)可以使用Bigtable類型的數(shù)據(jù)庫，因為它的數(shù)據(jù)存儲在一個分布式文件系統(tǒng)上，很容易擴(kuò)展 。

　　要和其他服務(wù)集成，檢查數(shù)據(jù)庫是否提供某種寫后同步功能，以便能夠捕捉到數(shù)據(jù)庫變化，通知其它系統(tǒng)，保證一致性。

　　容錯性，檢查在停電、分區(qū)故障以及其他故障場景下寫操作是否能夠成功。

　　如果只是為了推動某個方向上的技術(shù)創(chuàng)新，似乎沒有現(xiàn)成的東西能夠達(dá)到這個目的，你得自己去創(chuàng)造一個新的。這可不是件容易事。

　　移動平臺上可以用CouchDB/Mobile couchbase.

　　那個更好?

　　為了25%的性能提升而遷移到NoSQL是不值得的。

　　性能測試數(shù)據(jù)都有其特定的場景，不見得能適合你的情況。

　　如果你的公司剛剛成立，還沒有一個成型的產(chǎn)品，并且你很愿意嘗試一些新東西，那么選擇SQL還是NoSQL對你而言需要費(fèi)上些心思(言下之意，一張白紙好作畫，沒有既有系統(tǒng)的負(fù)擔(dān)就可以隨便折騰?)。

　　數(shù)據(jù)量不大的時候性能差距并不明顯，但是當(dāng)數(shù)據(jù)量變大的時候呢?

　　沒有***的東西，如果你去Amazon的論壇上去看，上面充滿了對各種產(chǎn)品的性能和服務(wù)的抱怨，GAE也是一樣。每個產(chǎn)品都會有問題，你能解決你選擇的產(chǎn)品的問題嗎?