如何處理每秒約 1k 次插入
假設一個人每秒有大約 1k 個請求需要插入。
現在，網際網路上有很多關於這個問題的答案……但在這個特定的背景下，它們在技術上是錯誤的。是的，幾乎任何 RDBMS 都可以在標準硬體上每秒處理 1k 次插入，但如果且僅當您放棄 ACID 保證時。令人驚訝的是，網際網路上有多少可怕的答案。例如“你總是可以擴展 CPU 和 RAM”，這應該會給你每秒更多的插入，但它不是這樣工作的。限制因素是磁碟速度或更精確：您實際上可以將多少事務刷新/同步到磁碟。這是棘手的一點。
在體面的“商品硬體”上（除非您投資於高性能 SSD），這是您可以期待的：
- SQLite：30 次插入/秒
- MySQL：80 次插入/秒
這是您在保持 ACID 保證的同時可以插入的速率。這實質上意味著，如果您有一個每秒有 100 個文章的論壇……您無法通過這樣的設置來處理它。
讀取請求不是問題。每秒可以有數千個讀取請求，但寫入請求通常小於每秒 100 個。
因此，這個問題專門針對如何在保持 ACID 保證的同時每秒處理 1k 次插入 - 假設單個節點每秒可以處理大約 80 個事務。
我可以看到這種工作的一種方法是，如果您在應用程序邏輯中的某處緩衝插入並將它們作為較大的事務送出到數據庫（同時讓客戶端等待事務結束），如果您只需要單個插入，這應該可以正常工作，儘管它很複雜應用程序邏輯相當多。
我的簡單 RAID 10 陣列在具有 300GB SAS 磁碟的舊硬體上執行，每秒可以處理 200-300 次插入，沒有任何問題；這是在 VM 上執行 SQL Server，同時執行許多其他 VM。
僅使用消費級 SSD，您可以預期每秒 3,000 到 5,000 或更多的 4K I/O。
你的問題到底是什麼？
這
這實質上意味著，如果您有一個每秒有 100 個文章的論壇……您無法通過這樣的設置來處理它。
根本不正確。您缺少的是多個使用者可以在每次日誌刷新中將更改排入隊列。因此，雖然每次日誌刷新需要 10 毫秒，但它可以強化數十或數百個單獨的並發事務。
打個比方：每小時來回一趟的火車，每小時可以載人遠多於 1 人。
在 SQL Server 中，並發會話將全部寫入日誌緩衝區，然後在送出時等待確認其 LSN 是否包含在後續日誌刷新中。
假設您的日誌磁碟具有 10ms 的寫入延遲和 100mB/s 的最大寫入吞吐量（單個旋轉磁碟的保守數字）。如果每個事務需要 100kB 的日誌空間（大），您可以在磁碟上每秒刷新 1000 個事務，只要您有至少 10 個使用者隨時等待送出事務。