RiCo技術農場

之前評估現有相關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分開存放。

LinkedIn幫Kafka做了很多吞吐量效能測試，他們以RabbitMQ benchmark為範本來進行一連串的效能測試，

單一producer、100 bytes、3x async-replication每秒高達75MB(每秒可發送786432 的message)，

sync-replication約40MB(每秒可發送419430的message)。單一Consumer則每秒有89.7MB(每秒可接收940573的message)，

三個Consumer約為249.5MB(每秒可接收2616197.12的message)，

而End to End的Producer’s latency平均2 ms，一整個讓我驚艷。

我之前在開發Consumer API時，對於Message的接收是使用callback function+event，code review時，

同事建議為什麼不用RX來簡化code，並更簡單處理非同步error handle和multiple threads的concurrency問題。

Kafka目前已經通過QA環境的壓力測試，也在Staging環境服務超過兩個禮拜了，

我們預計下一個版本將上Production，而那是一個超高流量和concurrent users的環境，

預防可能會有Scale-out的需求，我先來練習一下。

I notes for this topic.