web-dev-qa-db-ja.com

JSONサイズを減らすことを試みる価値はありますか?

モバイルアプリケーションから比較的大量のデータ(最大1000個のJSONオブジェクト)を送信していますが、通常は次のようにエンコードします。

[{
    id: 12,
    score: 34,
    interval: 5678,
    sub: 9012
}, {
    id: ...
}, ...]

代わりに配列の配列を送信することで、ペイロードを小さくすることができます。

[[12, 34, 5678, 9012], [...], ...]

プロパティ名の一部のスペースを節約し、サーバー上でオブジェクトを再作成します(スキーマが固定されているか、少なくともサーバーとクライアントの間の規約です)。

その後、ペイロードはPOSTリクエストで送信されます。おそらく3G接続経由(またはwifiの可能性があります)です。

ネストされた配列を使用して帯域幅をいくらか節約しているようですが、gzipが適用されたときにそれが顕著であるかわかりません。また、違いを正確かつ客観的に測定する方法がわかりません。

一方、ネストされた配列はfeelとは異なり、読みにくいため、デバッグ中にエラーを見つけるのが難しくなります。また、読みやすさをトイレに流しているので、配列をフラット化するだけで済みます。各子配列には固定数の要素があるため、サーバーはそれをスライスしてオブジェクトを再構築するだけで済みます。

このトピックに関するこれ以上の読み物は大歓迎です。

21
Attila O.

JSONH(別名hpack) https://github.com/WebReflection/JSONH は、例に非常によく似ています。

[{
    id: 12,
    score: 34,
    interval: 5678,
    sub: 9012
}, {
    id: 98,
    score: 76,
    interval: 5432,
    sub: 1098
}, ...]

になります:

[["id","score","interval","sub"],12,34,5678,9012,98,76,5432,1098,...]
17
John Gietzen

JSONは読みやすさを目的としています。スペースが気になる場合は、中間フォーマットを使用できます。 JSONファイルを取得し、データを合理的にコンパクトに格納する圧縮バイナリを作成するシリアライズ/デシリアライズ関数を作成し、行の反対側でそのフォーマットを読み取ります。

参照: http://en.wikipedia.org/wiki/Json 最初の文:「JSON ...は、人間が読めるデータ交換用に設計された軽量のテキストベースのオープンスタンダードです。」

基本的に、私のポイントは、人間は常にJSONを認識し、マシンは主にバイナリを認識するということです。読みやすさと少量のデータ転送(わずかな計算コストで)の両方の長所を活用できます。

13
artoonie

Gzipは、メッセージの繰り返し部分を、最初の出現への小さな後方参照に置き換えます。アルゴリズムはかなり「ばかげている」ですが、この種の反復データには最適です。オブジェクトの「構造」は1回しか送信されないため、ワイヤ上のサイズが目立って減少することはないと思います。

2つのサンプルJSONを圧縮することで、これを大まかにテストできます。または、Fiddlerを使用してHTTPリクエストをキャプチャします。圧縮されたサイズと圧縮されていないサイズを表示できます。

10
usr

これをモバイルデバイス(3Gについて言及)で使用しているので、読みやすさではなく、実際にはサイズを気にする必要があるかもしれません。さらに、あなたは頻繁に有線で送信されているものを読むことを期待していますか?

これは別の形式の提案です。

ProtoBuf は1つのオプションです。 Googleはこれを内部で使用し、.protoファイル(メッセージの説明を含む)を読み取ってJava/C++/Pythonシリアライザー/デシリアライザーを生成できるProtoBuf 'コンパイラ'があります、ネットワーク経由の送信にバイナリ形式を使用します。両端で生成されたクラスを使用するだけで、ネットワーク経由で送信されたときのオブジェクトの外観を忘れます。 外部で維持されているObj-Cポート もあります。

これは、ProtoBuf Webサイトでの ProtoBufとXML の比較です(XMLはまだ使用しているものではないことを私は知っています)。

最後に、これが Pythonチュートリアル です。

7
ArjunShankar

昔の質問ですが一言お願いします。

私の経験では、jsonの生のサイズに大きな違いがあり、圧縮後の量はごくわずかです。私はそれを人間が読めるようにしておくことを好みます。

実際のケース番号:1,29MBのjsonファイル、および圧縮された場合の145KBの最適化バージョン(32KBおよび9KB)。

極端な状況を除いて、この種の違いは無視できる程度であり、可読性のコストは非常に大きいと思います。

A:

{
  "Code": "FCEB97B6",
  "Date": "\/Date(1437706800000)\/",
  "TotalQuantity": 1,
  "Items": [
    {
      "CapsulesQuantity": 0,
      "Quantity": 1,
      "CurrentItem": {
        "ItemId": "SHIELD_AXA",
        "Order": 30,
        "GroupId": "G_MODS",
        "TypeId": "T_SHIELDS",
        "Level": 0,
        "Rarity": "R4",
        "UniqueId": null,
        "Name": "AXA Shield"
      }
    }
  ],
  "FormattedDate": "2015-Jul.-24"
}

B:

{
  "fDate": "2016-Mar.-01",
  "totCaps": 9,
  "totIts": 14,
  "rDays": 1,
  "avg": "1,56",
  "cells": {
    "00": {
      "30": 1
    },
    "03": {
      "30": 1
    },
    "08": {
      "25": 1
    },
    "09": {
      "26": 3
    },
    "12": {
      "39": 1
    },
    "14": {
      "33": 1
    },
    "17": {
      "40": 3
    },
    "19": {
      "41": 2
    },
    "20": {
      "41": 1
    }
  }
}

これは2つのファイルの断片です。

6
Diego Menta