¿Las mayores diferencias de Thrift vs Protocol Buffers?

286

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

serialization protocol-buffers thrift

— Jonas
fuente

44

Como nota al margen, Marc Gravell mantiene una biblioteca para trabajar con el protobuf de Google llamado protobuf.net y está en code.google.com/p/protobuf-net

— RCIX

55

Esta pregunta y algunas de las siguientes respuestas tienen aproximadamente 6 años. Probablemente muchas cosas han cambiado desde entonces.

— AlikElzin-kilaka

159

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

Thrift admite 'excepciones'
Los Buffers de protocolo tienen mucha mejor documentación / ejemplos
Thrift tiene un Settipo incorporado
Los Buffers de protocolo permiten "extensiones": puede extender un protocolo externo para agregar campos adicionales, al tiempo que permite que el código externo opere en los valores. No hay forma de hacer esto en Thrift
Encuentro Protocol Buffers mucho más fácil de leer

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

— hazzen
fuente

16

Esta presentación los explica bien a partir de 2013 slideshare.net/IgorAnishchenko/pb-vs-thrift-vs-avro

— BAR

13

thrift admite como 10 idiomas más

— Elijah Saounkine 01 de

1

Para algunos idiomas puede agregar extensiones. Por ejemplo, Thrift genera clases parciales para C # que son fáciles de extender. Sin embargo, esa no es la regla general, es cierto.

— JensG

soporte grpc 1.0 (proto3) maptambién

— KindDragon

85

Otra diferencia importante son los idiomas admitidos por defecto.

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

— Mike Gray
fuente

16

protobuf tiene un excelente soporte de ruby github.com/macks/ruby-protobuf y code.google.com/p/ruby-protobuf . Estoy usando protobuf de C # (3.5) y Ruby, C # serializando los datos y, cuando es necesario, Ruby deserializando y trabajando en la tarea.

— Bryan Bailliache

66

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

— Igor Gatis

se puede utilizar directamente protobuf C ++ archivos en c objetivo (tanto para iOS y OS X) que mira esto qn

— Tushar Koul

Veo que code.google.com/p/protobuf-net a menudo se menciona como un puerto protobuf para C #, pero no es completamente cierto. Una de las características importantes de Protobuf y Thrift es la definición de estructura externa, por lo que la misma definición puede ser utilizada por diferentes idiomas. protobuf-net no admite esta característica porque incorpora la definición de estructura dentro del código C #.

— Andriy Tylychko

@AndyT: Eso es discutible, depende de si es una ventaja que la definición de estructura sea EXTERNA para todos los idiomas que desea admitir. Con protobuf-net, usted define su estructura de datos en C # y genera el archivo .proto a partir de eso, que luego puede usarse para crear el soporte en los otros idiomas. Considero que esto es una ventaja, ya que soy muy centrado en C # y estoy en el proceso de integrar Android / Java con una gran aplicación .Net existente. Por lo tanto, quiero seguir considerando que mis clases de C # son las definiciones de estructura definitivas.

— RenniePet

73

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

— saidimu apale
fuente

9

Eso no es cierto. Las memorias intermedias de protocolo definen una API de servicio RPC y hay algunas bibliotecas disponibles para implementar el paso del mensaje.

— Stephen

77

No dije que Protobuf no tiene un RPC definido, solo que no parece haber sido diseñado para eso, al menos no la versión externa a la que todos tienen acceso. Lea el comentario de este ingeniero de Google aquí

— dijo

9

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

— Alec Thomas

2

Para mí, es un buen punto sobre ProtoBuf. Si solo necesita serializar, no agregue código inútil. Y si en el futuro, necesita enviarlo por RPC, no hay problema, puede funcionar. Utilizo Netty para la red, y Protobuf está perfectamente integrado, así que no hay problema, no hay prueba y maximizo el rendimiento.

— Kikiwa

14

Protobufs fueron, de hecho, diseñados con RPC en mente. Google acaba de abrir ese componente recientemente - grpc.io

— andybons

57

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

Para ver más de cerca las diferencias, consulte las diferencias de código fuente en este proyecto de código abierto .

— eishay
fuente

1

Sugerencia rápida: sería bueno si hubiera otro formato no binario (xml o json?) Utilizado como línea de base. No ha habido buenas pruebas que muestren tendencias generales: se supone que PB y Thrift son más eficientes, pero si es y por cuánto, es una pregunta abierta.

— StaxMan

44

¿0.02 segundos? No tengo ese tiempo libre

— Chris S

1

Ahora que Thrift tiene múltiples protocolos (incluido un TCompactProtocol), creo que la primera viñeta ya no se aplica.

— Janus Troelsen

13

La opción de optimización de velocidad ahora es la predeterminada para los buffers de protocolo ( code.google.com/apis/protocolbuffers/docs/proto.html )

— Willem

55

¿Obtenemos un 30% de objetos más pequeños con el conjunto "optimizar_para = velocidad"? ¿O eso está comprometido?

— Prashant Sharma

56

Como dije como tema "Thrift vs Protocol buffers" :

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

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: compatibilidad integrada en Protobuf
El soporte de Protobuf para otros idiomas (incluidos 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 una documentación mucho mejor y muchos ejemplos.
Thrift viene con un buen tutorial
Los objetos Protobuf son más pequeños.
Protobuf es más rápido cuando se usa la configuración "optimizar_para = VELOCIDAD"
Thrift ha integrado la implementación RPC, mientras que para Protobuf las soluciones RPC están separadas, pero disponibles (como Zeroc ICE ).
Protobuf se lanza bajo licencia de estilo BSD
Thrift se lanza bajo licencia Apache 2

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

— Grzegorz Wierzowiecki
fuente

10

Ahora este es un círculo completo. Has publicado exactamente la misma respuesta a tres preguntas (similares) que siempre se vinculan a cualquiera o. Siento que estoy jugando Zelda y he perdido una señal.

— ChrisR

+ ChrisR je, 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 la captura!

— Grzegorz Wierzowiecki

66

"Thrift viene con un buen tutorial", qué gracioso. Es el tutorial más incompleto que he visto. Tan pronto como quiera hacer algo al lado de TSimpleServer, quedará atrapado allí

— Marian Klühspies

Thrift también tiene el complemento Wireshark: github.com/andrewcox/wireshark-with-thrift-plugin

— CCoder

8

Protocol Buffers parece tener una representación más compacta, pero esa es solo una impresión que obtengo al leer el documento técnico de Thrift. En sus propias palabras:

Decidimos optar por algunas optimizaciones de almacenamiento extremas (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 hacer fácilmente si encontramos un caso de uso crítico para el rendimiento que lo exige.

Además, puede ser solo mi impresión, pero Protocol Buffers parece tener algunas abstracciones más gruesas en torno a las versiones de estructura. Thrift tiene cierto soporte de versiones, pero se necesita un poco de esfuerzo para que esto suceda.

— Daniel Spiewak
fuente

1

¿Por qué el hecho de que Thrift admite no ser lo más compacto posible te hace creer que los Protocol Buffers lo son?

— Michael Mior

1

Las memorias intermedias de protocolo utilizan codificación de enteros de longitud variable, tanto para valores como para identificadores de campo. Entonces, el caso muy común de enviar un campo int con un valor pequeño será de dos bytes, no int16 e int32.

— Poolie

"Los búferes de protocolo usan codificación de enteros de longitud variable" - también TCompactProtocol

— JensG

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 tipos u otras sofisticadas conversiones utf8, etc. que ofrece protobuff.

Entonces, si la serialización / deserialización es todo lo que necesita, entonces probablemente pueda usar algo más.

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

— dhruvbird
fuente

7

Una cosa obvia que aún no se menciona es que puede ser tanto un pro o un contra (y es lo mismo para ambos) es 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 desventaja.

Además, ambos tienen un poco menos de 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 algunos otros formatos (xml, json) también.

— StaxMan
fuente

3

Es trivial generar un búfer de protocolo en una representación de texto que sea mucho más legible para los humanos que XML: my_proto.DebugString (). Para ver un ejemplo, consulte code.google.com/apis/protocolbuffers/docs/overview.html

— SuperElectric

Por supuesto, lo mismo para todos los formatos binarios, pero eso no los hace legibles tal como están (depuración en el cable). Peor aún, para protobuf, realmente necesita el esquema def para conocer los nombres de campo.

— StaxMan

Thrift admite protocolos diferentes, incluso definidos por el usuario. Puedes usar binario, compacto, json o algo que inventaste la semana pasada.

— JensG

6

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

55

Ejecuté Thrift en Windows con éxito. Use el tenedor de Windows en github.com/aubonbeurre/thrift

— Sergey Podobry

20

La rama principal oficial ahora también tiene soporte para Windows.

— Janus Troelsen

55

@dalle - Alex P agregó soporte de hilo Boost en Thrift. Ahora es el subproceso predeterminado para Windows. * NIX por defecto es pthreads. Y para confirmar Janus T, Thrift ahora es totalmente compatible con Windows.

— pmont

21

Esta es información desactualizada. Thrift funciona perfectamente en Windows desde hace mucho tiempo.

— JensG

6

ProtocolBuffers es MÁS RÁPIDO.
Aquí hay un buen punto de referencia:
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 repositorio de Github de Marc Gravell .

— Stefan Steiger
fuente

4

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

Protocol Buffers están diseñados exclusivamente para la serialización, no es un marco como Thrift.

— Babra Cunningham
fuente

3

¿Qué quiere decir con marco RPC y en qué se diferencia de gRPC de protobuf ?

— marcelocra

gRPC no está empaquetado junto con protobuf. Fue desarrollado como 10 años después. Thrift viene empaquetado con el marco completo RPC. Fue hecho juntos.

— trilogía

3

Por un lado, protobuf no es una implementación completa de RPC. Requiere algo como gRPC para acompañarlo.

gPRC es muy lento en comparación con Thrift:

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

— trilogía
fuente

0

Hay algunos puntos excelentes aquí y voy a agregar otro en caso de que alguien se cruce aquí.

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

PD: vea este excelente proyecto de referencia mediante el thekvscual compara muchos serializadores, incluidos thrift-binary, thrift-compact y protobuf: https://github.com/thekvs/cpp-serializers

PD: Hay otro serializador llamado YASque también ofrece esta opción, pero no tiene esquema. Vea el enlace de arriba.

— Sinapsis
fuente

0

También es importante tener en cuenta que no todos los idiomas compatibles se comparan consistentemente con el ahorro o el protofoto. En este punto, se trata de la implementación de módulos, además de la serialización subyacente. Asegúrese de verificar los puntos de referencia para cualquier idioma que planee usar.

— JSON
fuente