简评 Taobao Tair: 四不像

版权声明: 允许非商业性转载，但转载时必须标明原作者 fcicq、原始链接 http://www.fcicq.net/wp/?p=914 及本声明。

Taobao Tair 是一个分布式 key-value store. 于 2010.6.29 正式开源.

Tair 支持内存 hash (MDB) 和文件存储引擎 (FDB).
(如果你熟悉 Tokyo Cabinet 的话, 对应 TCMDB 和 TCHDB)
存储引擎可以扩展 (但这个 API 个人觉得很难看).

Memcached 和 Redis 的一些特性也被搬到了这里.
比如原子计数器支持, Item 支持, 版本号支持.

可是压根它就不打算支持 Memcached 协议 (也许以后会有吧, 写个 Proxy?).

—

Tair 没有使用 Consistent Hashing (这个应该没看错).
但使用了 Dynamo 论文 Page 12 中的 Strategy 3 以保证节点分布与数据完整性.
(但就这个也不像! 因为没用 Consistent Hashing, 所以不符合论文, 见下 GFS 相关讨论)
并提供了两种节点分布方式: 负载平衡优先, 数据安全优先.
这种方式虽然偶不太喜欢, 不过倒是个可以接受的方案.
纯 Consistent Hashing + Buckets + 多 Hash Ring (每个 Ring 不能在同一网段以提高可用性) 也是一种做法, 不过缺点是复制份数不能随负载而调整了.

插嘴: Riak 和 Voldemort 应该是暂时最像 Dynamo 的实现了吧…

如果非要做个比较的话, Google File System (GFS) 的 Block 分配也是这样的, 有 Master 负责 Block 到机器的对应查询.
这个 Buckets 的数量是一定的 (这是没办法). 但 Buckets 太多, configserver 就要耗费更多的时间去同步对应表.
仔细考虑一下, 增加减少节点时重新平衡的行为, 和 GFS 确实太相似了.
区别只是 GFS Block 的数量是可变的, 这个是不可变的. 反着看的话, Blocksize 是不固定的.

整体上说, 如果数据完整性对你很重要, Tair 是不错的选择. (这话没说完就这么放着了… )

代码: 客户端直接取模就得到服务器了. (tair_client_api_impl.cpp)
if (my_server_list.size() > 0U) {
hash %= bucket_count;
for(uint32_t i=0;i < copy_count && i < my_server_list.size(); ++ i){
uint64_t server_id = my_server_list[hash] + i * bucket_count;
if(server_id != 0){
server.push_back(server_id);
}
}
}


—

关于 Tair 自带的 FDB, 自称树形存储引擎 (这个树实际上和排序没有太大关系, 仅用于索引查询).

如果没看错的话是这样的:
用 h(x) 计算出 bucket number (这属于前面的分布式部分), 找到 bucket 对应的(数据和索引)文件完成写入, 索引使用的是二叉树.

索引的定义:
typedef struct _item_index {
uint32_t left;
uint32_t right;
uint64_t size:24;
uint64_t offset:40;
uint64_t hashcode;
} item_index;

个人认为索引方面有缺陷. 应该引入 Cache-Oblivious 的树形数据结构 (二叉树需要的内存访问次数太多了), 即便它能够缓存在内存中.

FDB 具体实现很像 Facebook 的图片存储系统. 适合 Object 修改次数极少的情况.
使用了空间池 (free_blocks_manager) 以提高空间利用率.

关于 MDB 的实现偶没有评估的能力.

—

希望以上描述能够帮助大家更快的评估 Tair. 如有疑问请丢邮件过来.

ps:
那 Dynamo 的论文写 Consistent Hashing 干嘛?

ps2:
写网络应用程序不支持 IPv6 怎么行?

ps3:
四不像, 这个概括还是比较准确的. 你说它不像什么?

友情提示: 请注意文章的时效性与准确性, 作者不对文章的有效性负责.