EntityFramework Core 5.0 VS SQLBulkCopy
【導讀】EF Core 5.0伴隨著.NET 5.0發布已有一段時日,本節我們來預估當大批量新增數據時,大概是多少區間我們應該考慮SQLBulkCopy而不是EF Core
SQLBulkCopy早出現于.NET Framework 2.0,將數據批量寫入利用此類毫無疑問最佳,雖其來源任意,但此類僅適用于SQL Server,每個關系數據庫都有其批量處理驅動,這里我們僅僅只討論SQL Server
性能差異預估批量數據大小
首先給出我們需要用到的測試模型
public?class?User {public?int?Id?{?get;?set;?}public?string?Name?{?get;?set;?}public?DateTime?Birth?{?get;?set;?}public?string?Email?{?get;?set;?}public?string?Phone?{?get;?set;?} }接下來我們則需要模擬數據,為偽造實際生產數據,這里我們介紹一個包Bogus,此包專用來偽造數據,一直在更新從未間斷,版本也達到32,如下:
此包中有針對用戶類的模擬,具體使用這里就不詳細展開,我們構造一個方法來偽造指定數量的用戶數據,如下:
有了批量偽造數據,接下來我們再利用上下文去新增數據,然后分別打印偽造數據和新增成功所耗費時間,如下:
[HttpPost] public?async?Task<IActionResult>?GenerateInsert([FromQuery]?int?count?=?1000) {var?s?=?new?Stopwatch();s.Start();var?users?=?GenerateUseres(count);var?gererationTime?=?s.Elapsed.ToString();s.Restart();await?_context.Users.AddRangeAsync(users);var?insertedCount?=?await?_context.SaveChangesAsync();return?Ok(new{inserted?=?insertedCount,generationTime?=?gererationTime,insertTime?=?s.Elapsed.ToString()}); }新增100條數據太小,這里我們直接從批量1000條數據開始測試,此時我們將看到所存儲數據和實際數據完全一毛一樣
通過SQL?Server Profiler工具監控得到如下一堆語句
通過運行多次,當然也和筆記本配置有關(i7,6核12線程,內存16G),但還是可以預估批量新增1000條大概耗時為毫秒級,如下:
接下來我們試試新增1萬條看看,耗時基本需要1秒,如下:
最后我們再來試試新增十萬條數據試試,大概需要14秒才能完成
到了這里想必我們沒有必要再往上增長數據,我們來看看利用SqlBulkCopy又將如何
因如上利用EF Core新增時間在毫秒級,那么我們則直接從新增1萬條開始測試,如下我們可看到此時與EF Core新增1萬條數據差異,耗時遠遠小于1秒
最后我們再來測試10萬條,很顯然EF Core耗時結果將為SqlBulkCopy的指數倍(大致14倍,若數據為100萬,想想二者其性能差異),如下:
若繼續通過SQL Server Profiler監控工具查看SQL語句,很顯然SQL語句會很簡短,據我所知,SqlBulkCopy是直接將數據通過流形式傳輸到數據庫服務器,然后一次性插入到目標表中,所以性能是杠杠的。
利用SqlBulkCopy和EF Core 5.0,當然理論上不論是EF Core更新到其他任何版本,其性能與SqlBulkCopy不可同日而語,本文我們只是稍加探討下數據量達到多少時不得不考慮其他手段來處理,而不是利用EF Core新增數據
??????EF Core和SqlBulkCopy性能差異比較,毫無疑問SqlBulkCopy為最佳選手
?????當新增數據量達到1萬+時,若需考慮性能,可采用SqlBulkCopy或其他手段處理數據而不再是EF Core,二者性能差異將呈指數增長
總結
以上是生活随笔為你收集整理的EntityFramework Core 5.0 VS SQLBulkCopy的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 在 k8s 中部署 Prometheus
- 下一篇: 小心使用 Task.Run 续篇