Las mayores diferencias de Thrift vs Protocol Buffers?

¿Cuáles son los mayores pros y contras de Apache Thrift vs Google’s Protocol Buffers ?

Ambos ofrecen muchas de las mismas características; sin embargo, hay algunas diferencias:

  • Thrift admite ‘excepciones’
  • Los búferes de protocolo tienen mucha mejor documentación / ejemplos
  • Thrift tiene un tipo de Set incorporado
  • Los búfers de protocolo permiten “extensiones”: puede extender un proto externo para agregar campos adicionales, mientras permite que el código externo opere en los valores. No hay forma de hacer esto en Thrift
  • Encuentro Buffers de Protocolo mucho más fácil de leer

Básicamente, son bastante equivalentes (con Protocol Buffers ligeramente más eficiente de lo que he leído).

Otra diferencia importante son los idiomas soportados por defecto.

  • Buffers de protocolo: Java, Android Java, C ++, Python, Ruby, C #, Go, Objective-C, Node.js
  • Thrift: Java, C ++, Python, Ruby, C #, Go, Objective-C, JavaScript, Node.js, Erlang, PHP, Perl, Haskell, Smalltalk, OCaml, Delphi, D, Haxe

Ambos podrían extenderse a otras plataformas, pero estos son los enlaces de idiomas disponibles listos para usar.

RPC es otra diferencia clave. Thrift genera código para implementar clientes RPC y servidores donde el Protocolo Buffers parece diseñado principalmente como un formato de intercambio de datos solo.

  • Los objetos serializados de Protobuf son aproximadamente un 30% más pequeños que Thrift.
  • La mayoría de las acciones que puede querer hacer con objetos protobuf (crear, serializar, deserializar) son mucho más lentas que el ahorro a menos que active la option optimize_for = SPEED .
  • Thrift tiene estructuras de datos más ricas (Map, Set)
  • La API de Protobuf se ve más limpia, aunque las clases generadas están empaquetadas como clases internas, lo que no es tan agradable.
  • Las enumeraciones de ahorro no son Java Enums reales, es decir, son solo entradas. Protobuf tiene enums de Java reales.

Para ver de cerca las diferencias, revisa los diffs del código fuente en este proyecto de código abierto .

Como he dicho como tema “Thrift vs Protocol buffers” :

En referencia a la comparación Thrift vs Protobuf vs JSON :

  • Thrift admite fuera de la caja AS3, C ++, C #, D, Delphi, Go, Graphviz, Haxe, Haskell, Java, Javascript, Node.js, OCaml, Smalltalk, Typescript, Perl, PHP, Python, Ruby, …
  • C ++, Python, Java: soporte integrado en Protobuf
  • El soporte de Protobuf para otros lenguajes (incluyendo Lua, Matlab, Ruby, Perl, R, Php, OCaml, Mercury, Erlang, Go, D, Lisp) está disponible como Complementos de terceros (por cierto, aquí está el soporte de SWI-Prolog ).
  • Protobuf tiene mucha mejor documentación y muchos ejemplos.
  • Thrift viene con un buen tutorial
  • Los objetos Protobuf son más pequeños
  • Protobuf es más rápido al unir “optimize_for = SPEED”
  • Thrift ha integrado la implementación RPC, mientras que las soluciones Protobuf RPC están separadas, pero disponibles (como Zeroc ICE ).
  • Protobuf se lanza bajo licencia de estilo BSD
  • Thrift se libera bajo la licencia de Apache 2

Además, hay muchas herramientas adicionales interesantes disponibles para esas soluciones, que podrían decidir. Aquí hay ejemplos de Protobuf: Protobuf-wireshark , protobufeditor .

Pude obtener un mejor rendimiento con un protocolo basado en texto en comparación con protobuff en python. Sin embargo, no hay verificación de tipo u otra conversión de lujo utf8, etc … que ofrece protobuff.

Entonces, si la serialización / deserialización es todo lo que necesita, entonces probablemente pueda usar otra cosa.

http://dhruvbird.blogspot.com/2010/05/protocol-buffers-vs-http.html

El protocolo Buffers parece tener una representación más compacta, pero esa es solo una impresión que obtengo leyendo el libro blanco de Thrift. En sus propias palabras:

Decidimos evitar algunas optimizaciones extremas de almacenamiento (es decir, empaquetar enteros pequeños en ASCII o usar un formato de continuación de 7 bits) por simplicidad y claridad en el código. Estas alteraciones se pueden realizar fácilmente si encontramos un caso de uso crítico para el rendimiento que las exija.

Además, puede que solo sea mi impresión, pero Protocol Buffers parece tener algunas abstracciones más gruesas alrededor del control de versiones. Thrift tiene cierto soporte de control de versiones, pero se necesita un poco de esfuerzo para hacerlo realidad.

Una cosa obvia aún no mencionada es que puede ser a la vez pro o contra (y es lo mismo para ambos) que son protocolos binarios. Esto permite una representación más compacta y posiblemente más rendimiento (pros), pero con una legibilidad reducida (o más bien, depuración), una estafa.

Además, ambos tienen menos soporte de herramientas que los formatos estándar como xml (y tal vez incluso json).

(EDITAR) Aquí hay una comparación interesante que aborda las diferencias de tamaño y rendimiento, e incluye números para otros formatos (xml, json) también.

Y según la wiki, el tiempo de ejecución de Thrift no se ejecuta en Windows.

ProtocolBuffers es MÁS RÁPIDO.
Hay un buen punto de referencia aquí:
http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking

También es posible que desee ver Avro, ya que Avro es aún más rápido.
Microsoft tiene un paquete aquí:
http://www.nuget.org/packages/Microsoft.Hadoop.Avro

Por cierto, el más rápido que he visto es Cap’nProto ;
La implementación de AC # se puede encontrar en el repository Github de Marc Gravell .

Creo que la mayoría de estos puntos han pasado por alto el hecho básico de que Thrift es un framework RPC, que tiene la capacidad de serializar datos usando una variedad de métodos (binarios, XML, etc.).

Los búfers de protocolo están diseñados exclusivamente para la serialización, no es un framework como Thrift.

Por un lado, protobuf no es una implementación completa de RPC. Requiere algo como gRPC para ir con eso.

gPRC es muy lento en comparación con Thrift:

http://szelei.me/rpc-benchmark-part1/

Aquí hay algunos puntos excelentes y voy a agregar otro en caso de que la ruta de alguien se cruce aquí.

Thrift le brinda la opción de elegir entre el serializador thrift-binary y thrift-compact (de), thrift-binary tendrá un excelente rendimiento pero mayor tamaño de paquete, mientras que el ahorro compacto le dará una buena compresión pero necesita más potencia de procesamiento. Esto es útil porque siempre puedes cambiar entre estos dos modos tan fácilmente como cambiar una línea de código (diablos, incluso hazlo configurable). Por lo tanto, si no está seguro de cuánto debe optimizar su aplicación para el tamaño del paquete o la potencia de procesamiento, el ahorro puede ser una opción interesante.

PD: thekvs este excelente proyecto de referencia de thekvs que compara muchos serializadores, incluidos los de ahorro y binario, ahorro de dinero compacto y protobuf: https://github.com/thekvs/cpp-serializers

PD: Hay otro serializador llamado YAS que también proporciona esta opción, pero no contiene YAS esquema, vea el enlace de arriba.

Intereting Posts