真正的大型應用程序（例如 facebook）如何擴展其數據庫
我很好奇如何擴展大型數據庫，例如 facebook DB。我所知道的是應用程序以某種方式部署到多個數據中心，這意味著每個數據中心中的每個“節點”都應該能夠快速訪問那個大數據庫。
首先，我無法想像它們是如何部署的，但這是另一個問題（我猜？）。
因此，如果我沒記錯的話，那麼問題是如何有這麼多獨立的節點訪問龐大的數據庫，並且一切都是一致的、穩定的、性能良好的和可擴展的？
免責聲明：我對這個主題的了解不如我想的那樣，請隨時編輯我的錯誤；我做了一些自願的捷徑以避免從頭開始重寫維基百科
好吧，讓我們縮小一點：你是一個成功的應用程序製造商，你每天必鬚麵對幾千個使用者。
這是你進入大男孩世界的第一步，也是最重要的問題：
你在用你的數據做什麼？
從這個問題中，你的整個架構將被選擇，它可能會決定事情的順利進行（還記得pokemonGo 的發布嗎？在這一點上是一個很大的失敗）。
- 我們只有少量寫入（了解要儲存的輸入數據），但讀取量非常大。
然後，您將使用單個/小型主數據庫集群（大型 R-DBMS或“任何”分佈式No S ql）和許多副本作為從屬（只讀）或全球記憶體內容傳遞網路-CDN。這非常適合像新聞這樣的網站（評論部分在另一個服務上，見下文）。
- 我們以更經典的比率讀/寫
你排除第一個選項。記憶體會有所幫助，但還不夠，而且 R-DBMS 開始變得非常昂貴，因為您需要一個具有分佈式寫入的大型集群（而不是單個主伺服器）。您很可能會使用一些NoSQL解決方案。您仍然應該能夠使用大多數經典的，因為這就是它們被創建的原因。您將擁有一個完整的主副本池或一個強大的主副本和一個從屬完整副本的池。
- 你對你的“讀多於寫”的事情很有趣，我即將讓 Twitter 停業，並且讀起來的寫幾乎更多……
好的，真正的問題來了，這個問題使 R-DBMS 無法解決，並讓一群工程師做噩夢……“我們如何處理每微秒的寫入，而讀取可能是 0 到 Katy Perry 的1億粉絲？”
答案是“不像我們想的那麼容易”。更嚴重的是，訣竅是“分佈式數據”。您找到一種方法來區分您的數據並在每個儲存實例中僅儲存一小部分數據（請注意，我在這裡甚至沒有真正使用“DB”，它是 NoSql 的陰暗面，它幾乎可以生存它自己的，只是像“文件系統”一樣面對世界。所以現在你有一個規則來將你的數據儲存在不同的小實例上。很好。有趣的部分是“我們如何讓它們回來？”並且這很重要。寫很“容易”，但讀意味著你必須讓一些伺服器成為“事物所在位置的前索引”，一個通往正確儲存空間的路由網關，但知道數據在哪裡不是唯一需要擔心的。
Katy Perry 回來了，隱藏您的數據庫，隱藏您的伺服器……您現在可以跨整個數據中心保存和檢索您的數據。關鍵是，現在每一行都儲存為具有 2 個冗餘節點的“正常使用”，如果這一行病毒式傳播，這還不夠。在最終使用烤麵包機而不是伺服器之前，您必須使用動態記憶體和/或節點複製。你問“什麼”？好吧，與Ant 算法一樣，您必須對數據施加一些權重：
- 誰在發帖？
- 凱蒂佩里
好的，至少在接下來的幾週內，我們可能會將它們儲存在 3 個以上的節點中……
什麼鬼，這條 D. Trump 2013 年的推文今天在網上瘋傳
即使作者和日期似乎不能證明比預設分配更多的節點是合理的（我是不是完全政治化了？我的錯……），流行度將觸發記憶體機制並臨時傳播到其他節點以匹配要求。
對於這個解決方案，我一步一步地解釋了它是如何工作的，但是具有良好配置的 DBMS 將為您完成。
如您所見，即使我們只是快速瀏覽一下如何處理“大”，也有很多話要說。請記住，這些解決方案中的大多數（全部？）都是從他們解決的問題中發展而來的：每家大公司都根據他們的案例製作自己的 DBMS。NoSQL 產品只是這些公司為解決定制解決方案需求所做的工作的公開發布。