ComStock資訊量實例解說

___(A)____

重播用的來源檔(Raw)

HK_100503.log

檔案大小: 1,444,388 KB

此檔案為2010-05-03,HTS Server於日盛所錄下接收ComStock的港股資料(由cooper提供)

輸出給HTS的封包歷史檔(Raw)

SeqNo.HFD

檔案大小:    250,016 KB

此為GMDS輸出給HTS Server(KGQ)的完整資料內容,

包含HTS需要的封包序號、清盤、市場訊息與衍伸的欄位資料如內外盤量、前一買賣成交價等,

以及由盤後檔取得的擴充欄位如中英文名稱,交易ID,商品特性等,

HTS的歷史檔封包索引

SeqNo.HFI

檔案大小:    112,538 KB

此檔案規格以16Bytes為一個結構單位,結構內容為:

檔案位置(__int64[8]) + 封包長度(long[4]) + 發送時間(time_t[4])

提供以序號針對歷史檔快速Access的索引資訊,也可作為以後以時間模擬資料重播的依據

以Raw Data比較, 來源的 1.44GB 經過GMDS處理後, 須發送給HTS Server

的資料量僅250MB,約原本的18%不到,

其中主要原因是日盛的架構中,會有大量頻繁的Refresh資料,

而在來源資訊連結無中斷的狀況下,Refresh的內容都會跟記憶的Quote Status一模一樣,

因此單就Raw Data來說,經過變異演算處理的過程中就能節省大量資料傳輸,

而250MB的資訊量於新的壓縮傳輸機制下實際僅須傳輸120MB,壓縮約為原本的48% ,

48% * 18% = 8.64%, 也就是以通訊的部分而言,

從源資訊到HTS只須源資訊的 8.64%傳輸頻寬, 不到原本的一成, 非常驚人!

___(B)____

重播用的來源檔(Raw)

20100602-16h.log

檔案大小:   119,701 KB

此檔案為2010-06-02,由iPower提供的ComStock Log檔 (僅Level1,無Level2之5檔行情)

輸出給HTS的封包歷史檔(Raw)

20100602-SeqNo.HFD

檔案大小:     65,660 KB

HTS的歷史檔封包索引

20100602-SeqNo.HFI

檔案大小:     24,733 KB

以Raw Data比較, 來源的 119MB 經過GMDS處理後, 須發送給HTS Server

的資料量僅 65MB,約原本的55%,

原因是ComStock的架構中,有些資料須經常性的伴隨發送,

例如小數點位數,只要有價位資料就須連帶發送出來,但這個項目是完全不會有異動的,

所以GMDS以一個tag紀錄此資料,從頭到尾只須發送一次即可,這樣就能隨封包數目的數量級大幅減少傳輸資訊量,

同樣的如交易日期(ComStock有三種日期 Quote/Active/Trade Date)於同一交易日中也是不會變動的,

類似的這些都可以讓Raw Data本身透過變異演算技術的處理,就能有相當大幅度的資訊量節省空間,

資訊量節省不單是節省頻寬,包括傳遞速度與處理效率都會相對提升,

同樣的於實際傳輸的部分,可以(A)的部分來估

55% * 48% = 26.4% ,

所以從源資訊到HTS只須源資訊的 26.4%傳輸頻寬, 僅原本的三成不到, 也是驚人!

PS:

ComStock 的 Log 僅會有 Realtime 的 Refresh push, 不會像日盛中的架構會有其它多餘的Querry Refresh資料