Thrift VS Protocol buffers

Thrift VS Protocol buffers

Google recently released its ProtocolBuffers as open source. About a yearago, 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).

 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

Protobuf:只支持序列化、反序列化

Thrift:提供简单的RPC框架，依赖boost，libevent。

   越底层，代码越复杂、灵活性越高、效率越高；越上层，抽象封装的越好、代码越简单、效率越差。Socket和RPC的区别再次说明了这点。

The Thrift C++ runtime library does notcurrently work on windows.This means that you’ll be able to compile Thrift IDLfiles to C++/Java/Python/etc...,but you won’t be able to compile and run thegenerated C++ code under windows.

Overall, I think Thrift wins on features and ProtocolBuffers win on documentation. Implementation-wise, they’re quite similar. Bothuse integer tags to identify fields, so you can add and remove fields withoutbreaking existing code. Protocol Buffers support variable-width encoding ofintegers, which saves a few bytes. (Thrift has an experimental output formatwith variable-width ints.)

The major difference is that Thrift provides a fullclient/server RPC implementation, whereas Protocol Buffers only generate stubsto use in your own RPC system.

　　Protocol Buffers，是Google内部使用一种语言中立、平台中立和可扩展的序列化结构数据的方式，并提供基于Java、C++ 和Python这三种语言的实现，每一种实现都包含了相应语言的编译器以及库文件，并且在很多Google的产品中都有使用。它是一种二进制的格式，所以其速度是使用XML进行数据交换的10倍左右。它主要用于两个方面：其一是普通的RPC(Remote ProcedureCall，远程方法调用)通信，它可用于分布式应用之间或者异构环境下的通信;其二是数据存储方面，因为它自描述，而且压缩很方便，所以可用于对数据进行 持久化，比如存储日志信息等，并可被MapReduce程序的处理。

　　Thrift 是由 Facebook 开源的一个RPC 框架，现在已经成为了著名开源组织Apache的孵化项目之一，它主要的几个特点是：其一是支持非常多的语言，包括在 Web开发中很常用的 PHP，以及C++/Python/Java 等在 Web后端非常常用的语言，甚至还包括近期很流行的 Ruby和Erlang;其二是提供完整的 RPC 框架实现，通过脚本就能生成通讯相关的框架代码，比如搭建一个简易的服务只需要几分钟，这样使得开发者只需要集中精力处理好业务逻辑即可，;其三是拥有被 Facebook、Last.fm等不少大规模互联网应用验证过的性能和可用性。总体而言，它的代码实现是很优秀的，逻辑层次非常清楚，易于定制扩展，同时通过框架生成代码非常方便，也节省很多通讯方面的开发和调试时间，并且 Facebook号称Thrift在速度上和Protocol Buffers相比有一定的优势。