對錶進行分片或分區之前的限制

Question

我是資料庫系統設計的新手。在閱讀了很多文章後，我真的很困惑我們應該有 1 個表格而不進行分片或分區的限制是多少。我知道提供通用答案確實很困難，事情取決於諸如

之類的因素

• 行的大小
• 資料型別（字串、blob 等）
• 活躍查詢數量
• 什麼樣的查詢
• 索引
• 重讀/重寫
• 預期延遲

但是當有人問這個問題

• 如果每天有 10 億個資料和數百萬行添加，您會怎麼做？對於如此大的資料庫，4 次讀取、1 次寫入和 2 次更新查詢的延遲需要低於 5 毫秒。
• 如果您只有 1000 萬行，但更新和讀取量很高，您會選擇什麼？新增的新行數並不重要。高一致性、低延遲是要求。

如果行數少於一百萬，並且行大小增加數千，那麼選擇很簡單。但當選擇涉及數百萬或數十億行時，事情就會變得更加棘手。

注意：我在問題中沒有提到延遲數。請 根據您可以接受的延遲數回答。另外，我們正在討論結構化資料。

我不確定，但我可以添加 3 個具體問題：

• 假設您為亞馬遜或任何電子商務訂單管理系統選擇 SQL 資料庫。訂單數量每天都在以百萬計的速度增加。已經有10億筆記錄了。現在，假設沒有資料存檔。每秒有超過一千個查詢的高讀取查詢。並且也有寫入。讀：寫比例為100：1
• 讓我們舉一個現在較小的數字的例子。假設您為 abc 或任何電子商務訂單管理系統選擇 SQL 資料庫。訂單數量每天都在增加數千。已經有1000萬筆記錄。現在，假設沒有資料存檔。每秒有超過一萬個查詢的高讀取查詢。並且也有寫入。讀寫比例為10:1
• 第三個範例：免費贈品分發。我們有1000萬件好東西要分發。每個使用者 1 件好東西。高一致性、低延遲是目標。假設已經有 2000 萬用戶在等待免費分發，一旦時間開始，他們所有人都會嘗試獲得免費的好東西。

注意：在整個問題中，假設我們將選擇 SQL 解決方案。另外，如果提供的用例在邏輯上沒有意義，請忽略。目的是獲取數字方面的知識。

有人可以幫忙了解基準是什麼嗎？您目前正在從事的專案中的任何實際數字都可以表明，對於具有如此多查詢的大型資料庫，這就是觀察到的延遲。任何可以幫助我證明針對特定延遲的一定數量的查詢選擇表數量的合理性的任何東西。

Answer 1

MySQL 的一些答案。由於所有資料庫都受到磁碟空間、網路延遲等限制，其他引擎可能類似。

• 無論行數有多少，「點查詢」（使用適當的索引取得一行）都需要幾毫秒。
• 寫一個需要數小時甚至數天才能運行的SELECT是可能的。所以你需要了解查詢是否是這樣病態的。 （我認為這是高“延遲”的一個例子。）
• 當您無法維持單一伺服器上所需的寫入數量時，就需要「分片」。
• 透過使用複製並將讀取傳送到副本，可以「無限」擴展大量讀取。
• PARTITIONing（尤其是在 MySQL 中）的用途很少。更多詳細資訊：分區
• INDEX 對於效能非常重要。
• 對於資料倉儲應用，建置和維護「匯總表」對於大規模效能至關重要。 （其他一些引擎有一些內建的工具。）
• 每天插入一百萬行不是問題。 （當然，有些模式設計可能會導致這個問題。）經驗法則：100/秒可能不是問題；1000/秒可能是可能的；之後就變得更難了。更多關於高速攝取
• 網路延遲主要取決於客戶端和伺服器的距離。到達地球的另一邊需要超過200毫秒。另一方面，如果客戶端和伺服器位於同一棟建築物內，則延遲會低於 1 毫秒。另一方面，如果您指的是執行查詢需要多長時間，那麼這裡有一些經驗法則： 對於需要命中 HDD 磁碟的簡單查詢，需要 10 毫秒； SSD 為 1 毫秒。
• 如果資料太大而無法快取在 RAM 中，UUID 和哈希值對效能非常不利。
• 我沒有提及讀/寫比，因為我更喜歡獨立判斷讀寫。
• 「每秒萬讀」很難實現；我認為很少有應用程式真正需要這樣的。或者他們可以找到更好的方法來實現相同的目標。一個使用者發出查詢的速度有多快？也許每秒一個？有多少用戶可以同時連線和活動？數百個。
• （我的觀點）大多數基準測試都是無用的。一些基準測試可以顯示一個系統的速度是另一個系統的兩倍。所以呢？一些基準測試表明，當您有超過數百個活動連接時，吞吐量就會停滯，並且延遲會趨於無窮大。所以呢。當應用程式運行一段時間後，捕獲實際查詢可能是最好的基準。但它的用途仍然有限。
• 幾乎總是單一表比拆分錶（多個表；分區；分片）更好。如果您有具體的例子，我們可以討論一下表格設計的優缺點。
• 行的大小和資料類型－大列（TEXT/BLOB/JSON）被「不記錄」存儲，從而[可能]導致額外的磁碟命中。磁碟命中是任何查詢中成本最高的部分。
• 活躍查詢－幾十次之後，查詢就會互相衝突。 （想像雜貨店裡有很多推著購物車的購物者——「太多」的購物者，每個人都需要很長時間才能完成。）

當您進入大型資料庫時，它們分為幾種不同的類型；每個都有一些不同的特徵。

• 資料倉儲（感測器、日誌等）－附加到表格的「結尾」；高效率「報告」的總表；龐大的「事實」表（可選擇分塊存檔）；某些「維度表」。
• 搜尋（產品、網頁等）－EAV 有問題；全文通常很有用。
• 銀行業務、訂單處理 - 這對 ACID 功能和處理交易的需求非常重要。
• 媒體（圖像和影片）--如何儲存龐大的對象，同時讓搜尋（等）相當快。
• '找到最近的' - 需要一個 2D 索引，SPATIAL 或一些技術 此處
##