¿Las mayores diferencias de Thrift versus Protocol Buffers?

7

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

Decidimos contra algunas optimizaciones extremas de almacenamiento (es decir embalaje enteros pequeños en ASCII o utilizando un formato de continuación de 7 bits) en aras de la simplicidad y la 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 sobre el control de versiones struct. Thrift tiene cierto soporte de control de versiones, pero se necesita un poco de esfuerzo para hacerlo realidad.

Fuente

2008-09-16 04:23:05

+0

¿Por qué el hecho de que Thrift admite que no es lo más compacto posible lo hace creer que los Buffers de Protocolo sí lo son? –

+0

Los búferes de protocolo usan codificación de entero de longitud variable, tanto para los valores como para los identificadores de campo. Entonces, el caso muy común de enviar un campo int con un valor pequeño será de dos bytes, no un int16 e int32. – poolie

133

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

Thrift soportes 'excepciones'
Protocol Buffers tienen mucho mejor documentación/ejemplos
Thrift tiene una orden interna del Set tipo
Protocol Buffers permiten "Extensiones" - se puede extienda un proto externo para agregar campos adicionales, mientras permite que el código externo opere en los valores. No hay manera de hacer esto en Thrift
encuentro Protocol Buffers mucho más fácil de leer

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

Fuente

2008-09-16 04:25:40 hazzen

+87

¿Alguno de estos puntos cambió en los últimos 4 años? –

+14

Esta presentación los explica bien desde 2013 http://www.slideshare.net/IgorAnishchenko/pb-vs-thrift-vs-avro – BAR

+12

soportes de ahorro como 10 idiomas más –

56

Los objetos serializados de Protobuf son aproximadamente 30% más pequeños que Thrift.
La mayoría de las acciones que puede querer hacer con objetos protobuf (crear, serializar, deserializar) son much slower than thrift a menos que active 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 que no es tan agradable.
Las enumeraciones de Thrift no son Java Enums reales, es decir, son solo entradas. Protobuf tiene enums de Java reales.

Para ver de cerca las diferencias, consulte los diffs del código fuente en this open source project.

Fuente

2008-11-17 18:00:31 eishay

+34

Eso es" mucho más lento cuando no se optimiza la velocidad "... –

+0

Aquí está la nueva prueba con la optimización en: http://eishay.blogspot.com/2008/11/protobuf-with-option-optimize-for-speed.html – scobi

+1

Sugerencia rápida: sería genial si hubiera otra formato no binario (xml o json?) utilizado como línea de base. No ha habido buenas pruebas que demuestren tendencias generales, suponiendo que el PB y el Ahorro sean más eficientes, pero si y por cuánto, si es así, es una pregunta abierta. – StaxMan

7

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).

(EDIT) Aquí hay un Interesting comparison que aborda las diferencias de rendimiento de tamaño &, e incluye números para algunos otros formatos (xml, json) también.

Fuente

2009-03-11 01:19:02 StaxMan

+3

Es trivial dar salida a un búfer de protocolo a una representación de texto que es mucho más legible para el ser humano que XML: my_proto.DebugString(). Para ver un ejemplo, consulte https://code.google.com/apis/protocolbuffers/docs/overview.html – SuperElectric

+0

Por supuesto, lo mismo para todos los formatos binarios, pero eso no los hace legibles (depuración en el cable) . Peor aún, para protobuf, realmente necesita el esquema para conocer los nombres de los campos. – StaxMan

74

Otra diferencia importante son los idiomas admitidos por defecto.

Protocol Buffers: Java, Android Java, C++, Python, Ruby, C#, Go, Objective-C, Node.js
Ahorro: Java, C++, Python, Ruby, C#, Go, Objetivo- 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 fuera de la la caja.

Fuente

2009-08-03 16:08:23

+16

protobuf tiene excelente soporte de ruby https://github.com/macks/ruby-protobuf y http://code.google.com/p/ruby-protobuf/. Estoy usando protobuf de C# (3.5) y Ruby, C# serializando los datos, y cuando es necesario, Ruby deserializa y trabaja en la tarea. –

+8

Hay una biblioteca para protobuf en .NET: http://code.google.com/p/protobuf-net/ – Jordan

+6

http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns enumera PHP, Ruby, Erlang, Perl, Haskell, C#, OCaml más Actiona Script, Common Lisp, Go, Lua, Mathlab, Visual Basic, Scala. Pensé que estas son todas las implementaciones de terceros. – Gatis

6

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

Fuente

2009-09-27 00:11:11 hplbsh

+3

Esto es de lejos una de las cosas más importantes. En realidad, es triste, debería funcionar en Windows, Thrift ya depende de boost, pero Thrift no usa Boost.Thread ni Boost.Asio, en su lugar Thrift usa pthread directamente, lo cual no es realmente bueno para la portabilidad. – dalle

+3

Ejecuto Thrift en Windows con éxito. Use el tenedor de Windows en https://github.com/aubonbeurre/thrift –

+16

La rama principal oficial ahora también cuenta con soporte de Windows. –

64

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.

Fuente

2010-03-28 07:43:16 saidimu

+6

Eso no es verdad. Los búferes de protocolo definen una API de servicio RPC y hay algunas bibliotecas disponibles para implementar el paso de mensajes. – Stephen

+5

No he dicho que Protobuf no tenga RPC definido, solo que no parece haber sido diseñado para eso, al menos no para la versión externa a la que todos tienen acceso.Lea el comentario de este ingeniero de Google [aquí] (http://steve.vinoski.net/blog/2008/07/13/protocol-buffers-leaky-rpc/#comment-1093) – saidimu

+8

Más importante aún, Thrift tiene soporte RPC integrado Protobuf actualmente se basa en bibliotecas de terceros, lo que significa menos ojos, menos pruebas, código menos confiable. –

8

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.

Por lo tanto, 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

Fuente

2010-05-03 19:09:14 dhruvbird

51

Como he dicho como "Thrift vs Protocol buffers" tema:

Refiriéndose a Thrift vs Protobuf vs JSON comparison:

Thrift apoya 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 - in- soporte de caja en Protobuf
Protobuf support for other languages (including Lua, Matlab, Ruby, Perl, R, Php, OCaml, Mercury, Erlang, Go, D, Lisp) is available as Third Party Addons (por cierto Here is SWI-Prolog support).
Protobuf tiene mucha mejor documentación y muchos ejemplos.
Thrift viene con un buen tutorial
objetos protobuf son más pequeños
Protobuf es más rápido cuando unsing "optimize_for = VELOCIDAD"
Thrift ha incorporado la aplicación RPC, mientras que para Protobuf RPC solutions are separated, but available (como Zeroc ICE).
Protobuf se distribuye bajo licencia BSD
Thrift se distribuye bajo la licencia Apache 2

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

Fuente

2011-08-27 18:25:01

+6

Ahora este es un círculo completo. Ha publicado la misma respuesta exacta a tres preguntas (similares) que siempre se relacionan con cualquiera de ellos o. Siento que estoy jugando Zelda y perdí un signo. – ChrisR

+0

+ ChrisR heh, no recuerdo cómo sucedió. Aunque hubo un par de preguntas similares, tal vez debería hacer tres estructuras similares en lugar de ciclo. Un día ... Es una pregunta muy antigua y ahora estoy respondiendo por teléfono. De todos modos, gracias por atrapar! –

+3

"Thrift viene con un buen tutorial": qué divertido. Es el tutorial más incompleto que he visto en mi vida. Tan pronto como quieras hacer algo al lado de TSimpleServer te quedas atascado allí –

6

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 puede ser que desee ver en Avro, como Avro es incluso 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;
Se puede encontrar una implementación de C# en Github-repository of Marc Gravell.

Fuente

2014-08-29 07:21:56

2

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.

Fuente

2017-04-14 14:47:35

+0

¿Qué quieres decir con el framework RPC y cómo es eso? diferente de protobuf [gRPC] (http://www.grpc.io/)? – marcelocra

0

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

Thrift le ofrece 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 procesamiento poder. 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.

PS: Ver este excelente proyecto de referencia por thekvs que compara muchas serializadores incluyendo el ahorro en binario, el ahorro-compacto y protobuf: https://github.com/thekvs/cpp-serializers

PS: Hay otro serializador llamado YAS que da esta opción también, pero es sin esquema, vea el enlace de arriba.

Fuente

2017-09-03 08:10:00 Sinapse

0

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/

Fuente

2018-01-28 03:33:00 MrBlob

¿Las mayores diferencias de Thrift versus Protocol Buffers?

Respuesta

Cuestiones relacionadas