為效能放棄功能 ? NoSQL 前要考慮的事

NoSQL 與傳統 Relational DB 方案選擇是近期討論熱點之一，最近看了一些方案之間的比較，數字上的意義或許有一些參考價值，但方案是否適合企業業務運作，資料儲存選擇方面的、不同選項背後的理論，在 SQL 和 NoSQL 之間的比較可以有更多考慮指標。

有關評測由 EnterpriseDB 進行，比較了 MongoDB 2.6 及 PostgreSQL 9.4 在不同環境下的效能分數。EnterpriseDB 是開發 PostgreSQL 的公司，因此測評可能會有一點欠缺公允。然而，大多數公司是否正確地看待 著NoSQL解決方案、以及性能需求是否已經成為他們急需考慮的。如我們看看Mongo在維基百科上的解釋：

MongoDB (from “humongous”) is a cross-platform document-oriented database. Classified as a NoSQL database, MongoDB eschews the traditional table-based relational database structure in favor of JSON-like documents with dynamic schemas (MongoDB calls the format BSON), making the integration of data in certain types of applications easier and faster

介紹中“certain types of applications”是重點所在，因為企業不能僅僅因為性能就拋棄relational database，轉而採用面向文檔的資料庫，因為這是愚蠢的動機：一優的化 SQL 資料庫每秒處理的事務能夠超過 14000 條，因此如果你超過了這個級數，說明你已經在一流的公司裡了。

相反，當實體大部分與樹形結構相關，且關係模型持續被迫地創建join或重度反規範化關係而超越了其合理性時，文檔資料庫就比關係型數據庫的更好的解決方案。在這種情況下，資料模型符合上面的約束，那麼文檔結構有能力比relational model創建更少的、與物件導向設計不匹配的現象。據我們所知，所有重要的relational database模式創建了大量的與物件模型相關的屬性，這就是飽受詬病的 Object-relational impedance mismat問題。物件導向的系統通常是樹狀結構，它比其它模型能夠更好地適應文檔資料庫，Graph database除外，很明顯，Graph database實現了一個圖的大部分通常表現。

很多人費力地從NoSQL資料庫抽出非常基本的資訊，而這些資訊用關係型數據庫就可輕易地做到，主要是因為多年來人們都是這樣做的。那麼，NoSQL資料庫在管理事務上，和relational database相比，有著很大的不同：用最終一致性(Eventual Consistency)和Idempotent Services設計應用程式，這意味著企業可以採用新技術來解決舊有觀念，而筆者對於最終建議是採用適合你的 domain mode 的資料存儲方案，不要過早地性能優化，因為你可能還需要儘量解決錯誤的問題。

原文網址：http://maurizioturatti.com/blog/2015/01/06/using-nosql-wrong-reason/