it-swarm-es.tech

¿Las mayores diferencias entre Thrift y Protocol Buffers?

¿Cuáles son las mayores ventajas y desventajas de Apache Thrift vs Protocol Buffers de Google ?

263
Bob

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

  • Thrift soporta 'excepciones'
  • Protocol Buffers tienen mucho mejor documentación/ejemplos
  • Thrift tiene un tipo Set incorporado
  • Los búferes de protocolo permiten "extensiones": puede extender un protocolo externo para agregar campos adicionales, al tiempo que permite que un código externo funcione en los valores. No hay manera de hacer esto en Thrift
  • Encuentro Protocol Buffers mucho más fácil de leer

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

149
hazzen

Otra diferencia importante son los idiomas soportados por defecto.

  • Protocol Buffers: 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 de manera inmediata.

80
Mike Gray

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

70
saidimu apale
  • Los objetos serializados de Protobuf son aproximadamente un 30% más pequeños que Thrift.
  • La mayoría de las acciones que puede hacer con los objetos protobuf (crear, serializar, deserializar) son mucho más lentas que el ahorro a menos que active option optimize_for = SPEED .
  • Thrift tiene estructuras de datos más ricas (Mapa, Conjunto)
  • La API de Protobuf parece más limpia, aunque las clases generadas están todas empaquetadas como clases internas, lo que no es tan agradable.
  • Los enums de Thrift no son enums de Java reales, es decir, son solo ints. Protobuf tiene verdaderas enumeraciones de Java.

Para ver de cerca las diferencias, consulte el código fuente que se encuentra en este proyecto de código abierto .

57
eishay

Como he dicho como "Búferes de protocolo vs de Thrift" tema:

Refiriéndose a Comparación de Thrift vs Protobuf vs JSON :

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

55

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 conversiones de lujo, etc. que ofrece protobuff.

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

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

8
dhruvbird

Una cosa obvia que aún no se menciona es que puede ser tanto un pro como un con (y es el 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, mejor dicho, debuggability), una estafa.

Además, ambos tienen poco menos soporte para herramientas que los formatos estándar como xml (y quizás incluso json).

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

7
StaxMan

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

Decidimos no realizar 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 cuando nos encontramos con un caso de uso crítico para el rendimiento que lo exige.

Además, puede que solo sea mi impresión, pero los búferes de protocolo parecen 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.

7
Daniel Spiewak

ProtocolBuffers es más rápido.
Hay un punto de referencia de Niza 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 ;
Una implementación de C # se puede encontrar en el repositorio Github de Marc Gravell .

6
Stefan Steiger

Y de acuerdo con wiki el tiempo de ejecución de Thrift no se ejecuta en Windows.

6
hplbsh

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

gPRC es muy lento en comparación con Thrift:

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

3
trilogy

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 (binarios, XML, etc.).

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

3
Babra Cunningham

También es importante tener en cuenta que no todos los idiomas compatibles se comparan de forma consistente con thrift o protobuf. En este punto, es una cuestión de la implementación de los módulos además de la serialización subyacente. Tenga cuidado de verificar los puntos de referencia para cualquier idioma que planee usar.

0
JSON

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

Thrift le da la opción de elegir entre thrift-binary y thrift-compact (des) serializador, thrift-binary tendrá un excelente rendimiento pero un tamaño de paquete más grande, mientras que thrift-compact le dará una buena compresión pero necesita más capacidad 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 configurarlo). Entonces, si no está seguro de cuánto debe optimizarse su aplicación para el tamaño del paquete o en la potencia de procesamiento, el ahorro puede ser una opción interesante.

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

PD: hay otro serializador llamado YAS que también ofrece esta opción pero no tiene esquema, vea el enlace de arriba.

0
Sinapse