¿Las mayores diferencias de Thrift vs Protocol Buffers?

Respuestas:

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 :

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.


fuente
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
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
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