238
¿Cuáles son los mayores pros y contras de Apache Thrift frente a Google's Protocol Buffers?¿Las mayores diferencias de Thrift versus Protocol Buffers?
A
Respuesta
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.
+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
Settipo - 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).
+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.
+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.
+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.
+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.
+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.
+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
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.
+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.
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.
+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.
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:
Cuestiones relacionadas
- 1. Comparación de rendimiento de Thrift, Protocol Buffers, JSON, EJB, otro?
- 2. Delphi Protocol Buffers?
- 3. ¿Alguna experiencia con Protocol Buffers?
- 4. Protocol Buffers y modelos de datos internos
- 5. Protocol Buffers de Java RPC Pila
- 6. Usando Google 'Protocol Buffers' en Arduino
- 7. ¿Para qué se utilizan las memorias intermedias Apache Thrift y Google Protocol?
- 8. ¿Cuáles son las mayores diferencias entre fopen y curl?
- 9. ¿Existe una implementación de la calidad de producción de los Buffers de Google Protocol en .NET
- 10. Integrar archivos de Google Protocol Buffers .proto a Visual C++ 2010
- 11. Apache Thrift Java-Javascript comunicación
- 12. Protocol Buffers: ¿Debo utilizar Int64 o fixed64 para representar un valor .NET DateTime?
- 13. Scala Case Classes vs. Protocol Buffers with Akka en la red
- 14. ¿Cómo codificaría un Map <String, Object> utilizando Protocol Buffers?
- 15. Cassandra Thrift Erlang insertar
- 16. Buffers de protocolo de Google comparar
- 17. Android WebView Protocol Handler
- 18. Boost.Asio con buffers de protocolo de Google
- 19. mayores a las de intercambio de comparación y
- 20. Thrift + Tornado + Async
- 21. Cómo desinstalar Thrift
- 22. MvcBuildViews Versus Razor Generator
- 23. Uso de Thrift en iOS
- 24. Informática para personas mayores
- 25. python multiprocessing pickle protocol
- 26. .NET Messaging & STOMP Protocol
- 27. gson vs protocol buffer
- 28. Logitech Unifying Receiver Protocol?
- 29. Apio versus djcelery
- 30. Buffers de protocolo frente a JSON o BSON
Como nota al margen, Marc Gravell mantiene una biblioteca para trabajar con Googles protobuf llama protobuf.net y está en http://code.google. com/p/protobuf-net/ – RCIX
Esta pregunta y algunas de las siguientes respuestas tienen aproximadamente 6 años de antigüedad. Probablemente muchas cosas han cambiado desde entonces. –