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.
當時在公司安裝測試Kafka時，同事最常問我是否真的需要ZK呢?
是否可以讓架構更簡單並單純使用Kafka cluster，我當時的回答是:無法避免。
管理和理解Consumer offset我覺得是入門kafka的首要基礎，不然可能會遇到一些小問題，
如Consumer為什麼一直pull重複資料?Consumer如何從某個offset開始pull資料?
Consumer為什麼不pull資料?..等
目前我使用Kafka-manager 管理公司的kafka cluster，但管理上我覺得有些地方很不方便，
偏偏其中有一點是我個人覺得很重要的，所以昨天就嘗試了Kafka Eagle用來補足Kafka-manager的不足，
另外我也大概玩了KafkaOffsetMonitor(太久沒更新，無法支援kafka 0.10.2.X)和linkedin/kafka-monitor(可支援kafka 0.10.2.X，但太多javascripts錯誤，我改到一半就放棄了)。
目前我使用Kafka manager來管理公司的kafka cluster，但topic無法修改replicate 數量，
這篇紀錄一下如何使用kafka system tools進行修改。
Hash index只能建立在In-memory table，並且提供point更快速的搜尋效能，
SQL2016開始可透過rebuild index方式修改bucket_count，無須drop and create。
I got a bug of kafka on windows. It caused disk space usage issue because kafka borkers can not delete old log files after the configured time.
So, I have to build binary of kafka with patch from Microsoft/kafka’s version to avoid more disk space usage.
IN-Memory OLTP的Range Index使用類似B-tree的BW-tree結構，
透過BW-tree有效改善Range和point搜尋效率，並節省更多記憶體開銷，
尤其更適合DATE, DATETIME and DATETIME2。
I have wrote two articles about clustered index as below
[SQL SERVER][Memo]Clustered VS NonClustered Indexes
[SQL SERVER][Memo]再談 Clustered Index.
Today, I would like to talk about physically ordering or sorting of rows in clustered index.
大量使用In-Memory table功能後，那當然就得監控並掌握每個memory object記憶體使用量，
避免發生任何記憶體意外。
當你要將old sp移轉為native sp，千萬不要忘記Native Compilation Advisor這好朋友。
現在公司使用的Monitoring and Reporting System是由ITG建置而成。
SQL2016 In-Memory OLTP，現在可以讓我們很方便將資料存放至Memory table。
SQL2016新功能時態表我以前寫過兩篇，這功能去年我也正式使用在一個線上OLTP系統，
我得老實說這功能確實省下我不少時間，但往往方便就會忽略一些細節，
這篇紀錄一下和Memory table使用的情況。
SQL Server預設將交易隔離等級套用至disk和memory table，
而共同目標都是要達到交易完整性，
而交易初始模式(Transaction Initiation Modes)將直接影響我們要使用那種isolation level，
開發人員有必要了解其中差異，以避免交易更新資料發生非預期錯誤或資料不一致情況。
kafka預設保存7天(168 hour)的log在disk，處理message過程中可能會出現異常或非預期錯誤(如網路中斷、disk 問題)，
這時有可能造成我們資料遺失或不一致，這篇來看看如何重新consume這些資料。
確認Consumer是否有完整消耗kafka message是管理kafka重要的第一步，
因為你不想看到message無法被消耗或累積太多的情況。