NoSQL與關系型數據庫設計理念比較　　

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

特點：
它們可以處理超大量的數據。

它們運行在便宜的PC服務器集群上。

它們擊碎了性能瓶頸。

沒有過多的操作。

Bootstrap支持

1，Cassandra:

Cassandra從安裝配置，到使用，負載平衡機制等等，無疑是這些新興的NoSQL中最方便使用的一個（個人使用體驗觀點）

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

2.MongoDB:

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

3.Redis:

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

4.HBase:

概念上也相對完美，有Hive開源工具支持，使HBase,可以相對于其它NoSQL數據庫更易于使用，基于HDFS分布文件系統，使HBASE天
生就有對海量分布集群很好的支持。又因為與Hadoop相伴而生，所以一個系統想使用數據分析，智能處理，海量邏輯執行，完全可以選擇Hadoop +
HBase云計算方案。

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

當我使有MySQL +
NoSQL方案時，我會選擇MongoDB,不僅是因為他的出色的海量分布式方案的支持，也不是因為經的Map/Reducer分布式計算的支持。而是因
為還沒聽說過它有過重大的失敗案例，相對較完美的文檔（還有中文手冊喲）還有JSON分格支持，在當下WebAPI流行的時代，不僅是從個人喜愛角度，也
是從工程管理角度，開發人員更Love it,呵呵。

1、穩定性

2、索引，索引放在內存中，能夠提升隨機讀寫的性能。如果索引不能完全放在內存，一旦出現隨機讀寫比較高的時候，就會頻繁地進行磁盤交換，MongoDB的性能就會急劇下降

3、占用的空間很大，因為它屬于典型空間換時間原則的類型。那么它的磁盤空間比普通數據庫會浪費一些，而且到目前為止它還沒有實現在線壓縮功能，

在MongoDB中頻繁的進行數據增刪改時，如果記錄變了，例如數據大小發生了變化，這時候容易產生一些數據碎片，出現碎片引發的結果，

一個是索引會出現性能問題，

另外一個就是在一定的時間后，所占空間會莫明其妙地增大，所以要定期把數據庫做修復，定期重新做索引，這樣會提升MongoDB的穩定性和效率。

在最新的版本里，它已經在實現在線壓縮，估計應該在2.0版左右，應該能夠實現在線壓縮，可以在后臺執行現在repair DataBase的一些操作。如果那樣，就解決了目前困擾

我們的大問題。

4、MongoDB對數據間的事務關系支持比較弱

5、運維不方便