SQL Server 2014記憶體優化表的使用場景
最近一個朋友找到走起君,咨詢走起君記憶體優化表如何做高可用的問題
大家知道,記憶體優化表作為In-Memory OLTP功能是從SQL Server 2014開始引入,用來對抗Oracle 12C的In-Memory OLTP選件
不過SQL Server的In-Memory OLTP功能是完全内置的功能,不像Oracle需要額外付費才能獲得
由于是比較新的技術,可能大家對記憶體優化表還是比較陌生,網上也鮮有記憶體優化表使用場景的文章
朋友公司做的業務是跟蜂鳥配送類似的配送業務,整個配送系統平台每天訂單量超過30W
坐标問題
系統中某一個部分需要儲存跑男的坐标
坐标需要儲存到redis和資料庫,一旦坐标更新也需要更新redis中的資料
剛開始朋友用傳統表來儲存坐标資料,但是很快遇到問題,傳統表在更新的速度跟不上
後來改用記憶體優化表,使用了之後
剛開始上傳坐标的接口,延遲很大,用了記憶體表,100毫秒以内,搞定
這些坐标是需要持久化的,而記憶體優化表是完全支援ACID的,是以也不需要擔心資料丢失的問題
記憶體優化表更新速度快的另一個原因:無鎖機制, 并發(如闩鎖争用或阻塞)影響的應用程式遷移到記憶體中 OLTP 時,其性能會顯著提高。
大家知道,記憶體優化表需要有一個非聚集哈希主鍵索引,大概的表結構是
每個跑男占用一行記錄
對應到redis裡面大家應該都知道怎麽存儲了吧,使用redis的散列類型來存儲跑男的坐标
hmset 跑男ID X坐标 value Y坐标 value 跑男線上時間 value
hmset 1 X坐标 12 Y坐标 10 跑男線上時間 60
因為資料庫高可用的問題,朋友就購置了新伺服器,用來搭建AlwaysOn,新伺服器都用SSD固态硬碟
記憶體優化表的瓶頸主要在事務日志固化,雖然有延遲持久化,但是延遲持久化在意外當機的時候可能丢失部分資料
現在新伺服器使用SSD固态硬碟之後,事務日志固化的瓶頸基本消失
使用新伺服器之後,支撐30w/日訂單是完全沒有問題的
另一個問題是AlwaysOn問題
實際上,SQL Server 2014的AlwaysOn叢集已經支援記憶體優化表,隻是不支援在輔助副本上查詢記憶體優化表資料,在故障轉移之後
輔助副本上的記憶體優化表資料是完全沒有丢失的,SQL Server 2016對AlwaysOn叢集的記憶體優化表做了改進,支援在輔助副本上查詢記憶體優化表資料
總結
實際上,如果大家對記憶體優化表研究比較深入的話,記憶體優化表實際上相當于把redis嵌入到SQL Server,再在上面加上事務等關系型資料庫特性
因為兩者實作的底層都是哈希表
注意:記憶體優化表跟redis一樣,是純記憶體操作的,是以機器記憶體不能太小,SQL Server在啟動時候會把記憶體優化表資料庫檔案
裡面的資料全部load入記憶體,朋友的redis伺服器和SQL Server伺服器都用的256G記憶體,記憶體還算足夠
這篇文章寫得比較粗糙,最後祝大家新年快樂!
參考文章
http://www.cnblogs.com/lyhabc/p/3691911.html
http://www.cnblogs.com/lyhabc/articles/4230547.html
https://msdn.microsoft.com/en-us/library/dn635118(v=sql.120)
如有不對的地方,歡迎大家拍磚o(∩_∩)o
本文版權歸作者所有,未經作者同意不得轉載。