Mongo DB或任何nosql DB（Hbase，Cassandra）如何可擴展，並且比傳統RDBMS具有優勢？

Question

我仍然無法實時聯系到nosql的好處，而傳統的RDBMS也有索引。 如果有人可以建議柱狀數據庫在實際應用中的優勢，特別是在使用結構，半結構化或非結構化數據方面。

Answer 1

在很大程度上，這取決於您希望數據存儲區做什么。 如果您希望能夠擴展以滿足存儲或運營需求，那么RDBMS只能帶您走遠。

它歸結你怎么能擴展以滿足需求。 RDBMS實際上只能垂直擴展。 也就是說，添加更多的RAM，添加更多的磁盤等。分布式（NoSQL）數據庫通過允許您添加更多的計算機實例，使擴展更加容易。 這稱為水平縮放。

這是使用Cassandra的示例：

假設我有一個3節點群集，並且我的鍵空間（數據庫）還配置有3的復制因子（RF）。這意味着每個節點負責100％的數據。 我加載了數據，並占用了100GB的磁盤空間（在每個節點上）。 現在，雖然我群集中可能總共有300GB的數據，但是我的數據的單個副本是100GB。

因此，我的產品團隊來找我，說他們需要將擁有的數據量增加一倍。 我知道我用200GB驅動器構建了他們的3節點集群。 如果我什么也不做，那么這些驅動器將被填滿（如果沒有，它們將不會為其他空間留出空間）。

現在由我來擴展群集以滿足他們的空間需求。 首先，將3個新節點添加到群集中（總共6個），但我將RF保留為3。這使每個節點負責50％的數據，即50GB。 當我的產品團隊加載更多數據以滿足其“加倍”要求時，每個節點應回升至約100GB。 數據的單個副本現在為200GB。 但是，由於每個節點占50％，每個200GB的驅動器仍然只有100GB。

范例2：

假設上面有6個節點的集群能夠支持每秒10,000個操作（ops）的操作負載。 我的產品團隊再次來找我，說他們在假期期間需要支持20,000個操作。 由於當前群集只能支持其中一半，因此它將在高吞吐量下阻塞，並且一個或多個節點可能崩潰。

隨着Cassandra線性擴展，實現此目標的方法是（再次）使集群大小增加一倍。 因此，我將其從6個節點增加到12個節點，同時仍保持我的RF為3。在運行了一些性能測試之后，他們驗證了它確實可以支持20,000 ops。 由於我的數據的單個副本為200GB，因此總數據占用量仍為600GB。 現在有12個節點，每個節點僅負責25％的數據，即50GB。

因此，可伸縮性是優勢。 但是如何對數據建模呢？ 分布式數據庫建模的主要思想有兩個方面：

1. 建立一個關鍵的表結構，以使其分布良好。 我們不希望每個節點上的數據量不均勻。
2. 在表上構建鍵，使其符合我們的查詢要求。

NoSQL數據庫的缺點之一是查詢模式受到限制。 為了減少網絡時間，您希望確保查詢可以由單個節點提供。

這通常意味着使用自然鍵，因為這些自然鍵更符合您對數據的要求。 代理鍵（字母鍵，數字鍵或二者兼有）分布良好，但對於查詢並沒有真正的作用。 用戶“ Bob Jones”在我的系統中的ID為“ 3582346556230”。 但是，當我想查詢Bob的數據時，我可能永遠不想用“ 3582346556230”來請求它，因為這對應用程序或使用數據的上下文沒有任何意義。

另外，您希望數據具有結構。 非結構化數據是不可查詢的數據。 就那么簡單。 如果要查詢非結構化數據，則需要解析其標識方面以用作鍵。 您不想“搜索”或運行SELECT * FROM查詢。 與NoSQL數據庫中的全數據庫掃描相比，NoSQL數據庫中的全表掃描甚至要消耗更多的資源，因為它們必須檢查每個節點，對副本進行排序，從而導致額外的網絡時間。

NoSQL數據庫使您能夠擴展（用於增加數據或需求）。 但是必須注意，它們的可伸縮性會使某些事情（RDBMS可能擅長）比以往更加困難。

Answer 2

在RDBMS中，R elational，該R是最重要的事情，從蒙戈失蹤。 有很少到沒有辦法使數據庫了解在不同的 表 收藏項的時間之間的相互關系 。 RDBMS的一大優勢是能夠定義數據庫將強制執行的約束，最常見的是外鍵約束，這些約束可確保一個表中的ID引用另一表中的現有ID。

數據庫能夠強制執行此類約束的一項要求顯然是，所有事物都必須經過一個事實來源，並且需要一個中央實體來對數據進行交叉檢查。 它不能分散，因為兩個不同的主要來源之間的差異可能導致數據不一致。

在Mongo中，每個數據Blob幾乎都是獨立的。 它不會以數據庫強制的任何方式引用其他條目。 Mongo也沒有弱到沒有ACID保證 ，這意味着幾乎沒有防止競爭條件插入或更新的保護措施。 一言以蔽之：Mongo不能保證數據的一致性，而將這些顧慮轉移到了應用層。 這使它的工作更加分散。

例如，擴展Mongo的一種好方法是擁有許多輔助服務器，這些輔助服務器復制主服務器以進行只讀訪問。 無法保證主數據庫和輔助數據庫在任何給定時間都將保持同步，寫入主數據庫的數據可能需要幾秒鍾的時間才能滴流到輔助數據庫。 但是，這使您幾乎可以擁有無​​限數量的輔助只讀服務器，這對於在高讀取負載下擴展數據庫非常有用。

Mongo專門處理其群集的方式還使它具有很高的正常運行時間，因為如果服務器發生故障，群集將自動將其自身重新組織為主服務器和備用服務器。 這甚至可以進行滾動維護，而不會導致客戶端停機。

在寫入過程中不必強制執行復雜的約束或事務一致性，還可以使操作更加“即興即忘”，從而可以更快地寫入數據庫。 再次，以允許不一致的數據為代價。 這就是為什么大多數寫作幾乎意味着在不保證其他文檔的情況下原子地更新集合中的單個文檔的原因，這與跨多個表的RDBMS事務更新是一種不同的范例。

我不建議Mongo存儲像財務分類帳之類的東西，該分類帳在很大程度上依賴於交易保證的一致性。 但是，像Twitter這樣的事情就是一個完美的例子：許多獨立的數據片段必須由大量客戶讀取。