大战丰满人妻性色av偷偷,国产,三级,成人,成人国产精品免费视频

国产av日韩一区二区三区精品,成人性爱视频在线观看,国产,欧美,日韩,一区,www.成色av久久成人,2222eeee成人天堂

對錶進行分片或分區(qū)之前的限制

P粉190883225 2024-01-16 13:32:16

563

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

之類的因素

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

但是當有人問這個問題

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

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

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

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

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

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

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

P粉190883225

全部回覆(1)

P粉4019012662024-01-17 09:55:18 1樓

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

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