在單個數據庫服務器上的多個數據庫上分割用戶數據

Question

我是一名自學成才的程序員，我一直在遵循一些基於常識的設計參數，而不是研究構建可擴展的系統。但是，我剛剛意識到我的系統的一個組件可能不是必需的。

一般來說，我將用戶數據分成組並分配給特定的mysql服務器。當負載均衡器後面的內容服務器收到請求時，我使用請求中的數據（如用戶標識）通過查詢存儲在DynamoDB上的中央表來解析存儲該用戶數據的數據庫，從而可以處理瘋狂的負載量。

但是，我也將用戶數據分配給服務器內的數據庫。就像我將在每臺服務器中有100個數據庫都具有相同的表結構，並且我將爲每個數據庫分配250個用戶。

最初的邏輯是，每個用戶有2k個條目的表將比500萬個條目更快地運行500k條目。但是，我想到以這種方式分解用戶數據可能沒有任何意義。 索引非常高效。我確定數據庫實際上有某種內部邏輯，它允許它以基本相同的速度訪問數據？我已經這樣做了十年，而我剛剛意識到這可能根本就沒有必要。有什麼想法嗎？我可以只用一個數據庫來創建我的所有表格，還是應該按照我以往的方式繼續進行操作，在服務器上分割100個數據庫？

Answer 1

這是一個有點理論，所以它可能是值得理解Big-O complexity又名時間複雜性的想法。

單個項目的聚集B樹索引查找是O（log（n）），其中n是表中的行數。 DynamoDB是一個基於散列的實現，它更接近於O（1），這意味着它的性能不會隨內容大小而發生明顯變化。

現在對於數學，log（500k）= 5.7，其中log（50mil）= 7.7只要避免命中磁盤以將索引加載到內存中，單行查找的比例就非常好。

所以，你說的是單行查找25％的差異。這是重要的，但仍然可能低於往返另一個數據庫系統（如DynamoDB）的開銷。

當然，您的里程可能會有所不同，因爲有關於將索引保存在內存等方面的擔憂......所以您可能會發現生產環境存在差異。我強烈建議設置一個測試，並驗證你的性能。