Acabamos de hacer un estudio interno sobre serializadores, aquí hay algunos resultados (¡para mi referencia futura también!)
Ahorro = serialización + pila RPC
La mayor diferencia es que Thrift no es solo un protocolo de serialización, es una pila RPC completa que es como una pila SOAP moderna. Entonces, después de la serialización, los objetos podrían (pero no obligatorios) enviarse entre máquinas a través de TCP / IP. En SOAP, comenzó con un documento WSDL que describe completamente los servicios disponibles (métodos remotos) y los argumentos / objetos esperados. Esos objetos fueron enviados a través de XML. En Thrift, el archivo .thrift describe completamente los métodos disponibles, los objetos de parámetros esperados y los objetos se serializan a través de uno de los serializadores disponibles (conCompact Protocol
un protocolo binario eficiente, que es el más popular en producción).
ASN.1 = Gran papá
ASN.1 fue diseñado por personas de telecomunicaciones en los años 80 y es difícil de usar debido al soporte limitado de la biblioteca en comparación con los serializadores recientes que surgieron de la gente de CompSci. Hay dos variantes, la codificación DER (binaria) y la codificación PEM (ascii). Ambos son rápidos, pero DER es más rápido y tiene un tamaño más eficiente de los dos. De hecho, ASN.1 DER puede mantener fácilmente (y a veces superar) los serializadores que fueron diseñados 30 añosdespués de sí mismo, un testimonio de su diseño bien diseñado. Es muy compacto, más pequeño que Protocol Buffers y Thrift, solo superado por Avro. El problema es tener grandes bibliotecas que admitir y en este momento Bouncy Castle parece ser la mejor para C # / Java. ASN.1 es el rey en seguridad y sistemas criptográficos y no va a desaparecer, así que no se preocupe por las 'pruebas futuras'. Solo consigue una buena biblioteca ...
MessagePack = medio del paquete
No está mal, pero no es el más rápido, ni el más pequeño ni el mejor compatible. No hay razón de producción para elegirlo.
Común
Más allá de eso, son bastante similares. La mayoría son variantes del TLV: Type-Length-Value
principio básico .
Protocol Buffers (originado en Google), Avro (basado en Apache, utilizado en Hadoop), Thrift (originado en Facebook, ahora proyecto Apache) y ASN.1 (originado en Telecom) implican cierto nivel de generación de código donde primero expresa sus datos en un serializador específico del formato, entonces el "compilador" del serializador generará el código fuente para su idioma a través de la code-gen
fase. La fuente de la aplicación usa estas code-gen
clases para IO. Tenga en cuenta que ciertas implementaciones (por ejemplo: la biblioteca Avro de Microsoft o ProtoBuf.NET de Marc Gavel) le permiten decorar directamente sus objetos POCO / POJO de nivel de aplicación y luego la biblioteca usa directamente esas clases decoradas en lugar de cualquier clase de código gen. Hemos visto que esta oferta mejora el rendimiento, ya que elimina una etapa de copia de objetos (desde los campos POCO / POJO de nivel de aplicación hasta los campos de generación de código).
Algunos resultados y un proyecto en vivo para jugar
Este proyecto ( https://github.com/sidshetye/SerializersCompare ) compara serializadores importantes en el mundo C #. La gente de Java ya tiene algo similar .
1000 iterations per serializer, average times listed
Sorting result by size
Name Bytes Time (ms)
------------------------------------
Avro (cheating) 133 0.0142
Avro 133 0.0568
Avro MSFT 141 0.0051
Thrift (cheating) 148 0.0069
Thrift 148 0.1470
ProtoBuf 155 0.0077
MessagePack 230 0.0296
ServiceStackJSV 258 0.0159
Json.NET BSON 286 0.0381
ServiceStackJson 290 0.0164
Json.NET 290 0.0333
XmlSerializer 571 0.1025
Binary Formatter 748 0.0344
Options: (T)est, (R)esults, s(O)rt order, (S)erializer output, (D)eserializer output (in JSON form), (E)xit
Serialized via ASN.1 DER encoding to 148 bytes in 0.0674ms (hacked experiment!)