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

　　關(guān)鍵是要意識(shí)到不同的應(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ī)的使用場(chǎng)景。

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

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

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

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

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

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

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

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

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

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

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

　　需要不同的訪問(wèn)方式和數(shù)據(jù)類型的話可以看看文檔數(shù)據(jù)庫(kù)，它們?cè)谶@方面很靈活。

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

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

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

　　搜索可以考慮Riak。

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

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

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

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

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

　　要記錄連續(xù)的大量數(shù)據(jù)，又對(duì)一致性無(wú)太高要求，可以看看Bigtable類型數(shù)據(jù)庫(kù)，因?yàn)樗ぷ髟诜植际轿募到y(tǒng)上，可以處理大規(guī)模的寫入請(qǐng)求。

　　需要盡可能使用簡(jiǎn)單，請(qǐng)考慮PAAS方案，用這種方案你自己幾乎不需要做什么。

　　如果你的產(chǎn)品要賣給企業(yè)客戶請(qǐng)考慮關(guān)系數(shù)據(jù)庫(kù)，因?yàn)樗麄兞?xí)慣于關(guān)系數(shù)據(jù)庫(kù)。

　　要?jiǎng)討B(tài)構(gòu)建對(duì)象間的關(guān)系，對(duì)象的屬性能夠動(dòng)態(tài)加減，可以考慮圖數(shù)據(jù)庫(kù)，因?yàn)樗恍枰猻chema，可以在代碼中隨需建模。

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

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

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

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

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

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

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

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

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

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

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

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

　　能夠在云中操作，自動(dòng)利用云的一切特性和好處，目前還沒(méi)有這樣的東西。

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

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

　　規(guī)模不斷增長(zhǎng)(真正的大數(shù)據(jù)場(chǎng)景)，但是訪問(wèn)不頻繁的數(shù)據(jù)可以使用Bigtable類型的數(shù)據(jù)庫(kù)，因?yàn)樗臄?shù)據(jù)存儲(chǔ)在一個(gè)分布式文件系統(tǒng)上，很容易擴(kuò)展 。

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

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

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

　　移動(dòng)平臺(tái)上可以用CouchDB/Mobile couchbase.

　　那個(gè)更好?

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

　　性能測(cè)試數(shù)據(jù)都有其特定的場(chǎng)景，不見(jiàn)得能適合你的情況。

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

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

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