JSON と Gzip は、データをシリアル化する簡単な方法です。これらは、プログラミング言語全体で広く実装されています。また、この表現はシステム間で移植可能です (そうですか?)。
私の質問は、非常に効率的なバイナリシリアル化方法と比較して、json + gzip が十分に優れているかどうか (2 倍未満のコスト) ですか? さまざまな種類のデータをシリアライズしながら、スペースと時間のコストを探しています。
JSON と Gzip は、データをシリアル化する簡単な方法です。これらは、プログラミング言語全体で広く実装されています。また、この表現はシステム間で移植可能です (そうですか?)。
私の質問は、非常に効率的なバイナリシリアル化方法と比較して、json + gzip が十分に優れているかどうか (2 倍未満のコスト) ですか? さまざまな種類のデータをシリアライズしながら、スペースと時間のコストを探しています。
json+gzip でシリアル化すると、数字とオブジェクトに rawbytes+gzip よりも 25% 多くのスペースが使用されます。限られた精度の数値 (有効数字 4 桁) の場合、シリアル化されたサイズは同じです。小規模なアプリケーションであれば、json+gzip を使用するのがデータ サイズの点で十分であると思われます。これは、各レコードがフィールドと値を完全に記述するレコードの配列を送信する場合にも当てはまります (JavaScript でデータを保存する一般的な方法)。
以下の実験のソース: https://github.com/csiz/gzip-json-performance
私は 100 万個の浮動小数点 (64 ビット) 数を選びました。これらの数値は自然界に由来すると想定しているため、指数分布を使用してそれらを生成し、有効数字 4 桁に丸めました。JSON は表現全体を書き留めるので、大きな数値を格納するとコストが高くなる可能性があると考えたので (例: 123456.000000 と 0.123456 を格納)、両方のケースをチェックします。四捨五入されていないシリアル番号もチェックします。
小さい数値をシリアル化する場合、圧縮された json で使用されるサイズは、圧縮されたバイナリと比較して 9% 大きくなります (約 1.0 の大きさのオーダーなので、書き留める数桁のみ)。
json 3.29mb json/raw 43%
binary 3.03mb binary/raw 40%
json/binary 1.09
圧縮された json で使用されるサイズは、大きな数値をシリアル化する場合、圧縮されたバイナリと比較して 17% 小さくなります (約 1000000 桁、書き留める桁数が多くなります)。
json 2.58mb json/raw 34%
binary 3.10mb binary/raw 41%
json/binary 0.83
完全精度の double をシリアル化する場合、圧縮された json で使用されるサイズは、圧縮されたバイナリよりも 22% 大きくなります。
json 8.90mb json/raw 117%
binary 7.27mb binary/raw 95%
json/binary 1.22
オブジェクトについては、JSON で通常の怠惰な方法でシリアル化しています。各オブジェクトは、フィールド名と値を含む完全なレコードとして保存されます。「選択」列挙には、その値が完全に綴られています。
[
{
"small number": 0.1234,
"large number": 1234000,
"choice": "two"
},
...
]
効率的なバイナリ表現のために、オブジェクトをベクトル化します。オブジェクトの数を格納し、次に小さい数の連続ベクトルを格納し、次に選択列挙型の連続ベクトルを格納します。この場合、列挙型の値は既知で固定されていると想定しているため、インデックスをこの列挙型に格納します。
n = 1e6
small number = binary([0.1234, ...])
large number = binary([1234000, ...])
choice = binary([2, ...]) # indexes to the enum ["zero", "one", ..., "four"]
圧縮された json で使用されるサイズは、オブジェクトを保存するときに圧縮されたバイナリよりも 27% 大きくなります。
json 8.36mb json/raw 44%
binary 6.59mb binary/raw 35%
json/binary 1.27