1. Inicio
  2. Pregunta y respuesta
  3. Buffers de protocolo frente a JSON o BSON

Buffers de protocolo frente a JSON o BSON

2010-01-04 15 views
85

¿Alguien tiene alguna información sobre las características de rendimiento de Protocol Buffers frente a BSON (JSON binario) o frente a JSON en general?Buffers de protocolo frente a JSON o BSON

  • El tamaño del cable
  • velocidad de serialización
  • velocidad Deserialización

Parecen buenos protocolos binarios para su uso a través de HTTP. Me pregunto qué sería mejor a largo plazo para un entorno C#.

Aquí hay algo de información que estaba leyendo en BSON y Protocol Buffers.

Fuente

2010-01-04 Jeff Meatball Yang

+0

Algunos argumentan (creo que esto incluye a un antiguo autor protobuf) que es una mejor idea usar un formato de serialización más grande pero más económico y luego comprimir la salida con un compresor estándar rápido. – CodesInChaos

+0

http://devblog.corditestudios.com/blog/2012/10/29/bson-vs-yaml-vs-protobuf/ – laike9m

Respuesta

63

Thrift es otra alternativa similar a Protocol Buffers.

Hay buenos puntos de referencia de la comunidad de Java en la serialización/deserialización y tamaños de cable de estas tecnologías: http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking

En general, JSON tiene el tamaño del cable ligeramente más grande y ligeramente peor Deser, pero gana en la ubicuidad y la capacidad de interpretarlo fácilmente sin la fuente IDL. El último punto es algo que Apache Avro está tratando de resolver, y supera a ambos en términos de rendimiento.

Microsoft ha lanzado un paquete C# NuGet Microsoft.Hadoop.Avro.

Fuente

2010-01-04 17:41:09

+1

El tamaño de mensaje pequeño no se traduce automáticamente en perforamnce rápido, consulte este artículo http://soa.sys-con.com/node/250512 –

+1

Buen enlace; De lo único que no estoy seguro es de los comentarios sobre Avro: si bien podría funcionar de manera más eficiente para sus casos de uso principales (toneladas de entradas de datos similares), no parece funcionar muy rápido en este punto de referencia (que prueba el manejo de un solicitud única) – StaxMan

+0

CoDec, MoDem .... Me gusta "SeDes" mejor :) – nawfal

21

tampones protocolo está diseñado para el alambre:

  1. muy pequeño tamaño de mensaje - un aspecto es representación entera de tamaño variable muy eficiente.
  2. Decodificación muy rápida: es un protocolo binario.
  3. protobuf genera C + + super eficiente para codificar y decodificar los mensajes - sugerencia: si codifica todos los enteros var o elementos de tamaño estático, se codificará y decodificará a una velocidad determinística.
  4. Ofrece un modelo de datos MUY rico: codifica de manera eficiente estructuras de datos muy complejas.

JSON es solo texto y tiene que ser analizado. sugerencia: codificar un "mil millones" de int dentro de él tomaría un montón de caracteres: mil millones = 12 caracteres (escala larga), en binario se ajusta en uint32_t ¿Y qué hay sobre tratar de codificar un doble? eso sería mucho peor.

Fuente

2010-01-04 17:40:59

+3

Sin embargo, tiene la desafortunada desventaja de no manejar la herencia y, aunque la composición es válida Alternativa, prefiero no ser forzado por mi objeto de transferencia de datos a usar composición en lugar de herencia. –

+4

Creo que las extensiones se pueden usar de forma muy similar a la herencia ... https://developers.google.com/protocol-buffers/docs/reference/cpp-generated#extension – kralyk

+1

Sí, las extensiones son un muy buen punto. Lo uso en la práctica en el trabajo todos los días. –

51

Éstos son some recent benchmarks que muestra el rendimiento de los populares Serializadores .NET.

El Burning Monks benchmarks muestra el rendimiento de serializar un POCO simple, mientras que el completo Northwind benchmarks muestra los resultados combinados de la serialización de una fila en cada tabla del conjunto de datos Northwind de Microsoft.

enter image description here

Básicamente búferes de protocolo (protobuf-net) es de alrededor de 7x más rápido que el más rápido de la biblioteca de clases base Serializador en .NET (XML DataContractSerializer). También es más pequeño que la competencia, ya que también es 2.2x más pequeño que el formato de serialización más compacto de Microsoft (JsonDataContractSerializer).

serializadores texto de ServiceStack son los más cercanos a igualar los resultados del binario protobuf-red donde su Json Serializer sólo es 2.58x más lento que protobuf-net.

Fuente

2010-08-18 03:00:02 mythz

+1

Gran publicación, pero si es posible siempre debe poner barras de error en sus gráficos de barras al mostrar los promedios. – jtromans

+0

¿Por qué JIL no está incluido en las pruebas? (¿tienes alguna idea de por qué?) –

Cuestiones relacionadas

 Cuestiones relacionadas