SQL Server 2014內存優化表的使用場景

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 

本文版權歸做者全部，未經做者贊成不得轉載。