专访基于Erlang的开源NoSQL数据库Tiger创始人姚新明

编者按:感谢ZoomQuiet淘宝褚霸为本次采访提供问题。

\

姚新明,Erlang程序员,目前就职于安防技术中国有限公司杭州研究院云计算部,从事分布式文件系统的研发,早期从事企业信息系统开发、SaaS系统架构,写过javascript,干过java,会点perl、c、emacs lisp,喜欢linux、emacs,爱好开源技术,目前主要关注NoSQL、分布式技术、分布式文件系统。

\

InfoQ: 请对Tiger项目做个介绍。

\

姚新明:Tiger是一个Erlang开发的NoSQL数据库,基于Erlang、zab协议以及leveldb、Redis引擎实现,目的是提供高性能,高可靠性,高可用性的数据服务。单点问题一直是困扰架构师的主要问题之一,自己以前做架构的时候也碰到比较多,一直没有找到好的解决方案,接触Erlang、zab协议,leveldb后,我意识到我以前所面临的一些问题是可以解决的,所以就有了Tiger。

\

InfoQ: Tiger在数据的安全性方面是如何做到的?

\

姚新明:Tiger采用2f+1的集群模式,数据相当于多副本存储,所以数据丢失的概率比较小。

\

InfoQ: Tiger在灾难恢复方面有哪些特性?

\

姚新明: Tiger采用2f+1的集群模式,是基于consensus设计理念的集群,因此在f台机器出故障的时候不会影响系统的可用性,新增加的机器可以在线加入集群,历史数据会先从本地恢复,再从leader同步剩余的数据,所以只要不是所有机器都crash,那么系统是可以恢复的。

\

InfoQ:能否介绍下Tiger的性能和可以承载的数据集大小?

\

姚新明:Tiger的单机读写可以达到10k tps的能力,集群读写能力为n:1,这主要得益于Erlang强大的网络能力,以及leveldb存储引擎。数据集如果是leveldb引擎,主要瓶颈在磁盘容量,如果是Redis引擎,瓶颈主要是在内存,另外数据量太大系统重启恢复的时间会相对长点,zab引擎的log是使用leveldb,从leveldb的测试报告,大概是100M左右的顺序读能力,所以如果是6G的数据,估计回放数据要2分钟左右。

\

InfoQ: 为什么选择 Erlang 作为开发平台?

\

姚新明: Erlang在网络编程方面有很大的优势,另外分布式协议paxos和zab都是基于消息的协议,Erlang的actor模型很适合处理这种协议,用Erlang实现的zab引擎只有2k代码左右,比zookeeper的代码量小很多。

\

InfoQ: 为什么不在 menisa 上进行改进?

\

姚新明:menisa是一个不错的数据库,功能比较多,但是也有比较明显的缺点,首先是对网络分区没有很好的处理,另外单个表的限制也是比较大的问题,Erlang做数据库引擎其实不是一个很好的选择,个人认为mmeisa更适合2台机器做HA的模式,不是特别适合分布式大数据。

\

InfoQ: 作为少数派的基于 Erl 的NoSQL 作品, 和 CouchDB/CouchBase ,Tiger相比有什么优势?

\

姚新明: CouchDb是文档数据库,我以前也简单用过,从性能和可靠性以及可用性方面Tiger应该是有更大的优势。CouchBase其实和Tiger的做法类似,Erlang做通讯层,c做持久层,目前Tiger功能相对少些,因为zab协议的支持,可靠性和可用性应该更好,性能方面没有对比过。

\

InfoQ:目前,您推荐在什么场景中使用Tiger?

\

姚新明: 比较适合N:1读写的场景,系统对可靠性和可用性要求比较高都可以考虑Tiger,比如session服务器,认证中心都是可以的,当然作为缓存也可以, 应该说使用memcached和Redis的场景都能使用,当然Redis接口目前还不是很全。部署是建议3台或者5台集群方式。如果是采用Erlang开发server,也可以嵌入Tiger中使用的zab_engine来解决多server的数据一致性问题。

\

InfoQ: Tiger对中文信息是否有方便的支持?

\

姚新明: 下一步将完善文档,因为前端采用的是大家都比较熟悉的memcached协议和Redis协议,所以从使用的角度应该问题不大。如果只是验证,在项目主页上有说明,基本上是傻瓜型的,生产环境安装部署需要修改几个配置,这个会增加到文档中去。

\

InfoQ: 对于Tiger的未来有什么计划?

\

姚新明:

\
  1. 根据用户反馈,完善已有的api包括memcached和Redis ,推出稳定的版本\
  2. 完善性能测试,性能调优\
  3. zab引擎的完善\
  4. 增加数据备份功能\

从长远的角度是考虑做一个类似riak的系统,但不是p2p模式,而是采用master slave模式,数据一致性通过zab引擎来实现,那么系统将会是一个大型的高可靠性分布式K/V系统。

\

InfoQ:目前有种说法是最低调的Riak可能是最终胜出者。Tiger 的目标是Riak,那为什么 Riak 目前无法解决手上的问题? 或者説 Riak 相比 Tiger 的应用场景有什么不同?

\

姚新明: Riak是p2p模型的,对于数据是基于CAP的最终一致性,相当与弱一致性,我还是比较喜欢master slave模式,简单可控性强。另外Riak中所有node都是连接的,保活消息广播量比较大,估计能支持的节点数会有限。

\

Riak我是比较喜欢的,Basho公司应该是在c和Erlang方面都很有实力的公司,Tiger的项目结构是参考Riak做的,打包脚本是直接从Riak拿来的,省了不少工作。eleveldb也是从Basho公司拿来的。

\

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
erlang开发的开源高可靠性nosql数据库tiger介绍可靠性:    写:对于n=2f 1 机器集群,在f台机器宕机的情况下可写    读:只要是没有宕机的机器都是可读的一致性:    强一致性扩展性:    读的能力可以线性扩展 功能:   目前实现了key/value的get set 和delete功能:   基于memcached协议和leveldb的持久数据库   基于redis协议和redis存储引擎的内存数据库,宕机后数据重放到内存 性能:     单机跑3个实例:     双核,Pentium(R) Dual-Core  CPU      E6600  @ 3.06GHz     centos 5.6 erlang R15b 2G 内存    基于memcached协议的接口:     set接口:     91.49% <= 12 milliseconds,5387.93 requests per second     get 接口:     100.00% <= 13 milliseconds 18177.54 requests per second      基于redis协议的接口:     set接口:     100.00% <= 60 milliseconds 3954.13 requests per second      get 接口:       13477.09 requests per second      测试程序使用:mc-benchmark,redis-benchmark,因为3个实例在一个机器上,所以写的性能影响比较大,    部署的时候建议分开到不同物理机部署。 主要技术:  erlang:用于socket和通讯层   Zab(Zookeeper  Atomic Broadcast):实现消息的原子广播  存储引擎:leveldb,redis存储引擎  架构实现:zab_engine介绍:将zab协议实现为erlang的api,如果使用erlang开发项目,可以嵌入zab_engine,实现多master的架构变得非常简单  引擎实现功能:1:2阶段提交2:恢复   a.follow恢复   b.leader恢复   c.在线加入和恢复架构: 使用说明:1.实现gen_zab_server 回调函数2.对于须同步数据,实现handle_commit3.对于只读数据,实现handle_call 标签:tiger  NoSQL数据库
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值