2009-07-28 14 views
5

Actualmente estoy usando JSON (comprimido mediante gzip) en mi proyecto Java, en el que necesito almacenar una gran cantidad de objetos (cientos de millones) en el disco. Tengo un objeto JSON por línea y no puedo permitir los saltos de línea dentro del objeto JSON. De esta forma, puedo transmitir los datos del disco línea por línea sin tener que leer todo el archivo a la vez.Buscando un formato de serialización rápido, compacto, transmisible, multilingüe y fuertemente tipado

Resulta que analizar el código JSON (usando http://www.json.org/java/) es una sobrecarga mayor que extraer los datos brutos del disco o descomprimirlos (lo que hago sobre la marcha).

Idealmente, lo que me gustaría es un formato de serialización fuertemente tipado, donde pueda especificar "este campo de objetos es una lista de cadenas" (por ejemplo), y porque el sistema sabe qué esperar, puede deserializarlo con rapidez. También puedo especificar el formato simplemente dándole a otra persona su "tipo".

También necesitaría ser multiplataforma. Uso Java, pero trabajo con personas que usan PHP, Python y otros idiomas.

Así, para recapitular, que debe ser:

  • fuertemente tipado
  • transmisible (es decir, leer un poco de archivos a poco sin tener que cargar todo en la memoria RAM a la vez.)
  • Multiplataforma (incluyendo Java y PHP)
  • rápido
  • libre (como en el discurso)

¿Alguna sugerencia?

+0

Si extraer datos sin procesar del disco es más rápido, ¿por qué no hacer eso? ¿Por qué meterse con JSON si es más lento? –

+0

De acuerdo, entonces analizar json es más lento que descomprimir, o leer los datos del disco. ¿Y qué? ¿Es demasiado lento para lo que tienes que hacer? ¿O estás optimizando por el simple hecho de hacerlo? – Breton

+0

Breton: es demasiado lento para lo que tengo que hacer, no es una optimización prematura. – sanity

Respuesta

8

¿Has mirado en memorias intermedias del Protocolo de Google ?:

http://code.google.com/apis/protocolbuffers/

Son multiplataforma (C++, Java, Python) con los enlaces de terceros para PHP también. Es rápido, bastante compacto y fuertemente tipado.

También hay una comparación útil entre varios formatos aquí:

http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking

Es posible que desee considerar Thrift o uno de los otros mencionados aquí también.

+0

... y Google está respaldando. –

2

Usted puede echar un vistazo a YAML- http://www.yaml.org/

Es un superconjunto de JSON por lo que la estructura de archivos de datos será familiar para usted. Es compatible con algunos tipos de datos adicionales, así como la capacidad de utilizar referencias que incluyen una parte de una estructura de datos en otra.

No tengo idea de si será "lo suficientemente rápido", pero el analizador libyaml (escrito en C) parece bastante rápido.

+0

Si bien Yaml no es en modo alguno un superconjunto de JSON, acepto que es uno de los formatos más legibles/compactos/mecanografiados que conozco. – gizmo

+0

yaml es mucho más complejo que json. Creo que la mayoría de las implementaciones son más lentas. – troelskn

+0

AFAIK, sí, las implementaciones no son muy efectivas. YAML está orientado a objetivos algo diferentes, máxima expresividad, etc., no a la velocidad ni a la simplicidad. – StaxMan

3

que he tenido muy buenos resultados con el análisis de JSON Jackson

Jackson es un:

  • Transmisión (lectura, escritura)
  • RÁPIDO (medido a ser más rápido que cualquier otro analizador JSON Java y enlace de datos)
  • Potente (enlace de datos completo para las clases JDK comunes, así como cualquier clase de beans Java, Colección, Mapa o Enum)
  • Zero-dependen CY (no depende de otros paquetes más allá de JDK)
  • de código abierto (LGPL o AL)
  • totalmente conforme
  • procesador

JSON JSON (analizador + generador de JSON) escrito en Java. Más allá de la lectura/escritura JSON básica (análisis sintáctico, generación), también ofrece el modelo de árbol basado en nodo completo, así como la funcionalidad completa de enlace de datos OJM (Object/Json Mapper).

Su performance es muy bueno en comparación con muchas otras opciones de serialización.

+0

Usa Jackson antes de intentar cualquier otra cosa. El código en json.org no es adecuado para uso de producción. –

Cuestiones relacionadas