sirve - ¿Vale la pena el esfuerzo para tratar de reducir el tamaño de JSON?

tamaño de un json

Question

Estoy enviando relativamente muchos datos desde una aplicación móvil (hasta 1000 objetos JSON), que normalmente codificaría de esta manera:

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

Podría reducir la carga útil enviando una matriz de matrices en su lugar:

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

para ahorrar algo de espacio en los nombres de propiedades, y volver a crear los objetos en el servidor (ya que el esquema es fijo, o al menos es un contrato entre el servidor y el cliente).

La carga útil se envía luego en una solicitud POST , probablemente a través de una conexión 3G (o podría ser wifi).

Parece que estoy ahorrando algo de ancho de banda utilizando matrices anidadas, pero no estoy seguro de que se note cuando se aplica gzip , y no estoy seguro de cómo medir la diferencia de forma precisa y objetiva.

Por otro lado, las matrices anidadas no parecen una buena idea: son menos legibles y, por lo tanto, más difíciles de detectar errores durante la depuración. Además, dado que estamos descargando la legibilidad en el inodoro, podríamos simplemente aplanar la matriz, ya que cada matriz secundaria tiene un número fijo de elementos, el servidor podría simplemente dividirla y reconstruir los objetos nuevamente.

Cualquier otro material de lectura sobre este tema es muy apreciado.

Answer 1

Aunque es una pregunta antigua, me gustaría poner algunas palabras.

En mi experiencia, grandes diferencias en el tamaño de json raw, poco después de la compresión. Prefiero mantenerlo legible para humanos.

En los números de casos reales: un archivo json de 1,29MB, y la versión optimizada de 145KB, cuando se comprime, donde de 32KB y 9KB.

Excepto en condiciones extremas, creo que este tipo de diferencias son insignificantes y el costo de la legibilidad es enorme.

UNA:

{
"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"
}

SEGUNDO:

{
"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
}
}
}

Estos son fragmentos de los dos archivos.

Answer 2

Gzip reemplazará las partes recurrentes de su mensaje con pequeñas referencias a su primera aparición. El algoritmo es bastante "tonto", pero para este tipo de datos repetitivos es genial. Creo que no verás disminuciones notables en el tamaño sobre el cable porque tu "estructura" de objeto se envía solo una vez.

Usted puede probar aproximadamente esto comprimiendo dos JSON de muestra. O capturando una solicitud HTTP usando Fiddler. Puede mostrar los tamaños comprimidos y sin comprimir.

Answer 3

JSON está destinado a la legibilidad. Podría tener un formato intermedio si le preocupa el espacio. Cree una función de serialización / deserialización que tome un archivo JSON y cree un binario comprimido que almacene sus datos de manera tan compacta como sea razonable, luego lea ese formato en el otro extremo de la línea.

Consulte: http://en.wikipedia.org/wiki/Json Primera frase: "JSON ... es un estándar abierto basado en texto ligero diseñado para el intercambio de datos legibles por humanos".

Esencialmente, mi punto es que los humanos siempre verían el JSON, y las máquinas verían principalmente el binario. Obtiene lo mejor de ambos mundos: legibilidad y pequeña transferencia de datos (a costa de una pequeña cantidad de cómputo).

Answer 4

JSONH, también conocido como hpack, https://github.com/WebReflection/JSONH hace algo muy similar a su ejemplo:

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

Se convertiría en:

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

Answer 5

Ya que está usando esto en un dispositivo móvil (mencionó 3G), es posible que desee preocuparse por el tamaño, no la legibilidad. Además, ¿espera con frecuencia leer lo que se transmite a través del cable?

Esta es una sugerencia para una forma alternativa.

ProtoBuf es una opción. Google lo usa internamente, y hay un ''compilador'' de ProtoBuf que puede leer archivos .proto (que contiene una descripción del mensaje) y generar serializadores / deserializadores Java / C ++ / Python , que utilizan una forma binaria para la transmisión por cable. Simplemente utiliza las clases generadas en ambos extremos y olvida cómo se ve el objeto cuando se transmite por el cable. También hay un puerto Obj-C mantenido externamente .

Aquí hay una comparación de ProtoBuf con XML , en el sitio web de ProtoBuf (sé que XML no es lo que todavía se usa).

Finalmente, aquí hay un tutorial de Python .