40

オブジェクトをシリアル化するためにJSONとBSONを比較しています。これらのオブジェクトには、多数の整数の配列がいくつか含まれています。私のテストでは、シリアル化するオブジェクトには、合計で約12,000個の整数が含まれています。シリアル化された結果のサイズの比較にのみ関心があります。シリアル化を行うライブラリとしてJSON.NETを使用しています。JSONを使用しているのは、JavascriptでもJSONを使用できるようにするためです。

JSON文字列のサイズは約43kbで、BSON結果のサイズは161kbです。したがって、差係数は約4です。BSONの方がデータの保存に効率的だと思ったので、BSONを見たので、これは私が期待したものではありません。

だから私の質問は、なぜBSONが効率的でないのか、それをより効率的にすることができるのかということです。または、Javascriptで簡単に処理できる、多数の整数を含む配列を使用してデータをシリアル化する別の方法はありますか？

以下に、JSON/BSONシリアル化をテストするためのコードを示します。

        // Read file which contain json string
        string _jsonString = ReadFile();
        object _object = Newtonsoft.Json.JsonConvert.DeserializeObject(_jsonString);
        FileStream _fs = File.OpenWrite("BsonFileName");
        using (Newtonsoft.Json.Bson.BsonWriter _bsonWriter = new BsonWriter(_fs) 
               { CloseOutput = false })
        {
            Newtonsoft.Json.JsonSerializer _jsonSerializer = new JsonSerializer();
            _jsonSerializer.Serialize(_bsonWriter, _object);
            _bsonWriter.Flush();
        }

編集：

結果のファイルは次のとおりです https://skydrive.live.com/redir?resid=9A6F31F60861DD2C!362&authkey=!AKU-ZZp8C_0gcR0

4

1 に答える 1

69

JSON と BSON の効率は、格納する整数のサイズによって異なります。実際に整数型を格納するよりも ASCII の方がバイト数が少ないという興味深い点があります。BSON ドキュメントに表示される 64 ビット整数は、8 バイトを使用します。数値はすべて 10,000 未満です。つまり、それぞれを ASCII で 4 バイト (9999 までの各文字に 1 バイト) で格納できます。実際、ほとんどのデータは 1000 未満のように見えます。つまり、3 バイト以下で格納できます。もちろん、デシリアライゼーションには時間がかかり、安価ではありませんが、スペースを節約できます。さらに、Javascript は 64 ビット値を使用してすべての数値を表すため、各整数をより適切なデータ形式に変換した後に BSON に書き込むと、BSON ファイルがはるかに大きくなる可能性があります。

仕様によると、BSON には JSON にはない多くのメタデータが含まれています。このメタデータはほとんどが長さのプレフィックスであるため、関心のないデータをスキップできます。たとえば、次のデータを使用します。

["hello there, this is an necessarily long string.  It's especially long, but you don't care about it. You're just trying to get to the next element. But I keep going on and on.",
 "oh man. here's another string you still don't care about.  You really just want the third element in the array.  How long are the first two elements? JSON won't tell you",
 "data_you_care_about"]

ここで、JSON を使用している場合は、最初の 2 つの文字列全体を解析して、3 番目の文字列がどこにあるかを調べる必要があります。BSON を使用すると、次のようなマークアップが得られます (ただし、実際にはそうではありません。例としてこのマークアップを作成しているためです)。

[175 "hello there, this is an necessarily long string.  It's especially long, but you don't care about it. You're just trying to get to the next element. But I keep going on and on.",
 169 "oh man. here's another string you still don't care about.  You really just want the third element in the array.  How long are the first two elements? JSON won't tell you",
 19 "data_you_care_about"]

これで、「175」を読み取り、175 バイト前方にスキップし、次に「169」を読み取り、169 バイト前方にスキップし、「19」を読み取り、次の 19 バイトを文字列にコピーすることができます。そうすれば、区切り文字の文字列を解析する必要さえありません。

どちらを使用するかは、ニーズに大きく依存します。世界中で常に解析している巨大なドキュメントを格納する予定であるが、ディスク容量が限られている場合は、JSON を使用してください。JSON の方がコンパクトで容量効率が高いからです。ドキュメントを保存する予定であるが、(おそらくサーバー コンテキストで) 待機時間を短縮することが、ディスク領域を節約することよりも重要である場合は、BSON を使用します。

選択する際に考慮すべきもう 1 つの点は、人間の読みやすさです。BSON を含むクラッシュ レポートをデバッグする必要がある場合は、おそらくそれを解読するためのユーティリティが必要になります。おそらく、BSON だけを知っているわけではありませんが、JSON を読むことはできます。

よくある質問

于 2012-09-26T22:49:29.987 に答える