Búferes de protocolo frente a JSON o BSON [cerrado]

90

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

  • Tamaño del cable
  • Velocidad de serialización
  • Velocidad de deserialización

Estos parecen buenos protocolos binarios para usar sobre HTTP. Me pregunto cuál sería mejor a largo plazo para un entorno C #.

Aquí hay información que estaba leyendo sobre BSON y Protocol Buffers .

c# json comparison protocol-buffers bson Jeff Albóndiga Yang
fuente
Algunos argumentan (creo que esto incluye a un ex autor de protobuf) que es una mejor idea usar un formato más grande pero más barato para serializar y luego comprimir la salida con un compresor estándar rápido.
CodesInChaos
devblog.corditestudios.com/blog/2012/10/29/…
laike9m
No creo que esto deba reabrirse hasta que se proponga un cierto método de comparación en la pregunta en sí (de lo contrario, esto es para una discusión bastante obstinada / demasiado amplia)
YakovL

Respuestas:

64

Thrift es otra alternativa similar a Protocol Buffers.

Hay buenos puntos de referencia de la comunidad Java sobre serialización / deserialización y tamaño de cable de estas tecnologías: https://github.com/eishay/jvm-serializers/wiki

En general, JSON tiene un tamaño de cable un poco más grande y un DeSer ligeramente peor, pero gana en ubicuidad y la capacidad de interpretarlo fácilmente sin el IDL de origen. 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 .

Michael Greene
fuente
1
El tamaño pequeño del mensaje no se traduce automáticamente en una ejecución rápida, consulte este artículo soa.sys-con.com/node/250512
vtd-xml-author
1
Buen enlace; lo único de lo que no estoy seguro es de un comentario 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
CoDec, MoDem .... Me gusta más "SeDes" :)
nawfal
52

A continuación se muestran algunos puntos de referencia recientes que muestran el rendimiento de los populares serializadores .NET.

Los puntos de referencia de Burning Monks muestran el rendimiento de serializar un POCO simple, mientras que los puntos de referencia integrales de Northwind muestran los resultados combinados de serializar una fila en cada tabla del conjunto de datos de Northwind de Microsoft.

ingrese la descripción de la imagen aquí

Básicamente, los búferes de protocolo ( protobuf-net ) son aproximadamente 7 veces más rápidos que el serializador de biblioteca de clase Base más rápido en .NET (XML DataContractSerializer). También es más pequeña que la competencia, ya que también es 2,2 veces menor que Microsoft de formato de serialización más compacto (JsonDataContractSerializer).

Los serializadores de texto de ServiceStack son los más cercanos a igualar el rendimiento del protobuf-net binario, donde su serializador Json es solo 2.58 veces más lento que protobuf-net.

mito
fuente
1
Excelente publicación, pero si es posible, siempre debe colocar barras de error en sus gráficos de barras cuando muestre promedios.
jtromans
¿Por qué JIL no está incluido en las pruebas? (¿Tienes alguna idea de por qué?)
Royi Namir
22

los búferes de protocolo están diseñados para el cable:

  1. tamaño de mensaje muy pequeño: un aspecto es la representación de números enteros de tamaño variable muy eficiente.
  2. Decodificación muy rápida: es un protocolo binario.
  3. protobuf genera C ++ súper eficiente para codificar y decodificar los mensajes - sugerencia: si codifica todos los enteros var o elementos de tamaño estático en él, codificará y decodificará a una velocidad determinista.
  4. Ofrece un modelo de datos MUY rico: codifica de manera eficiente estructuras de datos muy complejas.

JSON es solo texto y debe analizarse . pista: codificar un "mil millones" de int en él tomaría bastantes caracteres: mil millones = 12 caracteres (escala larga), en binario encaja en un uint32_t Ahora, ¿qué hay de intentar codificar un doble? eso sería MUCHO MUCHO peor.

Hassan Syed
fuente
4
Sin embargo, tiene la desventaja bastante desafortunada de no manejar la herencia y, aunque la composición es una alternativa válida, prefiero que mi objeto de transferencia de datos no me obligue a usar la composición en lugar de la herencia.
Mark Green
4
Creo que las extensiones se pueden usar de una manera muy similar a la herencia ... developers.google.com/protocol-buffers/docs/reference/…
kralyk
1
Sí, las extensiones son un muy buen punto. Lo uso en la práctica en el trabajo todos los días.
Yngve Sneen Lindal
"Los búferes de protocolo están diseñados para el cable" ¿Qué es "el cable"?
Marcos Pereira
@marcospgp the wiresignifica solo red. Ahora, cuando usamos tantas redes inalámbricas, puede parecer extraño.
Victor Yarema