是否有比JSON / BSON更精简的Javascript对象表示法格式?

时间:2013-03-19 23:37:34

标签: javascript json bson

对于比JSON占用空间小得多的简单Javascript对象树,是否有任何良好的序列化/反序列化格式? BSON不是很令人印象深刻。

JSON中的冗余开销对于许多对象共享同一组属性的树尤其重要。理论上,应该可以检测对象数组中的模式,以便不重复属性名称。

3 个答案:

答案 0 :(得分:1)

您可以将您的JSON变成更多的数据库"格式,然后将其转换回常规对象。结果有时值得。

// Typed on the fly
var dict = [
  ["FirstName", "LastName"],
  ["Ken",       "Starr"],
  ["Kermit",    "Frog"]
];

然后你可以用这样的东西循环字典:

// Again, typed on the fly
var headers = dict[0];
var result = []
var o;
for (var i = 0 + 1; i < dict.length; i++) {
  o = {}
  for (j = 0; j < headers.length; j++) {
    o[headers[j]] = dict[i][j];
  }
  result.push(o);
}

答案 1 :(得分:1)

Gzip很快。 非常快。我非常有信心,它是精益物品运输的最佳解决方案(在实用性和效率方面)。

为了说明这一点,我在其中一个临时站点上构建了一个快速示例。

http://staging.svidgen.com/ajax/test-a.js生成5k行简单数据并输出原始的无污染JSON。

$data = array();
for ($i = 0; $i < 5000; $i++) {
    $data[] = array(
        'value-a' => $i,
        'value-b' => pow($i,2),
        'value-c' => pow($i,3)
    );
}

print json_encode($data);

gzipped响应 65KB ,需要 357ms 来请求,构建,序列化和传输。从等式中省略客户端大小的解析, 182KB / s 吞吐量。考虑到 274KB 传输的原始数据, 767KB / s 有效吞吐量。响应如下:

[{"value-a":0,"value-b":0,"value-c":0},{"value-a":1,"value-b":1,"value-c":1} /* etc. */]

替代格式http://staging.svidgen.com/ajax/test-b.js生成相同的5k行简单数据,但将数据重构为更高效的索引JSON序列化。

$data = array();
for ($i = 0; $i < 5000; $i++) {
    $data[] = array(
        'value-a' => $i,
        'value-b' => pow($i,2),
        'value-c' => pow($i,3)
    );
}

$out_index = array();
$out = array();

foreach ($data as $row) {
    $new_row = array();
    foreach ($row as $k => $v) {
        if (!isset($out_index[$k])) {
            $out_index[$k] = sizeof($out_index);
        }
        $new_row[$out_index[$k]] = $v;
    }
    $out[] = $new_row;
}

print json_encode(array(
    'index' => $out_index,
    'rows' => $out
));

gzipped响应 59.4KB ,需要 515ms 来请求,构建,序列化和传输。从等式中省略客户端大小的解析, 115KB / s 吞吐量。考虑到传输的 128KB 原始数据, 248KB / s 有效吞吐量。响应如下:

{"index":{"value-a":0,"value-b":1,"value-c":2},"rows":[[0,0,0],[1,1,1] /* etc. */ ]}

因此,在我们相当简单的示例中,原始的重组数据比原始原始数据小50%。但是,当gzip压缩时,它只减小了9%。在这种情况下,成本总请求时间增加了44%。

如果您编写了二进制库来重组数据,我希望您可以大幅减少44%。但是,它仍然不太可能值得。您需要它来序列化数据,而不是比“正常”编码结构花费的时间长9%以上才能看到任何增益。

避免重组或“替代序列化”命中的唯一方法是从头到尾以笨拙的索引方式处理服务器端的所有对象。而且,除非你真的想要从你的硬件中获得每一个微不足道的性能,否则这真的是一个糟糕的主意。

在这两种情况下,gzip的空间节省远远超出我们使用替代JavaScript可编译格式所能实现的空间。

(我们甚至没有考虑客户端大小的解析 - 对于任何不是“普通”JSON或XML的东西来说,非常重要。)

结论

只需使用内置的序列化库和gzip。

答案 2 :(得分:0)

  1. 确实存在快速压缩库。因此,紧凑格式优于不太紧凑的格式加压缩不是特定的。

    我手头没有链接,但我认为一位前protobuf设计师推荐这种方法。

  2. 查看MessagePack。它是一种相当紧凑的二进制格式,其语义与JSON或BSON非常相似。

    短数组(最多16个元素),映射(最多16对)和字符串(最多32个字节)具有单字节开销。小整数(-32到128)总共只占一个字节。