Thrift vs. Protocol Buffers 06月23日
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:
| Thrift | Protocol Buffers | |
|---|---|---|
| Backers | Facebook, Apache (accepted for incubation) | |
| Bindings | C++, Java, Python, PHP, XSD, Ruby, C#, Perl, Objective C, Erlang, Smalltalk, OCaml, and Haskell | C++, Java, Python (Perl, Ruby, and C# under discussion) |
| Output Formats | Binary, JSON | Binary |
| Primitive Types | bool byte 16/32/64-bit integersdouble string byte sequence map<t1,t2> list<t> set<t> |
bool32/64-bit integers float double string byte sequence “repeated” properties act like lists |
| Enumerations | Yes | Yes |
| Constants | Yes | No |
| Composite Type | struct | message |
| Exception Type | Yes | No |
| Documentation | So-so | Good |
| License | Apache | BSD-style |
| Compiler Language | C++ | C++ |
| RPC Interfaces | Yes | Yes |
| RPC Implementation | Yes | No |
| Composite Type Extensions | No | Yes |
Overall, I think Thrift wins on features and Protocol Buffers win on documentation. Implementation-wise, they’re quite similar. Both use integer tags to identify fields, so you can add and remove fields without breaking existing code. Protocol Buffers support variable-width encoding of integers, which saves a few bytes. (Thrift has an experimental output format with variable-width ints.)
The major difference is that Thrift provides a full client/server RPC implementation, whereas Protocol Buffers only generate stubs to use in your own RPC system.
Update July 12, 2008: I haven’t tested for speed, but from a cursory examination it seems that, at the binary level, Thrift and Protocol Buffers are very similar. I think Thrift will develop a more coherent community now that it’s under Apache incubation. It just moved to a new web site and mailing list, and the issue trackeris active.
Kyoto Cabinet 基本规格书【转】 06月20日
如果你知道 Tokyo Cabinet ，那么就应该知道 Kyoto Cabinet，因为他们都是同一个作者（平林幹雄）开发出来的 Key-Value 数据库。
Kyoto Cabinet：a straightforward implementation of DBM，主页：http://fallabs.com/kyotocabinet/ ，演示文稿：http://www.slideshare.net/estraier/kyotoproducts-5886452 。
Tokyo Cabinet：a modern implementation of DBM，主页： http://fallabs.com/tokyocabinet/
以下Tokyo Cabinet简称为TC， Kyoto Cabinet简称为KC，本文主要对KC做介绍。
KC是TC的后继者或兄弟项目，因为KC在各方面都超过了，所以作者在TC的首页上的开头向所有人推荐使用KC（我也是这个推荐才开始关注KC的）。TC为C实现，为了更好的可维护性，KC采用C++实现。
以下内容的英文原文来自：http://fallabs.com/kyotocabinet/spex.html (更多…)
浅谈Facebook的服务器架构(组图)【转】 06月13日
导读：毫无疑问，作为全球最领先的社交网络，Facebook的高性能集群系统承担了海量数据的处理，它的服务器架构 [...]
- 分类：互联网技术
- 标签： facebook, facebook服务器
- 评论：3 条
- 浏览：3912
- 阅读全文