Serializzazione entità performante: BSON vs MessagePack (vs JSON)

Di recente ho trovato MessagePack , un formato di serializzazione binario alternativo ai buffer di protocollo di Google e JSON che supera anche entrambi.

Inoltre, esiste il formato di serializzazione BSON utilizzato da MongoDB per l'archiviazione dei dati.

Qualcuno può elaborare le differenze e i vantaggi / svantaggi di BSON vs MessagePack ?

Solo per completare l'elenco dei formati di serializzazione binaria performanti: ci sono anche Gobs che saranno i successori dei buffer di protocollo di Google . Tuttavia, contrariamente a tutti gli altri formati citati, questi non sono indipendenti dalla lingua e si basano sulla riflessione integrata di Go, ma ci sono anche librerie Gobs per almeno un'altra lingua rispetto a Go.

// Nota che sono autore di MessagePack. Questa risposta può essere parziale.

Progettazione del formato

1. Compatibilità con JSON

   Nonostante il suo nome, la compatibilità di BSON con JSON non è così buona rispetto a MessagePack.

   BSON ha tipi speciali come "ObjectId", "Min key", "UUID" o "MD5" (penso che questi tipi siano richiesti da MongoDB). Questi tipi non sono compatibili con JSON. Ciò significa che alcune informazioni sui tipi possono essere perse quando si convertono oggetti da BSON a JSON, ma ovviamente solo quando questi tipi speciali si trovano nell'origine BSON. Può essere uno svantaggio utilizzare sia JSON che BSON in un singolo servizio.

   MessagePack è progettato per essere convertito in modo trasparente da / a JSON.

2. MessagePack è più piccolo di BSON

   Il formato di MessagePack è meno dettagliato di BSON. Di conseguenza, MessagePack può serializzare oggetti più piccoli di BSON.

   Ad esempio, una semplice mappa {"a": 1, "b": 2} è serializzata in 7 byte con MessagePack, mentre BSON utilizza 19 byte.

3. BSON supporta l'aggiornamento sul posto

   Con BSON, è possibile modificare parte dell'oggetto memorizzato senza serializzare nuovamente l'intero oggetto. Supponiamo che una mappa {"a": 1, "b": 2} sia memorizzata in un file e desideri aggiornare il valore di "a" da 1 a 2000.

   Con MessagePack, 1 utilizza solo 1 byte, mentre 2000 utilizza 3 byte. Quindi "b" deve essere spostato indietro di 2 byte, mentre "b" non viene modificato.

   Con BSON, sia 1 che 2000 utilizzano 5 byte. A causa di questa verbosità, non è necessario spostare "b".

4. MessagePack ha RPC

   MessagePack, Protocol Buffers, Thrift e Avro supportano RPC. Ma BSON no.

Queste differenze implicano che MessagePack è originariamente progettato per le comunicazioni di rete mentre BSON è progettato per gli archivi.

Implementazione e progettazione API

1. MessagePack ha API di controllo del tipo (Java, C ++ e D)

   MessagePack supporta la digitazione statica.

   La digitazione dinamica utilizzata con JSON o BSON è utile per linguaggi dinamici come Ruby, Python o JavaScript. Ma problematico per i linguaggi statici. È necessario scrivere noiosi codici di verifica del tipo.

   MessagePack fornisce API di controllo del tipo. Converte oggetti digitati dinamicamente in oggetti tipizzati staticamente. Ecco un semplice esempio (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 ha IDL

   È correlato all'API di verifica del tipo, MessagePack supporta IDL. (le specifiche sono disponibili da: http://wiki.msgpack.org/display/MSGPACK/Design+of+IDL )

   I buffer di protocollo e la parsimonia richiedono IDL (non supportano la tipizzazione dinamica) e forniscono un'implementazione IDL più matura.

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

   MessagePack supporta lo streaming di deserializzatori. Questa funzione è utile per le comunicazioni di rete. Ecco un esempio (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
    }

So che questa domanda è un po 'datata a questo punto ... Penso che sia molto importante menzionare che dipende dall'aspetto del tuo ambiente client / server.

Se si passano più volte byte senza ispezione, ad esempio con un sistema di code di messaggi o voci di registro in streaming su disco, è possibile preferire una codifica binaria per enfatizzare le dimensioni compatte. Altrimenti è un caso per caso con diversi ambienti.

Alcuni ambienti possono avere serializzazione e deserializzazione molto veloci su / da msgpack / protobuf, altri non così tanto. In generale, più basso è il livello di linguaggio / ambiente, migliore sarà la serializzazione binaria. Nei linguaggi di livello superiore (node.js, .Net, JVM) vedrai spesso che la serializzazione JSON è effettivamente più veloce. La domanda diventa allora: l'overhead della tua rete è più o meno vincolato rispetto alla tua memoria / CPU?

Per quanto riguarda i buffer msgpack vs bson vs protocol ... msgpack è il numero minimo di byte del gruppo, i buffer di protocollo sono più o meno gli stessi. BSON definisce tipi nativi più ampi rispetto agli altri due e potrebbe corrispondere meglio alla modalità dell'oggetto, ma ciò lo rende più dettagliato. I buffer di protocollo hanno il vantaggio di essere progettati per lo streaming ... il che lo rende un formato più naturale per un formato binario di trasferimento / archiviazione.

Personalmente, mi spingerei verso la trasparenza che JSON offre direttamente, a meno che non vi sia una chiara necessità di un traffico più leggero. Su HTTP con dati compressi con gzip, la differenza nell'overhead di rete è ancora meno un problema tra i formati.

Il test rapido mostra che JSON minimizzato è deserializzato più velocemente del MessagePack binario. Nei test Article.json è JSON minimizzato da 550kb, Article.mpack è la versione MP da 420kb. Naturalmente può essere un problema di implementazione.

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

Quindi i tempi sono:

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

Quindi lo spazio è risparmiato, ma più veloce? No.

Versioni testate:

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

Una differenza fondamentale non ancora menzionata è che BSON contiene informazioni sulle dimensioni in byte per l'intero documento e ulteriori documenti secondari nidificati.

document    ::=     int32 e_list

Ciò ha due vantaggi principali per gli ambienti con restrizioni (ad es. Incorporato) in cui dimensioni e prestazioni sono importanti.

1. Puoi verificare immediatamente se i dati che stai per analizzare rappresentano un documento completo o se hai bisogno di richiederne altri ad un certo punto (che si tratti di una connessione o archiviazione). Poiché questa è probabilmente un'operazione asincrona, potresti già inviare una nuova richiesta prima dell'analisi.
2. I tuoi dati potrebbero contenere interi sotto-documenti con informazioni irrilevanti per te. BSON consente di attraversare facilmente l'oggetto successivo oltre il documento secondario, utilizzando le informazioni sulla dimensione del documento secondario per saltarlo. msgpack d'altra parte contiene il numero di elementi all'interno di quella che è chiamata mappa (simile ai sotto-documenti di BSON). Sebbene si tratti indubbiamente di informazioni utili, non aiuta il parser. Dovresti comunque analizzare ogni singolo oggetto all'interno della mappa e non puoi semplicemente saltarlo. A seconda della struttura dei dati, ciò potrebbe avere un impatto enorme sulle prestazioni.

Ho fatto un rapido benchmark per confrontare la velocità di codifica e decodifica di MessagePack vs BSON. BSON è più veloce almeno se si dispone di array binari di grandi dimensioni:

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

Utilizzando C # Newtonsoft.Json e MessagePack di 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);
    }

Bene ， come ha detto l'autore ， MessagePack è stato originariamente progettato per la comunicazione di rete mentre BSON è progettato per gli archivi.

MessagePack è compatto mentre BSON è dettagliato. MessagePack è pensato per essere efficiente in termini di spazio mentre BSON è progettato per CURD (efficiente in termini di tempo).

Ancora più importante, il sistema di tipi (prefisso) di MessagePack segue la codifica Huffman, qui ho disegnato un albero Huffman di MessagePack (fare clic sul collegamento per vedere l'immagine) ：