¿Cuáles son las principales diferencias entre Apache Thrift, Google búferes de protocolo, MessagePack, ASN.1 y Apache Avro?

Question

Todos ellos proporcionan la serialización binaria, marcos de RPC e IDL. Estoy interesado en las diferencias fundamentales que existen entre ellos y características (rendimiento, facilidad de uso, la programación de apoyo idiomas).

Si conoce alguna otras tecnologías similares, por favor mencione en una respuesta.

Answer 1

ASN.1 es un estándar ISO / ISE. Tiene un lenguaje fuente muy legible y una variedad de back-ends, tanto en binario y legible. Al ser un estándar internacional (y uno antiguo en eso!) El idioma de origen es una cocina-sinkish poco (menos de la misma manera que el océano Atlántico es un poco húmeda) pero es muy bien especificado y tiene buena cantidad de apoyo . (Probablemente se puede encontrar una biblioteca ASN.1 para cualquier lenguaje que nombre si usted cava lo suficiente, y si no hay buenas bibliotecas de lenguaje C disponibles que se pueden utilizar en las FFI). Es, por ser un lenguaje estandarizado, documentado y obsesivamente tiene tutoriales disponibles unos buenos también.

Ahorro no es una norma. Es originaria de Facebook y más tarde de código abierto y es actualmente un proyecto de Apache nivel superior. No está bien documentado - en especial los niveles de tutorial - y para mi (aunque breve) simple vista no parece añadir nada que otros, los esfuerzos anteriores no lo hagan (y en algunos casos mejor). Para ser justos con él, que tiene un número bastante impresionante de los idiomas que soporta fuera de la caja, incluyendo algunos de los no convencionales de alto perfil. El IDL es también vagamente C-similares.

Protocol Buffers no es un estándar. Es un producto de Google que está siendo liberado a la comunidad en general. Es un poco limitado en cuanto a los idiomas soportados fuera de la caja (sólo es compatible con C ++, Python y Java), pero tiene una gran cantidad de ayuda de tercera persona para otros idiomas (de calidad muy variable). Google hace casi todo su trabajo mediante búferes de protocolo, por lo que es un protocolo de curtido en la batalla probado en combate (aunque no tan aguerrido como ASN.1 es. Tiene mucho mejor documentación que hace Thrift, pero, al ser una google producto, es muy probable que sea inestable (en el sentido de constante cambio, no en el sentido de no fiable). el IDL es también similar a C.

Todos los sistemas anteriores usan un esquema definido en algún tipo de IDL para generar código para un idioma de destino que luego se utiliza en la codificación y decodificación. Avro no lo hace. la tipificación de Avro es dinámica y sus datos esquema se utiliza en tiempo de ejecución directa, tanto para codificar y descodificar (que tiene unos costes evidentes en el procesamiento, pero también algunos beneficios obvios vis a vis los lenguajes dinámicos y la falta de una necesidad para este tipo de etiquetado, etc.) . Su esquema utiliza JSON que hace de soporte de Avro en un nuevo lenguaje un poco más fácil de manejar si ya hay una biblioteca JSON. De nuevo, como con la mayoría de los sistemas de Protocolo de Descripción de rueda-reinventar, Avro tampoco está estandarizada.

En lo personal, a pesar de mi relación de amor / odio con él, probablemente me utilizar ASN.1 para la mayoría de los propósitos de RPC y de transmisión de mensajes, a pesar de que en realidad no tiene una pila de RPC (que tendría que hacer uno, pero IOC hacen que bastante simple).

Answer 2

Acabamos de hacer un estudio interno sobre serializadores, aquí están algunos resultados (por mi referencia en el futuro también!)

Thrift = serialización + RPC pila

La mayor diferencia es que Thrift no es sólo un protocolo de serialización, se trata de una pila RPC completo soplado que es como una moderna pila día SOAP. Así que después de la serialización, los objetos podría (pero no obligatorio) enviarse entre máquinas a través de TCP / IP. En SOAP, que se inició con un documento WSDL que describe completamente los servicios disponibles (métodos remotos) y los argumentos / objetos previstos. Esos objetos fueron enviados a través de XML. En Thrift, el archivo .thrift describe completamente los métodos disponibles, objetos de parámetros esperados y los objetos se serializan a través de uno de los serializadores disponibles (con Compact Protocol, un protocolo binario eficiente, siendo la más popular en la producción).

ASN.1 = Gran papá

ASN.1 fue diseñado por la gente de telecomunicaciones en los años 80 y es torpe de usar debido al apoyo biblioteca limitada en comparación con los últimos serializadores que surgieron de la gente CompSci. Hay dos variantes, DER (binario) que codifica y PEM codificación (ascii). Ambos son rápidos, pero DER es más rápido y más eficiente el tamaño de los dos. De hecho DER ASN.1 puede fácilmente mantenerse al día (y, a veces vencer) serializadores que fueron diseñados 30 años diseño de sí mismo, un testimonio de que está bien diseñado. Es muy compacto, más pequeño que búferes de protocolo y Thrift, sólo superado por Avro. La cuestión es tener grandes bibliotecas para apoyar y ahora Castillo Hinchable parece ser el mejor para C # / Java. ASN.1 es el rey en los sistemas de seguridad y cifrado, y no va a desaparecer, así que no se preocupaba por el futuro de pruebas '. Acaba de obtener una biblioteca bien ...

MessagePack = mitad de la tabla

No está mal, pero no es ni el más rápido, ni el más mínimo ni la apoya mejor. No hay razón para elegir la producción de la misma.

Común

Más allá de eso, ellos son bastante similares. La mayoría son variantes del principio básico TLV: Type-Length-Value.

Protocol Buffers (Google originó), Avro (basado en Apache, usado en Hadoop), Thrift (Facebook se originó, ahora proyecto Apache) y ASN.1 (Telecom se originó) todos implican un cierto nivel de generación de código en el que en primer lugar expresar sus datos en un formato serializador-específica, entonces el serializador "compilador" va a generar código fuente de la lengua a través de la fase code-gen. Su fuente de la aplicación a continuación, utiliza estas clases code-gen para IO. Tenga en cuenta que ciertas implementaciones (por ejemplo: la biblioteca de Avro de Microsoft o del mazo de Marc ProtoBuf.NET) le permiten decorar directamente su nivel de aplicación POCO / objetos POJO y luego la biblioteca utiliza directamente esas clases decoradas en lugar de cualquier clase de código de generación de. Hemos visto esta oferta una actuación impulso, ya que elimina una etapa copia de un objeto (de nivel de aplicación campos POCO / POJO a los campos de código-gen).

Algunos resultados y un proyecto vivo para jugar

Este proyecto ( https://github.com/sidshetye/SerializersCompare ) compara serializadores importantes en el C # mundo. La gente de Java ya tienen algo href="https://github.com/eishay/jvm-serializers/wiki" 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!)

Answer 3

Adición a la perspectiva del rendimiento, Uber recientemente evaluado varias de estas bibliotecas en su blog de ingeniería:

https://eng.uber.com/trip-data-squeeze/

El ganador para ellos? MessagePack + zlib para la compresión

Nuestro objetivo era encontrar la combinación de codificación de protocolo y algoritmo de compresión con el resultado más compacto en el más alto velocidad. Hemos probado que codifica protocolo y compresión algoritmo combinaciones de 2.219 viajes pseudoaleatorios anónima de Uber Nueva York Ciudad (poner en un archivo de texto como JSON).

La lección aquí es que sus requisitos de transmisión que la biblioteca es adecuado para usted. Para Uber no podían utilizar un protocolo basado en IDL debido a la naturaleza sin esquema de paso de mensajes que tienen. Esto eliminó un montón de opciones. También para ellos es no sólo la codificación cruda / hora que entra en juego, pero el tamaño de los datos en reposo decodificación.

Tamaño Resultados

Velocidad Resultados

Answer 4

El gran cosa sobre ASN.1 está, que está diseñado para ist no aplicación especificación. Por lo tanto, es muy bueno en la ocultación / ignorando detalle de implementación en cualquier idioma "real" de programación.

Su tarea del ASN.1-compilador para aplicar las reglas de codificación a la asn1-archivo y generar a partir de los dos código ejecutable. Las reglas de codificación se podría dar en la codificación de notación (ECN), o podría ser una de las estandarizados tales como los BER / DER, PER, XER / EXER. Es decir ASN.1 es los tipos y estructuras, las reglas de codificación definen la codificación en el alambre, y por último pero no menos importante las transferencias del compilador a su lenguaje de programación.

Los compiladores libres apoyan C, C ++, C #, Java y Erlang, que yo sepa. El (mucho a caro y patentes / licencias montados) compiladores comerciales son muy versátiles, por lo general absolutamente hasta a la fecha y el apoyo a veces incluso más idiomas, pero ven a sus sitios (OSS Nokalva, MARBEN etc.).

Es sorprendentemente fácil de especificar una interfaz entre las partes de culturas totalmente diferentes de programación (por ejemplo, "incrustado" pueblo "y los agricultores de servidor".) Utilizando estas técnicas: un ASN.1-archivo, la regla de codificación, por ejemplo, BER y un ejemplo UML Diagrama de Interacción. Sin preocupaciones cómo se implementa, dejar cada uno su uso "lo suyo"! Para mí ha funcionado muy bien. BTW .: el sitio de Al OSS Nokalva se puede encontrar por lo menos dos free-to-descarga libros sobre ASN.1 (uno por el otro por Larmouth Dubuisson).

En mi humilde opinión la mayoría de los otros productos sólo trato de ser aún sin otra-RPC-stub-generadores, el bombeo de una gran cantidad de aire en el tema de serialización. Bueno, si uno necesita que uno podría estar bien. Pero para mí, se ven como reinvenciones de Sun-RPC (de fines 80a), pero, ey, que funcionaron muy bien, también.

Answer 5

El Bond de Microsoft ( https://github.com/Microsoft/bond ) es muy impresionante, con un rendimiento , funcionalidades y documentación. Sin embargo, no es compatible con muchas plataformas de destino a partir de ahora (13º Feb 2015). Sólo puedo suponer que es porque es muy nueva. Actualmente es compatible con Python, C # y C ++. Está siendo usado por MS en todas partes. Yo probé, a mí como ac # Developer utilizando bono es mejor que usar protobuf, el ahorro sin embargo he utilizado, así, el único problema que tuvimos fue con la documentación, que tenía que probar muchas cosas para entender cómo se hacen las cosas.

Pocos recursos en Bonos son los siguientes ( https://news.ycombinator.com/item? id = 8866694 , https://news.ycombinator.com/item?id=8866848 , https://microsoft.github.io/bond/why_bond.html)

Answer 6

Para obtener un rendimiento, un punto de datos es jvm-serializadores de referencia - es bastante específica, los mensajes pequeños, pero ayuda fuerza si están en la plataforma Java. Creo que el rendimiento en la voluntad general a menudo no sea la diferencia más importante. También: NUNCA tomar las palabras de los autores como el Evangelio; muchas demandas anunciadas son falsas (sitio msgpack por ejemplo, tiene algunas afirmaciones dudosas, ya que puede ser rápido, pero la información es muy incompleta, caso de uso no muy realista).

Una gran diferencia es si un esquema debe ser utilizado (PB, Thrift al menos; Avro puede ser opcional; ASN.1 creo también; MsgPack, no necesariamente).

También: en mi opinión, es bueno ser capaz de usar en capas, el diseño modular; es decir, la capa de RPC debe formato de datos no dicta, la serialización. Desafortunadamente la mayoría de los candidatos no bien agrupar estos.

Por último, la hora de elegir el formato de datos, hoy en día el rendimiento no hace uso excluyen de formatos textuales. Hay ardientes analizadores rápida JSON (y bastante rápida transmisión analizadores XML); y cuando se considera la interoperabilidad de lenguajes de scripting y la facilidad de uso, formatos y protocolos binarios pueden no ser la mejor opción.