在 docker 上讀取多個數據庫分片是個好主意嗎？
所以我有一個具有多個 CPU 核心的伺服器，它安裝了一個數據庫。你認為如果我們用 docker 安裝多個數據庫（數據分片），那麼每個請求都會去不同的數據庫是個好主意嗎？每個數據庫中的數據都不同，並且根據來自客戶端的請求，它將在不同的數據庫上進行查詢。
我不知道這是否比包含所有數據的專用數據庫更糟糕？
分片的問題是應用程序必須知道要查詢哪個分片。通常，這是通過在諸如客戶端之類的東西上分片來完成的。我將改編我的一篇舊部落格文章作為我的答案。
當您為大量客戶建構應用程序時，有兩種常用的數據庫設計方法：
- 選項 A：將所有客戶端放在同一個數據庫中
- 選項 2：為每個客戶端建構一個數據庫
將所有客戶端放在同一個數據庫中
這很簡單：只需在模式頂部添加一個 Client 表，添加一個 ClientUsers 表以確保人們只能看到他們自己的數據，然後我們就走了。
這種方法的好處：
**更容易的模式管理。**當開發人員部署新版本的應用程序時，他們只需在一個數據庫中進行架構更改。不用擔心不同的客戶不同步或使用錯誤的版本。
**更容易的性能調整。**我們可以在一個地方檢查索引使用情況和統計數據，輕鬆實施改進，並立即查看所有客戶的效果。對於成百上千的數據庫，即使是最小的更改也可能難以協調。我們可以檢查我們的過程記憶體內容並確定哪些查詢或儲存過程在我們的整個應用程序中是最密集的，而如果我們為每個客戶端使用單獨的數據庫，我們可能會更難在不同的執行計劃中聚合查詢使用。
**更容易建構外部 API。**如果我們需要授權外部人員訪問我們的整個數據庫來建構產品，如果所有數據都在一個數據庫中，我們可以更輕鬆地做到這一點。如果 API 必須處理來自多個伺服器上的多個數據庫的數據分組，它會增加開發和測試時間。（另一方面，“多台伺服器”的概念開始暗示一個數據庫管理所有場景的限制：一個數據庫通常意味著我們所有的負載只影響一個數據庫伺服器。）
**更輕鬆的高可用性和災難恢復。**如果我們只需要擔心一個數據庫，那麼管理數據庫鏡像、日誌傳送、複製和集群真的非常簡單。我們可以快速建立一個基礎設施。
將每個客戶端放在自己的數據庫或分片中
您仍然需要一個客戶端列表，但現在它變成了一個目錄 - 對於每個客戶端，您還可以跟踪它所在的分片。在啟動時，您的應用程序會查詢此表，並將其記憶體在 RAM 中。當它需要客戶端的數據時，它直接連接到該分片（數據庫和伺服器）。
這種方法的好處：
**更輕鬆的單客戶端還原。**客戶是不可靠的肉袋。（除了我的——他們是可靠的肉袋。）他們有各種各樣的“糟糕”時刻，他們想將所有數據檢索到某個時間點，如果他們的數據與同一表中的其他客戶數據。單客戶端數據庫場景中的還原非常簡單：只需還原客戶端的數據庫。沒有其他人受到影響。
**更輕鬆的數據導出。**客戶喜歡掌握他們的數據。他們希望知道自己可以隨時獲取數據的安全性，避免可怕的供應商鎖定場景，並且他們希望自己進行報告。將每個客戶的數據隔離到他們自己的數據庫中，我們可以簡單地給他們一份自己的數據庫備份副本。我們不必建構數據導出 API。
**更輕鬆的多伺服器可擴展性。**當我們的應用程序需要比我們從單個伺服器獲得的更多的功率時，我們可以在多個伺服器之間劃分數據庫。我們還可以在地理上分散負載，將伺服器放在亞洲或歐洲更靠近客戶。
**更輕鬆地調整每個客戶端的性能。**如果某些客戶使用不同的功能或報告，我們可以為這些客戶建構一組專門的索引或索引視圖，而不會增加每個人的數據量。誠然，這裡有一些風險——通過允許客戶端之間的模式差異，我們只是讓我們的程式碼部署風險更大，我們的性能管理更加困難。
**更輕鬆的安全管理。**只要我們正確地鎖定了每個數據庫一個使用者的安全性，我們就不必擔心客戶端 X 訪問客戶端 Y 的數據。但是，如果我們只為每個人使用一個登錄名，那麼我們還沒有真正解決這個問題。
更容易的維護視窗。 在客戶分散在全球的全球環境中，如果我們可以分組或分區進行維護，則更容易讓客戶下線進行維護。
哪一個適合你？
沒有一個正確的選擇：您必須了解自己公司的優勢和劣勢。讓我們以我的兩個客戶為例。
A公司擅長硬體性能調整。他們非常非常擅長從硬體中榨取最後一點性能，而且他們不介意以 12-18 個月的周期更換 SQL Server 硬體。（他們每 4-6 個月刷新一次 Web 伺服器！）他們的致命弱點是極端的合規性和安全性要求。他們有令人難以置信的審計需求，對他們來說，在單個伺服器、單個數據庫上實施防彈控制要比在數十台伺服器上的數千個數據庫中管理這些要求更容易。他們選擇了一個數據庫、一台伺服器、許多客戶端。
公司 2 擅長開發實踐。跨數千個數據庫管理模式更改和程式碼部署對他們來說不是問題。他們在世界各地都有客戶，他們全天候為這些客戶處理信用卡交易。他們需要在地理上分散負載的能力，並且他們不想每 12-18 個月更換一次世界各地的伺服器。他們為每個客戶選擇了一個數據庫，當他們開始在亞洲和歐洲為他們的離岸客戶安裝 SQL Server 時，它得到了回報。