Tokyo Tyrant（ttserver）在大数据量下的不稳定案例

Tokyo Tyrant（ttserver）在大数据量下的不稳定案例
2010-6-22 来源：cnblog 作者：孙立 我要评论分享到： 博客引用 投稿 打印 大 | 中 | 小导读：本文通过测试的方法，介绍了Tokyo Tyrant（ttserver）在大数据量下的不稳定案例。 关键词：Tokyo Cabinet Tokyo Tyrant ttserver NoSQL
正在加载数据...
　　ttserver不稳定案例 　　1. CMS a系统的文章采用了ttserver存储。在数据达到30多G的时候，经常出现写入失败，还出现了几次意外崩溃，无法重启成功，只得从slave恢复数据。 　　2.CMS b系统的图片使用ttserver存储，在数据导到65G的时候出现无法写入的情况，重启后问题依旧，只得从slave重新恢复数据重启。 　　3.BBS系统采用ttserver做缓存，设计上采用如果没有更新，那么缓存永久存在的策略。在数据达到65GB，数据条数在700多万条的时候，出现大量写入失败的情况，系统负载开始上升，日志出现大量do_mc_set: operation failed。当然这里作为缓存比较好处理，删掉，重新建个新的就OK。(注：启动参数data.tch#bnum=10000000#xmsiz=434217728#rcnum=20000) 　　测试中ttserver写入表现不稳定 　　1.#bum=10000000 　　插入940多万数据(一条7.2k)时出现崩溃(测了两次都一样，看起来好像内部出现了死锁，连上后，无法进行任何响应，没有任何操作时，也占了大量CPU)。越到后面插入的qps(每秒响应数)越小。而且波动比较大。 　　#bum=100000000 　　可以顺利插入上千万的数据，但是越到后面qps越小。越到后面插入的qps(每秒响应数)越小。而且波动比较大。 　　2.跟其他的nosql(mongodb,bdb je,cassandra)对比测试，在写入上，ttserver是表现最不稳定的，其他的nosql都非常好。 　　总结和注意 　　1.经过对Tokyo Cabinet的测试，同样跟ttserver一样，所以应该是Tokyo Cabinet 导致的不稳定。在选择btree方式存储时，随着数据量的增加一样不稳定。在优化参数上也做了各种尝试。 　　2.ttserver在性能的表现上非常不俗，特别是内存占用和cpu占用都很低，能同时响应上万的并发。但是你应该注意，他一般在数据导到20G以上就会出现不稳定情况。 　　所以用ttserver来存储单条比较小的数据非常好，存储大文本或者大的二进制文件，由于空间占用上升很快，很快就会变得不稳定。 　　3.注意备份，使用master-slave是个非常好的主意，在ttserver崩溃导致文件损坏或者其他什么原因无法启动时，你可以从slave 拷贝数据文件来进行恢复。 　　4.如果你一定要使用ttserver，建议对数据进行分片(sharding)存储，或者你自己使用一个网络接口，底层使用Tokyo Cabinet 来进行分片存储。 　　5.以上只是个人在使用中遇到的情况，本人正在尝试在存储大文本的ttserver进行替换掉。 　　注：Tokyo Cabinet 是日本人 Mikio Hirabayashi(平林干雄)のページ开发的一款DBM数据库(注：大名鼎鼎的DBM数据库qdbm就是他开发的)，该数据库读写非常快。insert:0.4sec/1000000 recordes(2500000qps)，写入100万数据只需要0.4秒。search:0.33sec/1000000 recordes (3000000 qps)，读取100万数据只需要0.33秒。下图为各种key-value数据库读写数据的性能测试，可以看出Tokyo Cabinet的速度是非常快的。
TechTarget中国原创内容，原文链接：http://www.searchdatabase.com.cn/showcontent_36766.htm