4 種不適合使用NoSQL數據庫的場景
我們在最近的一篇文章中探討了 NoSQL 和 NewSQL之間的基本區別。 現在讓我們通過觀察開發人員真正關心的問題來剖析其差異：
- 我們可以用NoSQL來解決哪些問題?
- 同樣重要的是，NoSQL在哪些方面不適合使用?
- 不同的方法 (NoSQL 和 NewSQL) 在哪些方面才能顯示它們的優勢?
讓我們回顧一下NoSQL和NewSQL之間四個有明顯差異的領域，并回顧一下一些使用NoSQL技術，但可能不是***選擇的用例。
NoSQL數據庫的四個缺點
不要讓我們產生誤解，NoSQL數據庫對于許多工作負載和應用程序是非常有優勢的，但在四個方面，NoSQL的缺點是很明顯的。
可擴展性
當NoSQL產品用來實現以滿足諸如Google，Facebook和Twitter等與生俱來的網絡公司的可擴展性需求時，它們開始引起注意。 這些公司要處理大量來自無數來源的非結構化數據：網絡搜索，移動設備，用戶狀態更新，評論流等。
在這些用例中，最重要的考慮是可擴展性：數據庫必須大規模擴展。 SQL數據庫的僵硬模式和交互性被視為枷鎖，并且在傳統RDBMS上擴展的成本也被認為是不可行的。
在廉價的硬件商品上向外擴展的能力是很關鍵的。 如果你的用例需要橫向擴展***數據源，NoSQL可能是正確的選擇 --- 除非你要對數據進行實時操作。
雖然傳統的關系數據庫系統提供了擴展選項 ---- 以非常顯著的成本 ---- 許多NewSQL系統被設計為解決可擴展性挑戰，首先使用NoSQL來解決，同時保留傳統RDBMS的事務性和交互性。
一個很好的替代方案是內存中，大規模并行的SQL關系數據庫，它在廉價的硬件商品上線性擴展。 數據庫應該是云友好的，并且能夠通過擴展來滿足云操作的需求。 應該將其設計為具有高性能和低延遲，具有無共享，本地群集，云友好的架構，從而實現高可用性，可冗余和容錯性。
可用性
大多數NoSQL系統是為可用性設計的，CAP-定理>
這個由Apache Cassandra做出的著名的設計決策是基于這樣一個觀點，即數據總是可以訪問比數據立即正確更重要。 畢竟，理由是，誰真的關心一個Tweet是否真的按照發布的順序實時顯示? 最終，它將以正確的順序顯示，但不一定非得立即正確顯示。
在某些用例中，最終的一致性是可以接受的。 但是在許多情況下，例如當您需要立即作出決定時...
- 讓移動用戶的訪問通過。
- 分配有限的，稀缺的資源。
- 處理財務。
... EC(和NoSQL)就不是一個好的選擇。
一些NewSQL系統允許用戶能夠將一致性級別調低。 例如，MemSQL支持弱隔離(ACID中的“I”)來提高查詢延遲。 為了可用性而犧牲正確答案，這對分析型(OLAP)工作負載可能是有意義的，但對事務型(OLTP)工作負載就變得無關緊要了。
一致性(例如，兼容ACID事務，正確答案)
NoSQL系統被設計為可用性(見上文)。 這個選擇意味著他們無法提供CAP定理>
因此，NoSQL系統選擇AP - 它們是可用性和分區容錯性。 這使得NoSQL對于需要強一致性的應用程序或用例來說是一個糟糕的選擇：
- 計費。
- 權限管理，運營支持(電信公司)。
- ***一美元(廣告科技，游戲)。
- SLA(譯者注：Service Level Agreement 服務級別協議，提供服務的企業與客戶之間就服務的品質、水準、性能等方面所達成的雙方共同認可的協議或契約)管理，會話管理。
- 交易驗證，欺詐檢測，投標和報價管理。
- 傳感器管理。
典型的CAP定義說：你不可能同時滿足這三個特性。
一個更實際的方式來考慮CAP：面對網絡分區，您不能總是具有***的一致性和100%的可用性。 您應該相應地做出規劃。
快速請求-響應應用程序
現代請求-響應式風格的應用程序大量發生：
- 驗證用戶的余額時允許移動電話進行連接。
- 以***惠的價格交易。
- 向潛在的成千上萬的用戶展示移動廣告，而不會影響廣告客戶的廣告預算。
- 為電信運營商管理嚴格的SLA。
- 在交易批準之前檢測欺詐刷卡。
這些事件在世界各地每天發生數百萬次。 電信，金融服務，在線游戲，廣告技術等行業的供應商需要適應這些事件的變化和速度。 他們需要一個可擴展的，事務性一致的解決方案。
