1. JSONやMessagePackを
試した話。
2013/4/23 第2回社内エンジニア勉強会
けめ
公開Ver.

2. シリアライズとは
シリアライズ【serialize】（シリアライゼーション）
ソフトウェア内部で扱っているデータを丸ごと、ファイルで保存したりネットワークで送
受信することができるように変換すること。
これとは逆に、ファイルに保存されているシリアライズされたデータや、ネットワークを
通じて送られてきたシリアライズされたデータを、ソフトウェアで扱うことのできる元の
データ形式に復元することを「デシリアライズ」(deserialize)「デシリアライゼーション」
(deserialization)という。
シリアライズとは【serialize】（シリアライゼーション） - 意味/解説/説明/定義 ： IT用語辞典
http://e-words.jp/w/E382B7E383AAE382A2E383A9E382A4E382BA.html

3. 今日の話
• 用途
• Web API
• キャッシュ
• 比較対象
• *
• *
ナイショ：新人の頃から関わってるシステムAと、最近
関わったシステムBを事例として紹介

4. 今まで扱ってきたもの

5. システムA
ナイショ：XMLベースの社内向けAPIの概要とリクエスト
のサンプルを紹介

6. システムB
ナイショ：システム間の連携に用いるXML-RPCなAPIの概
要とリクエストのサンプルを紹介

7. システムB
ナイショ：ブラウザ(JS)から呼び出されるJSONベースの
APIの概要とリクエストのサンプルを紹介

8. システムB
ナイショ：MessagePackでシリアライズして保存したキ
ャッシュデータのサンプルを紹介（文字セットから外れ
た部分は全て???みたいな状態のまま表示）

10. 小さな容量で表現
最小限の型と構造

11. 比較

12. 速度
• 変換の速さ
• もしXML-RPC準拠ではなくJSONにし
ていたら・・・
• JSON vs MessagePack
XML推し流されXML-RPCを
採用してみたが・・・

13. 速度
benchmarking XMLRPC::Lite vs. RPC::XML for server - tokuhirom’s blog.
http://blog.64p.org/entry/20100928/1285630821
Benchmark: timing 5000 iterations of RPC::XML, XML::RPC, XML::RPC::Fast, XMLRPC::Lite, rest
json...
RPC::XML: 2 wallclock secs ( 1.73 usr + 0.00 sys = 1.73 CPU) @ 2890.17/s (n=5000)
XML::RPC: 4 wallclock secs ( 4.51 usr + 0.00 sys = 4.51 CPU) @ 1108.65/s (n=5000)
XML::RPC::Fast: 2 wallclock secs ( 1.78 usr + 0.00 sys = 1.78 CPU) @ 2808.99/s (n=5000)
XMLRPC::Lite: 16 wallclock secs (15.49 usr + 0.01 sys = 15.50 CPU) @ 322.58/s (n=5000)
rest json: 0 wallclock secs ( 0.12 usr + 0.00 sys = 0.12 CPU) @ 41666.67/s (n=5000)
(warning: too few iterations for a reliable count)
Rate XMLRPC::Lite XML::RPC XML::RPC::Fast RPC::XML rest json
XMLRPC::Lite 323/s -- -71% -89% -89% -99%
XML::RPC 1109/s 244% -- -61% -62% -97%
XML::RPC::Fast 2809/s 771% 153% -- -3% -93%
RPC::XML 2890/s 796% 161% 3% -- -93%
rest json 41667/s 12817% 3658% 1383% 1342% --
PerlのXML-RPCモジュール比較
CPANモジュール選定の参考にさせ
ていただきました！
JSON使った方が早い・・・

14. 速度
Data::MessagePack - search.cpan.org
http://search.cpan.org/~tokuhirom/Data-MessagePack/lib/Data/MessagePack.pm
-- serialize
JSON::XS: 2.3
Data::MessagePack: 0.24
Storable: 2.21
Benchmark: running json, mp, storable for at least 1 CPU seconds...
json: 1 wallclock secs ( 1.00 usr + 0.01 sys = 1.01 CPU) @ 141939.60/s
(n=143359)
mp: 1 wallclock secs ( 1.06 usr + 0.00 sys = 1.06 CPU) @ 355500.94/s
(n=376831)
storable: 1 wallclock secs ( 1.12 usr + 0.00 sys = 1.12 CPU) @ 38399.11/s (n=43007)
Rate storable json mp
storable 38399/s -- -73% -89%
json 141940/s 270% -- -60%
mp 355501/s 826% 150% --
JSON vs MessagePack on Perl
MessagePackはさらに早い！

15. 速度
Data::MessagePack - search.cpan.org
http://search.cpan.org/~tokuhirom/Data-MessagePack/lib/Data/MessagePack.pm
-- deserialize
JSON::XS: 2.3
Data::MessagePack: 0.24
Storable: 2.21
Benchmark: running json, mp, storable for at least 1 CPU seconds...
json: 0 wallclock secs ( 1.05 usr + 0.00 sys = 1.05 CPU) @ 179442.86/s
(n=188415)
mp: 0 wallclock secs ( 1.01 usr + 0.00 sys = 1.01 CPU) @ 212909.90/s
(n=215039)
storable: 2 wallclock secs ( 1.14 usr + 0.00 sys = 1.14 CPU) @ 114974.56/s
(n=131071)
Rate storable json mp
storable 114975/s -- -36% -46%
json 179443/s 56% -- -16%
mp 212910/s 85% 19% --
JSON vs MessagePack on Perl
デシリアライズも早い！

16. 容量
• シリアライズ後の容量
• 器と中身
• 疑問：データ型はどこまで必要？

17. 容量
<struct>
<member>
（省略）
</member>
<member>
<name>Target</name>
<value>
<struct>
<member>
<name>Type</name>
<value><int>1</int></value>
</member>
<member>
<name>Status</name>
<value><int>7</int></value>
</member>
<member>
<name>Name</name>
<value><string>hoge256</string></value>
</member>
<member>
<name>Serial</name>
<value><string>3aefna7eoghaoi3dfna</string></value>
</member>
</struct>
</value>
</member>
</struct>
ナイショ：実際のリクエス
トからサンプルに改変
データの中身(白)以上に器(赤)の部
分が大きい。

18. 容量
{
"method":"system.admin.getHogeList",
"params":{
"Target":{
"Name":"hoge256",
"Type":1,
"Status":7
},
"Option":{
"Info":"Off"
}
}
}
（データ型の表現は減ったけど）
器はだいぶ小さくなった！
ナイショ：実際のリクエス
トからサンプルに改変

19. 容量
JSON vs MessagePack
春っぽくお弁当箱を
シリアライズしてみる

20. 容量
JSON vs MessagePack
MessagePackはさらに容量が小さい！

21. 容量
• 疑問：データ型はどこまで必要？
• 構造やデータ型の取り決め
• バリデーション
常に決まった構造とデータ型を返す
APIで、その仕様が公開されている場
合には恩恵薄い？
細かなデータ型もあると「仕様とデータ
が一緒に届く」とも言えるかも？

22. 可読性
• デシリアライズせずに読む
• 読み手：人間、プログラム（探索）
• 場所：ファイル、データベース
• 読み辛さ
• データ構造を示す付加情報

23. 可読性
• MessagePackを試していて気になったこと
• ファイルに書いてcurlでPOST
• APIコンソール上で編集
• TEXT型のカラムに書けない（MySQL）
• ログへの書き出しは？
頻繁に使うなら変換ユーティリティとかあると便利
手ではJSONを書いて変換する感じにする・・・？
JSONからMsgPackに置き換えた際に嵌った。。
XMLやJSONはそのまま書き出しているけど・・・

24. まとめ

25. まとめ
• 「公開範囲」で選ぶ
• 外部公開：RESTful,Ajax, ○○-RPC
• 仕様がオープン、公開ライブラリが充実
• 社内限定：独自の○○ベースもあり？
• プロダクト内部：言語依存もあり？
• 例）PerlのStorable

26. まとめ
• 「容量」や「速度」で選ぶ
• MessagePack ≧ JSON > その他
• 「可読性」で選ぶ
• JSON ≧ XML >> [超壁] >> MessagePack
この辺りは個人差がありそうｗ

27. おまけ

28. MessagePack issues121
• https://github.com/msgpack/msgpack/issues/121
• 「文字列型がほしい」という要望
• MessagePackはあくまでデータコンテナで、細
かなデータ型の扱いは言語に任せるスタンス
• しかしJSON代替としてのニーズも多い
• 非互換でもいいからIETF標準にしちまおう
ぜ！とか言い出して政治的な話にも発展

29. MessagePack issues121
• ep3 ゲスト: frsyuki, kiyoto - Tatsuhiko Miyagawa's Podcast
• http://tmblr.co/ZvMh0tf6XvMn
• 開発者の古橋さんがMessagePackを作ったキッカケ
や、issues121に端を発する議論について、国内外
の反応差や言語毎の事情、今後の方針について話
しています。
• 「MessagePack issues 121」で検索すると、日本語で
書かれたまとめ記事なども見つかります。

30. さらにおまけ

31. JSONの整形
$ JSONを出力する何か | python -mjson.tool
例）標準入力
{"method":"system.admin.getHogeList","params":{"":
{"User":"hoge256","Type":1,”Status”:7}}}
ナイショ：実際のリクエス
トからサンプルに改変

32. JSONの整形
例）標準出力
{
"method": "system.admin.getHogeList",
"params": {
"Service": {
"User": "hoge256",
"Type": 1,
"Status": 7
}
}
}

33. ご清聴ありがとうございました。