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

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

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

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 mismatch)問題。物件導向的系統通常是樹狀結構，它比其它模型能夠更好地適應文檔資料庫，Graph database除外，很明顯，Graph database實現了一個圖的大部分通常表現。

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