NoSQL與關(guān)系型數(shù)據(jù)庫(kù)設(shè)計(jì)理念比較　　

關(guān)系型數(shù)據(jù)庫(kù)中的表都是存儲(chǔ)一些格式化的數(shù)據(jù)結(jié)構(gòu)，每個(gè)元組字段的組成都一樣，即使不是每個(gè)元組都需要所有的字段，但數(shù)據(jù)庫(kù)會(huì)為每個(gè)元組分配所有的字段，這樣的結(jié)構(gòu)可以便于表與表之間進(jìn)行連接等操作，但從另一個(gè)角度來說它也是關(guān)系型數(shù)據(jù)庫(kù)性能瓶頸的一個(gè)因素。而非關(guān)系型數(shù)據(jù)庫(kù)以鍵值對(duì)存儲(chǔ)，它的結(jié)構(gòu)不固定，每一個(gè)元組可以有不一樣的字段，每個(gè)元組可以根據(jù)需要增加一些自己的鍵值對(duì)，這樣就不會(huì)局限于固定的結(jié)構(gòu)，可以減少一些時(shí)間和空間的開銷。

特點(diǎn)：
它們可以處理超大量的數(shù)據(jù)。

它們運(yùn)行在便宜的PC服務(wù)器集群上。

它們擊碎了性能瓶頸。

沒有過多的操作。

Bootstrap支持

1，Cassandra:

Cassandra從安裝配置，到使用，負(fù)載平衡機(jī)制等等，無疑是這些新興的NoSQL中最方便使用的一個(gè)（個(gè)人使用體驗(yàn)觀點(diǎn)）

但從近期的消息來看由于出現(xiàn)過幾次較為嚴(yán)重的數(shù)據(jù)庫(kù)停止服務(wù)事件，Cassandra的創(chuàng)始人Facebook,及Twitter開始漸漸棄用
Cassandra,只把Cassandra用在非核心模塊上，不地Digg仍在使用，看來我們要謹(jǐn)慎地對(duì)待它。2008年Facebook已讓
Cassandra開源到Apache.

2.MongoDB:

它的風(fēng)格可以說，在當(dāng)今WebAPI流行的時(shí)代，它更易于被人使用，BJSON操作風(fēng)格，自動(dòng)數(shù)據(jù)平衡機(jī)制（當(dāng)然要當(dāng)心存貯碎片問題），相對(duì)
MySQL等SQL數(shù)據(jù)庫(kù)有優(yōu)秀考慮全面的，分布式方案，自動(dòng)M/S主從讀寫切換。對(duì)于數(shù)據(jù)集群來說，可以說相當(dāng)完美的Sharding等自動(dòng)化支持。至
今聽說過的最嚴(yán)重的事件就是FourSquare的11小時(shí)數(shù)據(jù)庫(kù)宕機(jī)事件。相對(duì)來說還能接受：），它是使用C++/Boost編寫，效率性能的確不錯(cuò)。

3.Redis:

它就是一個(gè)高效的內(nèi)存數(shù)據(jù)庫(kù)，用它來持久化數(shù)據(jù)存貯，那是扯淡，如果真拿它來與別的NoSQL一樣使用（考慮讀寫一致性或者寫安全）那它馬上慢下
來：）不過他提供了比Memcached更多的操作數(shù)據(jù)類型，倒可以完全用它來做為一個(gè)高效易用的緩存，Benchmark據(jù)說優(yōu)于memcached.
我用的數(shù)據(jù)規(guī)模沒有這么大，不敢妄加評(píng)論。

4.HBase:

概念上也相對(duì)完美，有Hive開源工具支持，使HBase,可以相對(duì)于其它NoSQL數(shù)據(jù)庫(kù)更易于使用，基于HDFS分布文件系統(tǒng)，使HBASE天
生就有對(duì)海量分布集群很好的支持。又因?yàn)榕cHadoop相伴而生，所以一個(gè)系統(tǒng)想使用數(shù)據(jù)分析，智能處理，海量邏輯執(zhí)行，完全可以選擇Hadoop +
HBase云計(jì)算方案。

MongoDB也支持js的Map/Reducer所以可以試著整合一下MongoDB進(jìn)云計(jì)算方案中。

當(dāng)我使有MySQL +
NoSQL方案時(shí)，我會(huì)選擇MongoDB,不僅是因?yàn)樗某錾暮Ａ糠植际椒桨傅闹С?，也不是因?yàn)榻?jīng)的Map/Reducer分布式計(jì)算的支持。而是因
為還沒聽說過它有過重大的失敗案例，相對(duì)較完美的文檔（還有中文手冊(cè)喲）還有JSON分格支持，在當(dāng)下WebAPI流行的時(shí)代，不僅是從個(gè)人喜愛角度，也
是從工程管理角度，開發(fā)人員更Love it,呵呵。

1、穩(wěn)定性

2、索引，索引放在內(nèi)存中，能夠提升隨機(jī)讀寫的性能。如果索引不能完全放在內(nèi)存，一旦出現(xiàn)隨機(jī)讀寫比較高的時(shí)候，就會(huì)頻繁地進(jìn)行磁盤交換，MongoDB的性能就會(huì)急劇下降

3、占用的空間很大，因?yàn)樗鼘儆诘湫涂臻g換時(shí)間原則的類型。那么它的磁盤空間比普通數(shù)據(jù)庫(kù)會(huì)浪費(fèi)一些，而且到目前為止它還沒有實(shí)現(xiàn)在線壓縮功能，

在MongoDB中頻繁的進(jìn)行數(shù)據(jù)增刪改時(shí)，如果記錄變了，例如數(shù)據(jù)大小發(fā)生了變化，這時(shí)候容易產(chǎn)生一些數(shù)據(jù)碎片，出現(xiàn)碎片引發(fā)的結(jié)果，

一個(gè)是索引會(huì)出現(xiàn)性能問題，

另外一個(gè)就是在一定的時(shí)間后，所占空間會(huì)莫明其妙地增大，所以要定期把數(shù)據(jù)庫(kù)做修復(fù)，定期重新做索引，這樣會(huì)提升MongoDB的穩(wěn)定性和效率。

在最新的版本里，它已經(jīng)在實(shí)現(xiàn)在線壓縮，估計(jì)應(yīng)該在2.0版左右，應(yīng)該能夠?qū)崿F(xiàn)在線壓縮，可以在后臺(tái)執(zhí)行現(xiàn)在repair DataBase的一些操作。如果那樣，就解決了目前困擾

我們的大問題。

4、MongoDB對(duì)數(shù)據(jù)間的事務(wù)關(guān)系支持比較弱

5、運(yùn)維不方便