Serialisasi Entitas Performant: BSON vs MessagePack (vs JSON)

Baru-baru ini saya menemukan MessagePack , format serialisasi biner alternatif untuk Protocol Buffer dan JSON Google yang juga mengungguli keduanya.

Juga ada format serialisasi BSON yang digunakan oleh MongoDB untuk menyimpan data.

Adakah yang bisa menjelaskan perbedaan dan keunggulan BSON vs MessagePack ?

Sekadar melengkapi daftar format serialisasi biner yang berkinerja baik: Ada juga Gobs yang akan menjadi penerus Protocol Buffer Google . Namun berbeda dengan semua format lain yang disebutkan, yang bukan bahasa-agnostik dan mengandalkan refleksi bawaan Go, ada juga pustaka Gobs untuk setidaknya bahasa lain selain Go.

// Harap dicatat bahwa saya adalah penulis MessagePack. Jawaban ini mungkin bias.

Desain format

1. Kompatibilitas dengan JSON

   Terlepas dari namanya, kompatibilitas BSON dengan JSON tidak begitu baik dibandingkan dengan MessagePack.

   BSON memiliki tipe khusus seperti "ObjectId", "Min key", "UUID" atau "MD5" (menurut saya tipe ini dibutuhkan oleh MongoDB). Jenis ini tidak kompatibel dengan JSON. Itu berarti beberapa jenis informasi dapat hilang saat Anda mengonversi objek dari BSON ke JSON, tetapi tentu saja hanya jika jenis khusus ini ada di sumber BSON. Ini bisa menjadi kerugian untuk menggunakan JSON dan BSON dalam satu layanan.

   MessagePack dirancang untuk dikonversi secara transparan dari / ke JSON.

2. MessagePack lebih kecil dari BSON

   Format MessagePack kurang bertele-tele dari BSON. Hasilnya, MessagePack dapat membuat serial objek yang lebih kecil dari BSON.

   Misalnya, peta sederhana {"a": 1, "b": 2} diserialkan dalam 7 byte dengan MessagePack, sedangkan BSON menggunakan 19 byte.

3. BSON mendukung pembaruan di tempat

   Dengan BSON, Anda dapat memodifikasi bagian dari objek yang disimpan tanpa menserialisasi ulang seluruh objek. Misalkan peta {"a": 1, "b": 2} disimpan dalam sebuah file dan Anda ingin memperbarui nilai "a" dari 1 menjadi 2000.

   Dengan MessagePack, 1 hanya menggunakan 1 byte tetapi 2000 menggunakan 3 byte. Jadi "b" harus dipindahkan mundur sebanyak 2 byte, sedangkan "b" tidak diubah.

   Dengan BSON, 1 dan 2000 menggunakan 5 byte. Karena verbositas ini, Anda tidak perlu memindahkan "b".

4. MessagePack memiliki RPC

   MessagePack, Protocol Buffer, Thrift dan Avro mendukung RPC. Tapi BSON tidak.

Perbedaan ini menyiratkan bahwa MessagePack pada awalnya dirancang untuk komunikasi jaringan sedangkan BSON dirancang untuk penyimpanan.

Implementasi dan desain API

1. MessagePack memiliki API pemeriksaan tipe (Java, C ++ dan D)

   MessagePack mendukung pengetikan statis.

   Pengetikan dinamis yang digunakan dengan JSON atau BSON berguna untuk bahasa dinamis seperti Ruby, Python, atau JavaScript. Tapi merepotkan untuk bahasa statis. Anda harus menulis kode pengecekan tipe yang membosankan.

   MessagePack menyediakan API pemeriksaan tipe. Ini mengubah objek yang diketik secara dinamis menjadi objek yang diketik secara statis. Berikut adalah contoh sederhana (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 memiliki IDL

   Ini terkait dengan API pemeriksaan tipe, MessagePack mendukung IDL. (spesifikasi tersedia dari: http://wiki.msgpack.org/display/MSGPACK/Design+of+IDL )

   Protocol Buffer dan Thrift memerlukan IDL (tidak mendukung pengetikan dinamis) dan menyediakan implementasi IDL yang lebih matang.

3. MessagePack memiliki API streaming (Ruby, Python, Java, C ++, ...)

   MessagePack mendukung streaming deserializers. Fitur ini berguna untuk komunikasi jaringan. Berikut adalah contohnya (Ruby):

    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
    }

Saya tahu bahwa pertanyaan ini agak ketinggalan zaman pada saat ini ... Saya pikir sangat penting untuk menyebutkan bahwa itu tergantung pada seperti apa lingkungan klien / server Anda.

Jika Anda meneruskan byte beberapa kali tanpa pemeriksaan, seperti dengan sistem antrian pesan atau entri log streaming ke disk, Anda mungkin lebih memilih pengkodean biner untuk menekankan ukuran kompak. Jika tidak, itu adalah masalah kasus per kasus dengan lingkungan yang berbeda.

Beberapa lingkungan dapat memiliki serialisasi dan deserialisasi yang sangat cepat ke / dari msgpack / protobuf, yang lain tidak begitu banyak. Secara umum, semakin rendah level bahasa / lingkungan, serialisasi biner yang lebih baik akan berfungsi. Dalam bahasa tingkat yang lebih tinggi (node.js, .Net, JVM) Anda akan sering melihat bahwa serialisasi JSON sebenarnya lebih cepat. Pertanyaannya kemudian menjadi apakah overhead jaringan Anda lebih atau kurang dibatasi daripada memori / cpu Anda?

Berkenaan dengan msgpack vs bson vs buffer protokol ... msgpack adalah byte terkecil dari grup, buffer protokol hampir sama. BSON mendefinisikan tipe asli yang lebih luas daripada dua lainnya, dan mungkin lebih cocok untuk mode objek Anda, tetapi ini membuatnya lebih bertele-tele. Buffer protokol memiliki keuntungan karena dirancang untuk streaming ... yang membuatnya menjadi format yang lebih alami untuk format transfer / penyimpanan biner.

Secara pribadi, saya akan bersandar pada transparansi yang ditawarkan JSON secara langsung, kecuali jika ada kebutuhan yang jelas untuk lalu lintas yang lebih ringan. Melalui HTTP dengan data yang di-gzip, perbedaan dalam overhead jaringan bahkan lebih sedikit menjadi masalah antar format.

Pengujian cepat menunjukkan JSON yang diperkecil dideserialisasi lebih cepat daripada biner MessagePack. Dalam pengujian, Article.json adalah 550kb JSON yang diperkecil, Article.mpack adalah versi 420kb MP-nya. Mungkin masalah implementasi tentu saja.

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);
}

Jadi waktunya adalah:

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

Jadi ruang disimpan, tetapi lebih cepat? Tidak.

Versi yang diuji:

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

Perbedaan utama yang belum disebutkan adalah bahwa BSON berisi informasi ukuran dalam byte untuk seluruh dokumen dan sub-dokumen bersarang lebih lanjut.

document    ::=     int32 e_list

Ini memiliki dua manfaat utama untuk lingkungan terbatas (misalnya tertanam) di mana ukuran dan kinerja penting.

1. Anda dapat segera memeriksa apakah data yang akan Anda parse mewakili dokumen lengkap atau jika Anda akan perlu meminta lebih banyak di beberapa titik (baik itu dari beberapa koneksi atau penyimpanan). Karena ini kemungkinan besar merupakan operasi asinkron, Anda mungkin sudah mengirim permintaan baru sebelum parsing.
2. Data Anda mungkin berisi seluruh sub-dokumen dengan informasi yang tidak relevan untuk Anda. BSON memungkinkan Anda untuk dengan mudah melintasi ke objek berikutnya melewati sub-dokumen dengan menggunakan informasi ukuran dari sub-dokumen untuk melewatinya. msgpack di sisi lain berisi jumlah elemen di dalam apa yang disebut peta (mirip dengan sub-dokumen BSON). Meskipun ini adalah informasi yang tidak diragukan lagi berguna, ini tidak membantu pengurai. Anda masih harus mengurai setiap objek di dalam peta dan tidak bisa melewatkannya begitu saja. Bergantung pada struktur data Anda, ini mungkin berdampak besar pada kinerja.

Saya membuat benchmark cepat untuk membandingkan kecepatan encoding dan decoding MessagePack vs BSON. BSON lebih cepat setidaknya jika Anda memiliki array biner yang besar:

BSON writer: 2296 ms (243487 bytes)
BSON reader: 435 ms
MESSAGEPACK writer: 5472 ms (243510 bytes)
MESSAGEPACK reader: 1364 ms

Menggunakan C # Newtonsoft.Json dan MessagePack oleh neuecc:

    public class TestData
    {
        public byte[] buffer;
        public bool foobar;
        public int x, y, w, h;
    }

    static void Main(string[] args)
    {
        try
        {
            int loop = 10000;

            var buffer = new TestData();
            TestData data2;
            byte[] data = null;
            int val = 0, val2 = 0, val3 = 0;

            buffer.buffer = new byte[243432];

            var sw = new Stopwatch();

            sw.Start();
            for (int i = 0; i < loop; i++)
            {
                data = SerializeBson(buffer);
                val2 = data.Length;
            }

            var rc1 = sw.ElapsedMilliseconds;

            sw.Restart();
            for (int i = 0; i < loop; i++)
            {
                data2 = DeserializeBson(data);
                val += data2.buffer[0];
            }
            var rc2 = sw.ElapsedMilliseconds;

            sw.Restart();
            for (int i = 0; i < loop; i++)
            {
                data = SerializeMP(buffer);
                val3 = data.Length;
                val += data[0];
            }

            var rc3 = sw.ElapsedMilliseconds;

            sw.Restart();
            for (int i = 0; i < loop; i++)
            {
                data2 = DeserializeMP(data);
                val += data2.buffer[0];
            }
            var rc4 = sw.ElapsedMilliseconds;

            Console.WriteLine("Results:", val);
            Console.WriteLine("BSON writer: {0} ms ({1} bytes)", rc1, val2);
            Console.WriteLine("BSON reader: {0} ms", rc2);
            Console.WriteLine("MESSAGEPACK writer: {0} ms ({1} bytes)", rc3, val3);
            Console.WriteLine("MESSAGEPACK reader: {0} ms", rc4);
        }
        catch (Exception e)
        {
            Console.WriteLine(e);
        }

        Console.ReadLine();
    }

    static private byte[] SerializeBson(TestData data)
    {
        var ms = new MemoryStream();

        using (var writer = new Newtonsoft.Json.Bson.BsonWriter(ms))
        {
            var s = new Newtonsoft.Json.JsonSerializer();
            s.Serialize(writer, data);
            return ms.ToArray();
        }
    }

    static private TestData DeserializeBson(byte[] data)
    {
        var ms = new MemoryStream(data);

        using (var reader = new Newtonsoft.Json.Bson.BsonReader(ms))
        {
            var s = new Newtonsoft.Json.JsonSerializer();
            return s.Deserialize<TestData>(reader);
        }
    }

    static private byte[] SerializeMP(TestData data)
    {
        return MessagePackSerializer.Typeless.Serialize(data);
    }

    static private TestData DeserializeMP(byte[] data)
    {
        return (TestData)MessagePackSerializer.Typeless.Deserialize(data);
    }

Nah, seperti yang dikatakan penulis, MessagePack pada awalnya dirancang untuk komunikasi jaringan sedangkan BSON dirancang untuk penyimpanan.

MessagePack kompak sementara BSON verbose. MessagePack dimaksudkan untuk menjadi hemat ruang sementara BSON dirancang untuk CURD (hemat waktu).

Yang terpenting, sistem tipe MessagePack (awalan) mengikuti pengkodean Huffman, di sini saya menggambar pohon Huffman dari MessagePack (klik tautan untuk melihat gambar) ：