日前,SQL Server Team發佈了一款輕量、跨平台且免費的SQL Server資料庫開發和操作工具,
名為SQL Server operations studio,不管你的SQL Server是在docker、windows、linux、azure、mac,
一律爽快支援。
日前,SQL Server Team發佈了一款輕量、跨平台且免費的SQL Server資料庫開發和操作工具,
名為SQL Server operations studio,不管你的SQL Server是在docker、windows、linux、azure、mac,
一律爽快支援。
分享個人使用In-Memory OLTP注意事項和技巧
SQL2014開始,Memory table的交易處理,有最大相依交易8的數量限制,只會發生在驗證和commit階段,
一般來說In-Memory的交易過程是非常短暫的,但這並不表示你的交易就不會失敗,
實務上,我一定會簡化Memory資料表相依(複雜)性,
雖然SQL2016 In-Memory table支援很多功能(FK、trigger、LOB..),但這不代表一定有效率。
之前將old sp移轉至native compiled sp時,
執行SP有2點需要注意,因為對執行效能有一些影響。
之前評估現有相關disk table,移轉至In-Memory table需多少記憶體,
我得老實說這還真的無法準確評估,因為未來資料成長量是一個主要因素,
其次則是讀寫頻率也讓人困擾。
Columnstore indexes主要可以改善大量scan/aggregate操作(可達10倍),
因為採用xVelocity壓縮儲存方式(但無法對in-memory table壓縮),
可大大節省disk space(壓縮大約10倍以上,取決於資料表中所有資料型別),
所以和傳統row存放方式不同,通常會在fact table上建立來改善Data Mart/Data Warehouse彙熜效能。
In-Memory table在Query performance方面表現如何呢?我用這篇來記錄我一些簡單測試。
之前我寫過一篇使用In-memory table variables來提高交易效能,這篇記錄當時一些額外測試。
我想有在玩資料分析的朋友對於jupyter一定不陌生,它是一款open source的網頁版Machine Learning Analytics tools,
透過這套工具,你可以快速又方便進行資料分析、跑跑演算法,實作視覺化,而他也是iPython的前身,
至於切分出該專案,主要是因為iPython想更專注在shell的核心開發(shell真的很強大),
所以把其他元件都往Jupyter 專案集中,但我想我應該會喜歡web介面。
這篇來看看如何批次匯入event data
上一篇我安裝了PredictionIO的推薦引擎,這篇來看看如何透過RESTFul API or C#來使用該推薦引擎
Apach PredictionIO是一個用scala語言編寫的open source,
提供RESTFul API幫助我們方便使用recommendation engine,
也有提供client SDK如Java、Python,PHP,同時也是一個可擴展的Machine Learning應用(支援Spark MLib),
並提供各種Engine模板、演算法..等,也相當容易和Spark、MLlib、Hbase、MySQL、Hadoop、Elasticsearch搭配,
簡化並加速可擴展Machine Learning基礎建置管理,透過PredictionIO我們可以從零開始並快速建立一個推薦引擎。
Disk的checkpoint主要是將記憶體中的dirty pages和交易紀錄資訊寫入disk,
所以dirty pages的數量和checkpoint作業時間為線性關係,SQL Server會自動調整checkpoint作業頻率(預設60秒),
這樣做是要降低其他應用程式所受到的效能影響,如果減少頻率,則會拉長完成時間,
增加頻率,則會影響效能(資料庫一般I/O活動會大幅增加),
如果沒有特別理由,建議由SQL Server自行決定checkpoint頻率。
當你建立In-Memory table和index時,你無須考慮non-index key 的欄位,
因為In-Memory世界都是Cover query。
設定錯誤的Maximum Server Memory導致無法啟動SQL Server,
解決該問題大約只要3秒鐘。
Native compiled SP效能真的很吸引人,改寫上說麻煩也不麻煩,
但有時候確實也很麻煩,但改寫後的效能結果目前還不曾讓我失望。
使用者在網頁點擊按鈕,難免會不小心點了兩次以上,
如果這是一個heavy query(like report),一來浪費SQL Server資源,假如該SP又包含一些資料邏輯處理更新,
那麼也有可能發生資料不一致的情況,我們來看看如何從SQL Server下手來預防這狀況。
Kafka practical experience
Grafana introduction
使用該選項時,請注意你的tempdb有足夠空間,並且也和User DB分開存放。