MessagePack
當我們在討論 Web Applications 中的數據交換時，JSON 常是第一時間想到的格式，它有著易於閱讀且跨語言、開發成本低等優點。但當傳輸的數據量開始變大時，我們是不是有別種的選擇呢？
在我的經驗中，有時會碰到需要透過網路傳輸資料和處理請求但資料量還不算小狀況，所以經常會思考如何加速請求。這裡的手段有好幾種，例如：從 Server 著手的 CDN、GZIP。而這篇要討論的是從內容著手，主要談論的是 MessagePack。
簡介
MessagePack 是一種數據交換格式，類似於 JSON，但更小！更快！MessagePack 使用二進制序列化格式來表達數據資料及結構。以下是官方的示意圖：
如何使用？ 官網上有多種語言的實現版本 [link]
壓縮原理
👉 參閱規格 [link]
其中值得關注的是 Extension 格式
擴充格式 透過 Extension Type 可以自定義不同的資料類型，好比說可擴充 UUID 格式。但由於格式上的限制，最多只可支援到 127 種擴充格式(應該也是蠻夠用了😂
在 Shopify Engineering Blog 中也提到他們在做遷移到 MessagePack 時，透過 Extension Types 實現了在 MessagePack 中所沒有支援的 Rails 格式 [link]
Break down 這裡先給個 JSON 格式的 Example Data: Blog Articles
經過 MessagePack Packed 以後的資料會長這樣：
透過官方的規格來拆解每個 Byte，我們可以理解他是如何解釋這些資料的
序列化格式比較
上面大致瞭解了 MessagePack 後，接下來我們就來看一下其他的競品，並做幾個小實驗 [link]
P.S. 這裡就不提 ProtocolBuffers 的原理，單做 JSON 和 MessagePack 以及 Protocol Buffers 的比較
實驗方式：
- 對比不同序列化格式轉換後資料大小
- 對比各個格式的序列化時間
- 對比各個格式的反序列化時間
- 透過壓力測試工具來模擬實際請求的狀況：平均回覆時間、中位數時間
實驗結果： results of the experiment
總結
雖然以數據來看 Protocol Buffers 獲得壓倒性優勢，但別忘了它是需要預先編譯的，使用上沒這麼直覺，且和 MessagePack 一樣都是無法直接閱讀的。
那麼是否該從 JSON 遷移到 MessagePack 呢？答案是取決於使用情境
一般來說小型的數據量用 JSON 是不會感覺出明顯差異的，但當數據成長到一定的量級後，序列和反序列化就是程式中不小的瓶頸了，且儲存空間和網路傳輸也都是成本。
透過 Extension Type 可以自定義不同的資料類型，好比說可擴充 UUID 格式。但由於格式上的限制，最多只可支援到 127 種擴充格式(應該也是蠻夠用了😂
在 Shopify Engineering Blog 中也提到他們在做遷移到 MessagePack 時，透過 Extension Types 實現了在 MessagePack 中所沒有支援的 Rails 格式 [link]
Break down 這裡先給個 JSON 格式的 Example Data: Blog Articles
經過 MessagePack Packed 以後的資料會長這樣：
透過官方的規格來拆解每個 Byte，我們可以理解他是如何解釋這些資料的
序列化格式比較
上面大致瞭解了 MessagePack 後，接下來我們就來看一下其他的競品，並做幾個小實驗 [link]
P.S. 這裡就不提 ProtocolBuffers 的原理，單做 JSON 和 MessagePack 以及 Protocol Buffers 的比較
實驗方式：
- 對比不同序列化格式轉換後資料大小
- 對比各個格式的序列化時間
- 對比各個格式的反序列化時間
- 透過壓力測試工具來模擬實際請求的狀況：平均回覆時間、中位數時間
實驗結果： results of the experiment
總結
雖然以數據來看 Protocol Buffers 獲得壓倒性優勢，但別忘了它是需要預先編譯的，使用上沒這麼直覺，且和 MessagePack 一樣都是無法直接閱讀的。
那麼是否該從 JSON 遷移到 MessagePack 呢？答案是取決於使用情境
一般來說小型的數據量用 JSON 是不會感覺出明顯差異的，但當數據成長到一定的量級後，序列和反序列化就是程式中不小的瓶頸了，且儲存空間和網路傳輸也都是成本。
分享至
成為作者繼續創作的動力吧！
© 2024 vocus All rights reserved.