高性能系列化实体：BSON VS MessagePack（VS JSON）

Question

最近我发现MessagePack，替代二进制序列化格式，以谷歌的Protocol Buffers和JSON也优于两者。

此外还有MongoDB用于存储数据的BSON序列化格式。

有人可以详细说明区别以及BSON与MessagePack的区别/优点？

---

刚刚完成的高性能的二进制序列化格式列表：也有Gobs 这将是谷歌的协议缓冲 的继任者。然而， 与所有其他提及的格式不同，它们不是语言不可知的，并且依赖于 Go's built-in reflection ，至少在Go以外的语言中也有Gobs库。

Answer 1

//请注意我是MessagePack的作者。这个答案可能是有偏见的。

格式设计

1. 与JSON

   尽管它的名字的兼容性，与MessagePack相比BSON与JSON的兼容性也不是那么好。

   BSON有“ObjectId”，“Min key”，“UUID”或“MD5”（我认为MongoDB需要这些类型）的特殊类型。这些类型与JSON不兼容。这意味着某些类型信息在将对象从BSON转换为JSON时会丢失。在单一服务中使用JSON和BSON可能是不利的。

   MessagePack被设计为从/到JSON透明转换。

2. MessagePack比BSON

   小MessagePack的格式比BSON更简洁。结果，MessagePack可以序列化小于BSON的对象。

   例如，一个简单的映射{“a”：1，“b”：2}被7个字节的MessagePack序列化，而BSON使用19个字节。

3. BSON支持就地更新

   随着BSON，您可以修改存储对象的一部分，而无需重新整序列化对象。假设地图{“a”：1，“b”：2}存储在一个文件中，并且您希望将“a”的值从1更新为2000.

   使用MessagePack，1仅使用1个字节但2000年使用3个字节。所以“b”必须向后移动2个字节，而“b”没有被修改。

   使用BSON，1和2000都使用5个字节。由于这种冗长，你不必移动“b”。

4. MessagePack具有RPC

   MessagePack，协议缓冲区，节俭和Avro的支持RPC。但是BSON没有。

这些差异意味着MessagePack最初设计用于网络通信，而BSON设计用于存储。

实施和API设计

1. MessagePack具有类型检查的API（JAVA，C++和d）

   MessagePack支持静态打字。

   用于JSON或BSON的动态类型对于Ruby，Python或JavaScript等动态语言非常有用。但是对于静态语言来说很麻烦。你必须写无聊的类型检查代码。

   MessagePack提供了类型检查API。它将动态类型的对象转换为静态类型的对象。下面是一个简单的例子（C++）：

   #include <msgpack.hpp> 
   
   class myclass { 
   private: 
       std::string str; 
       std::vector<int> vec; 
   public: 
       // This macro enables this class to be serialized/deserialized 
       MSGPACK_DEFINE(str, vec); 
   }; 
   
   int main(void) { 
       // serialize 
       myclass m1 = ...; 
   
       msgpack::sbuffer buffer; 
       msgpack::pack(&buffer, m1); 
   
       // deserialize 
       msgpack::unpacked result; 
       msgpack::unpack(&result, buffer.data(), buffer.size()); 
   
       // you get dynamically-typed object 
       msgpack::object obj = result.get(); 
   
       // convert it to statically-typed object 
       myclass m2 = obj.as<myclass>(); 
   } 
   

2. MessagePack具有IDL

   它相关的类型检查API，MessagePack支持IDL。 （规范可从：http://wiki.msgpack.org/display/MSGPACK/Design+of+IDL）

   Protocol Buffers和Thrift需要IDL（不支持动态输入）并提供更成熟的IDL实现。

3. MessagePack已经流API（红宝石，Python和Java和C++，...）

   MessagePack支持流解串器。该功能对网络通信非常有用。下面是一个例子（红宝石）：

   require 'msgpack' 
   
   # write objects to stdout 
   $stdout.write [1,2,3].to_msgpack 
   $stdout.write [1,2,3].to_msgpack 
   
   # read objects from stdin using streaming deserializer 
   unpacker = MessagePack::Unpacker.new($stdin) 
   # use iterator 
   unpacker.each {|obj| 
       p obj 
   } 
   

Answer 2

快速测试显示缩小的JSON反序列化不是二进制MessagePack更快。在测试中，Article.json是550kb缩小的JSON，Article.mpack是它的420kb MP版本。当然可能是一个实现问题。

MessagePack：

//test_mp.js 
var msg = require('msgpack'); 
var fs = require('fs'); 

var article = fs.readFileSync('Article.mpack'); 

for (var i = 0; i < 10000; i++) { 
    msg.unpack(article);  
} 

JSON：

// test_json.js 
var msg = require('msgpack'); 
var fs = require('fs'); 

var article = fs.readFileSync('Article.json', 'utf-8'); 

for (var i = 0; i < 10000; i++) { 
    JSON.parse(article); 
} 

所以时间是：

Anarki:Downloads oleksii$ time node test_mp.js 

real 2m45.042s 
user 2m44.662s 
sys  0m2.034s 

Anarki:Downloads oleksii$ time node test_json.js 

real 2m15.497s 
user 2m15.458s 
sys  0m0.824s 

因此节省空间，但速度更快？

号

测试版本：

Anarki:Downloads oleksii$ node --version 
v0.8.12 
Anarki:Downloads oleksii$ npm list msgpack 
/Users/oleksii 
└── msgpack@0.1.7 

Answer 3

我知道这个问题是在这一点上有点过时...我想提一提，它取决于你的客户机/服务器环境是什么样子是非常重要的。

如果要传递的字节多次未经检验，例如用一个消息队列系统或流式传输的日志条目到磁盘上，则很可能更喜欢的二进制编码来强调紧凑的尺寸。否则，这是一个在不同环境下的案例。

某些环境会有非常快速的序列化和反序列化到/从msgpack/protobuf的年代，别人没有这么多。一般来说，语言/环境越低级，更好的二进制序列化就可以工作。在更高级别的语言（node.js，.Net，JVM）中，您经常会看到JSON序列化实际上更快。那么问题就是你的网络开销比你的内存/ CPU多少受到限制？

至于msgpack VS BSON VS协议缓冲区... msgpack是该组的至少字节，协议缓冲区是大约相同的。 BSON定义了比其他两种更广泛的本机类型，并且可能与对象模式更匹配，但这使得它更加冗长。协议缓冲区具有被设计为流式传输的优势...这使得它成为二进制传输/存储格式更自然的格式。

我个人的偏向透明度JSON提供直接，除非有较轻的交通显然需要。通过使用压缩数据的HTTP，网络开销的差异更不是格式之间的问题。