幾個較小的一個大型SQL服務器表？

我有一些設計問題要問。幾個較小的一個大型SQL服務器表？

假設我有一些TBL_SESSIONS表，其中我保留每個登錄的user-id和一些Dirty-flag（表明他擁有的內容是否已被更改，因爲他得到了它）。

現在，該表格應該每隔幾秒就由該登錄用戶每隔幾秒詢問一次，即該表格上有很多讀取調用，並且該Dirty-flag也有很大改變。

假設我期望許多用戶同時登錄。我想知道是否有任何理由創建像說10個這樣的表並讓用戶在這些表之間分發（根據他們的用戶id）。

我從兩個方面提出這個問題。首先，就性能而言。其次，在可擴展性方面。

我很想聽聽你的意見

來源

2014-02-06 dsb

請定義「llarge」。幾十億行？因爲低於1億的東西應該是一個完全沒有問題的東西（除非你認爲這是數據 - 許多開發者可悲地做）。 25年前，一百萬行很大，今天很小。 – TomTom

假設有100萬行（這意味着有100萬用戶登錄） – dsb

哎呀..我在回答之前沒有收到完整的消息。那麼，你是說，每隔幾秒鐘至少讀取一行100萬行的表格不是問題嗎？ – dsb

如果你有很多的記錄，比如數十億，以及你的服務器無法處理的高負載，那麼擁有多個表格會讓你感到驚訝。這樣你就可以執行分片 - >將不同的服務器拆分成幾個表。例如。在服務器A（id爲1到100 000 000），接下來的1億在服務器B（100 000 001到200 000 000）等等上有第一億條記錄。其他方式 - 有相同關於的數據不同和查詢數據通過某種平衡器，這可能會更困難（複製不是RDBMS的關鍵特性，所以它取決於引擎）

來源

2014-02-06 11:45:55 Sergio

在您的示例分片計劃中，您將所有新用戶加載到單個分片上。這聽起來不像一個好計劃。 –

對於1米行使用單個表。

使用正確的索引訪問時間不應該是一個問題。如果您使用多個分佈在其中的用戶，則需要進行額外的處理以找到要讀取/更新的表。

另外，您將爲每個表分配多少用戶？當用戶數量增長時會發生什麼......添加更多表格？我想你最終會遇到維修噩夢。

來源

2014-02-06 11:45:48 Tony

在沒有更多信息的情況下，這當然應該是缺省方法。 –

幾個較小的一個大型SQL服務器表？

回答

相關問題