可擴展的數據庫技術和架構

Question

我一直在嘗試了解有關分布式系統中數據庫擴展的更多信息，並且我陷入了RDBMS和NoSQL之間。

在線上的一些文章建議NoSQL是現代大數據的解決方案。 還有人說，NoSQL只是一種炒作，RDBMS可以通過良好的設計進行擴展，並提供良好的數據結構。

我不想閱讀別人的意見，而是想自己判斷兩者，但是我不完全了解可伸縮的RDBMS和可伸縮的NoSQL的要求。

我已經對RDBMS進行了更多閱讀，似乎該解決方案需要利用內存緩存和分片來減小數據庫大小和數據庫查詢數量。 還有其他技巧嗎？ 您是否仍可以使用具有許多列的表？ 還是使用更少的列和更多的聯接？

至於NoSQL，我已經閱讀了一些有關MongoDB的內容。 我了解它鼓勵數據聚合。 但是，這如何使其更具可擴展性呢？ 我也開始學習Cassandra，因為我讀到它的可擴展性比MongoDB好得多，但是我不知道它的可擴展性如何。

對於擴展RDBMS和NoSQL的基本的（簡明的，如果您有耐心的話，可以是高級的）簡明扼要的解釋，或者在線上很好的文章或解釋該主題的書籍，我將不勝感激。 :)

Answer 1

我不會介紹通過自行實現並在其之間放置內存緩存服務器來進行擴展的方式，...我只是介紹了開箱即用的內容...

讓我們首先從RDBMS開始：

我認為建立RDBMS集群比NoSQL集群更為復雜，但這只是我的觀點。 通常，您擁有一個主設備和多個從設備。 您必須將所有寫入發送到主服務器，並且可以從任何所需的從服務器讀取。 由於您具有RDBMS和ACID，因此系統應以某種方式向您保證，您不會讀取舊數據。 因此，這里的事情是，您假設應用程序只編寫一次並且經常讀取（通常是這種情況）。 出於這些目的，一台用於讀取/寫入的服務器和多台用於讀取的服務器非常好。 問題是，如果您寫得太頻繁，以至於無法在一台機器上跟上它們。 那是你的瓶頸。 除了巨大的Oracle內置解決方案外，還有http://www.scalearc.com/ ，它可以緩存查詢，...並為您處理擴展。

NoSQL ：

沒有所有數據庫都實現的1 NoSQL模式。 每個系統都有點不同。 例如，MongoDB與RDBMS非常相似，它也只有一個主服務器和幾個從屬服務器，可以向其復制數據，但是您還可以創建分片。 數據在分片之間拆分，然后復制到從屬設備。 因此，您可能有多個不同的母版，它們負責較小的零件。 之后，當您閱讀時，您可以選擇是否要從多個從屬設備，從主機或任何從屬設備進行讀取-取決於您是否急需最新數據。

另一方面，Cassandra的工作方式完全不同。 我不確定是否可以寫入多個服務器或其工作方式，但是基本上服務器會保留所有寫入的日志。 因此，即使他們不能立即處理寫入，它們也存儲在日志中，仍然可以為您提供快速響應。 然后，當您閱讀時，您可以再次說出您想要新數據的緊急程度，如果您確實想要最新的數據，Cassandra將需要檢查日志，如果有任何更新寫入，這將使您花費很多時間。很多時間。

鍵值存儲（例如ElasticSearch，CouchDB，CouchBase）再次以不同的方式工作。 在這里，該項目的進行了散列，並基於散列被發送到將對此負責的一個節點。 這樣，當您在寫入密鑰后進行讀取時，您將再次獲得最新信息，因為您將從同一節點讀取數據。 這種設計的思想是，沒有一個鍵會是每個人的興趣，而是負載將被分配。 這些數據庫也是我認為可以最佳擴展的數據庫，並且使向集群添加更多服務器最容易，但是卻失去了復雜查詢的功能，就像在MongoDB和Cassandra中擁有它一樣，當然還有RDBMS。 ElasticSearch具有一些簡單的搜索查詢，而CouchDB和CouchBase僅具有由MapReduce生成的View，如果適合該視圖，則可以在其中獲取所需的數據。 否則，您只能通過密鑰訪問它。

http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis-對最常見的NoSQL DB，它們的優缺點和最常見的使用場景進行了非常全面的總結。

---

最后，問題還是，為什么要擴展？ 您將在數據庫中擁有幾條記錄？ 幾百萬根本不是問題。 對於足夠強大的服務器上的大多數RDBMS，幾億美元也不是問題。 如果正確設計數據庫及其索引，那么每年甚至十億條記錄也應該可以。