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 

本文版權歸作者所有，未經作者同意不得轉載。