Thrift 与 protocol buffers 的比较

hrift vs Protocol Bufffers 

-----------------

 

 

Google recently released its Protocol Buffers as open source. About a year ago, Facebook released a similar product called Thrift . I’ve been comparing them; here’s what I’ve found:

The Comparison

	Thrift	Protobuf
Language Bindings	Java, C++, Python, C#, Cocoa, Erlang, Haskell, OCaml, Perl, PHP, Ruby, Smalltalk	Java, C++, Python
Primitive Types	bool, byte, 16/32/64-bit integers, double, string, byte sequence, map<t1,t2>, list<t>, set<t>	bool, 32/64-bit integers, float, double, string, byte sequence, “repeated” properties act like lists
Enumerations	Yes	Yes
Constants	Yes	No
Composite Type	Struct	Message
Exception Handling	Yes	No
Documentation	Lacking	Good
License	Apache	BSD-style
Compiler	C++	C++
RPC Interfaces	Yes	Yes
RPC Implementation	Yes	No
Composite Type Extensions	No	Yes
Data Versioning	Yes	Yes
Pros	- More languages supported out of the box - Richer data structures than Protobuf (e.g.: Map and Set) - Includes RPC implementation for services	- Slightly faster than Thrift when using “optimize_for = SPEED” - Serialized objects slightly smaller than Thrift due to more aggressive data compression - Better documentation - API a bit cleaner than Thrift
Cons	- Good examples are hard to find  - Missing/incomplete documentation	- .proto can define services, but no RPC implementation is defined (although stubs are generated for you).

 

Much of this table was originally compiled by Stuart Sierra but has been edited to include additional information relevant to my own requirements.

Thrift and Protocol Buffers are both great choices and there seems like no clear winner between them. Since they seem to have more in common than they do in conflict, it really comes down to real-world application-specific needs.

I’d choose Protocol Buffers over Thrift if:

• You’re only using Java, C++ or Python. Experimental support for other languages is being developed by third parties but are generally not considered ready for production use
• You already have an RPC implementation
• On-the-wire data size is crucial
• The lack of any real documentation is scary to you

I’d choose Thrift over Protocol Buffers if:

• Your language requirements are anything but Java, C++ or Python. See above.
• You need additional data structures like Map and Set
• You want a full client/server RPC implementation built-in
• You’re a Rock Star programmer that doesn’t need documentation or examples