protocol protobuf buffers serialization protocol-buffers thrift

serialization - buffers - protobuf vs json



¿Las mayores diferencias entre Thrift y Protocol Buffers? (13)

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

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

Como he dicho en el tema "Thrift vs Protocol buffers" :

Refiriéndose a la 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 .

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.

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

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.

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/

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 utilizar un formato de continuación de 7 bits) por motivos de 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 cuanto al versionamiento de estructuras. Thrift tiene cierto soporte de versiones, pero requiere un poco de esfuerzo para que esto suceda.

Pude obtener un mejor rendimiento con un protocolo basado en texto en comparación con protobuff en python. Sin embargo, no hay comprobación de tipos u otras conversiones de lujo, etc. que ofrece protobuff.

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

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

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

Una cosa obvia que aún no se ha mencionado 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 más bien, 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.

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

  • 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 la 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.
  • Los enums de Thrift no son enums reales de Java, es decir, son solo ints. Protobuf tiene verdaderas enumeraciones de Java.

Para ver más de cerca las diferencias, echa un vistazo a las diferencias de código fuente en este proyecto de código abierto .