NoSQL與關係型資料庫設計理念比較　　

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

特點：
它們可以處理超大量的資料。
它們執行在便宜的PC伺服器叢集上。
它們擊碎了效能瓶頸。
沒有過多的操作。
Bootstrap支援

缺點：
但是一些人承認，沒有正式的官方支援，萬一出了差錯會是可怕的，至少很多管理人員是這樣看。
此外，nosql並未形成一定標準，各種產品層出不窮，內部混亂，各種專案還需時間來檢驗

MySQL還是NoSQL：開源盛世下的資料庫該如何選擇

摘要：MySQL，關係型資料庫，有數量龐大的支持者。NoSQL，非關係型資料庫，被視為資料庫革命者。兩者似乎註定要有一場廝殺，可同屬開源大家庭的它們卻又能攜手並進、和睦相處，齊心協力為開發者提供更好的服務。

如何選擇：永遠正確的經典答案依然是：具體問題具體分析。

MySQL體積小、速度快、成本低、結構穩定、便於查詢，可以保證資料的一致性，但缺乏靈活性。NoSQL高效能、高擴充套件、高可用，不用侷限於固定的結構，減少了時間和空間上的開銷，卻又很難保證資料一致性。兩者都有大量的使用者和支持者，尋求兩者的結合無疑是個很好的解決方案。作者John Engates是Rackspace主機託管部門CTO，也是個開放雲支持者，他為我們帶來了詳細的分析。

選擇其中一個？還是兩者都要？

應用程式是否應該與關係型資料庫或NoSQL（也許是兩者）相一致，當然，這得基於被生成或被檢索資料的性質。和大多數科技領域的事物一樣，做決定時要折中考慮。

如果規模和效能比24小時的資料一致性更重要，那NoSQL是一個理想的選擇 （NoSQL依賴於BASE模型——基本可用、軟狀態、最終一致性）。

但如果要保證到“始終一致”，尤其是對於機密資訊和財務資訊，那麼MySQL很可能是最優的選擇（MySQL依賴於ACID模型——原子性、一致性、獨立性和耐久性）。

作為開源資料庫，無論是關係型資料庫還是非關係型資料庫都在不斷成熟，我們可以期待還會有一大批基於ACID和BASE模型的新應用產生。

NoSQL還是關係資料庫

       雖然09年出現了比較激進的文章《關係資料庫已死》，但是我們心裡都清楚，關係資料庫其實還活得好好的，你還不能不用關係資料庫。但是也說明了一個事實，關係資料庫在處理WEB2.0資料的時候，的確已經出現了瓶頸。

       那麼我們到底是用NoSQL還是關係資料庫呢？我想我們沒有必要來進行一個絕對的回答。我們需要根據我們的應用場景來決定我們到底用什麼。

如果關係資料庫在你的應用場景中，完全能夠很好的工作，而你又是非常善於使用和維護關係資料庫的，那麼我覺得你完全沒有必要遷移到NoSQL上面，除非你是個喜歡折騰的人。如果你是在金融，電信等以資料為王的關鍵領域，目前使用的是Oracle資料庫來提供高可靠性的，除非遇到特別大的瓶頸，不然也別貿然嘗試NoSQL。

        然而，在WEB2.0的網站中，關係資料庫大部分都出現了瓶頸。在磁碟IO、資料庫可擴充套件上都花費了開發人員相當多的精力來優化，比如做分表分庫（database sharding）、主從複製、異構複製等等，然而，這些工作需要的技術能力越來越高，也越來越具有挑戰性。如果你正在經歷這些場合，那麼我覺得你應該嘗試一下NoSQL了。