分类： LINUX
2011-04-26 11:40:41
Tokyo Cabinet简介
Tokyo Cabinet是日本人 Mikio Hirabayashi开发的一款 DBM 数据库，该数据库读写非常快，哈希模式写入100万条数据只需0.643秒，读取100万条数据只需0.773秒，是 Berkeley DB 等 DBM 的几倍。
Tokyo Cabinet 是一个DBM的实现。这里的数据库由一系列key-value对的记录构成。key和value都可以是任意长度的字节序列,既可以是二进制也可以是字符串。这里没有数据类型和数据表的概念。
当做为Hash表数据库使用时，每个key必须是不同的,因此无法存储两个key相同的值。提供了以下访问方法:提供key,value参数来存储，按key删除记录，按key来读取记录，另外，遍历key也被支持，虽然顺序是任意的不能被保证。这些方法跟Unix标准的DBM,例如GDBM,NDBM等等是相同的，但是比它们的性能要好得多（因此可以替代它们)
当按B+树来存储时，拥用相同key的记录也能被存储。像hash表一样的读取，存储，删除函数也都有提供。记录按照用户提供的比较函数来存储。可以采用顺序或倒序的游标来读取每一条记录。依照这个原理，向前的字符串匹配搜索和整数区间搜索也实现了。另外，B＋树的事务也是可用的。
As for database of fixed-length array, records are stored with unique natural numbers. It is impossible to store two or more records with a key overlaps. Moreover, the length of each record is limited by the specified length. Provided operations are the same as ones of hash database.
对于定长的数组，记录按自然数来标记存储。不能存储key相同的两条或更多记录。另外，每条记录的长度受到限 制。读取方法和hash表的一样。
Tokyo Cabinet是用C写的，同时提供c,perl,ruby,java的API。Tokyo Cabinet在提供了POSIX和C99的平台上都可用，它以GNU Lesser Public License协议发布。
Tokyo Cabinet是由同一作者开发的 Tokyo Cabinet 数据库网络接口。它拥有Memcached兼容协议，也可以通过HTTP协议进行数据交换。
Tokyo Tyrant 加上 Tokyo Cabinet，构成了一款支持高并发的分布式持久存储系统，对任何原有Memcached客户端来讲，可以将Tokyo Tyrant看成是一个Memcached，但是，它的数据是可以持久存储的。
上面是我从网上摘录的部分介绍~~
用Tokyo Tyrant 加上 Tokyo Cabinet,他们支持双向的M/M同步,也支持单向的M/S同步,可以为网站提供非常可靠的持久化的分布式数据高速Cache,没有了Memcached对内存大小的依赖,而且速度还是飞快.
计算一下,按100w每秒的速度,那么每天可以支持最高100w*1440*60 = 8640000w的查询总量.这样的速度对于任何一个网站都是足够用的了.
近期将对Tokyo Tyrant + Tokyo Cabinet的使用做一些测试,结果出来再与大家分享!!
Tokyo Cabinet介绍
Tokyo Cabinet是由一个名叫平林幹雄的日本人开发的一个管理数据库程序库，作者开发了一系列的开源程序。包括：
Tokyo Cabinet
tokyotyrant
QDBM（Quick Database Manager），
Hyper Estraier（a full-text search system for communities），
Estraier（a personal full-text search system）
Diqt：Multilingual Dictionary Searcher等。
现工作于日本的第一大社交网站mixi。
Tokyo Cabinet是一个DBM数据库，在整个数据库中它既没有数据表的概念也没有数据类型的概念，它由一系列的key-value对的记录构成，key和vlaue既可以是二进制数据也可以为字符数据，它们的长度可以是任意长度的字节序列，所有的记录都保存在文件中。所有记录由hash表，b+树或定长的数组组成。
Tokyo Cabinet基于GNU Lesser General Public License协议发布，采用C语言开发，它可以运行在任何支持C99和POSIX平台上使用。
相比一般的DBM数据库有以下几个特点：空间小，效率高，性能高，可靠性高，多种开发语言的支持（现已提供C，Perl，Ruby，Java，Lua的API），支持64位操作系统。
它的官方首页是:
最新版本：tokyocabinet-1.4.14
稍后我将推出他在mixi开发者blog上发表一系列有关于tokyocabinet的文档
PHP操作tokyo Cabinet
Posted: – 上午3:03
上篇我介绍了tokyo Cabinet，这篇我介绍通过php操作tokyo cabinet。需要的工具有php扩展模块Net_Tokyo_Tyrant，Tokyo Tyrant。
首先安装Tokyo Cabinet，安装方法
curl -O
./configure
make
make install
安装tokyotyrant
curl -O
./configure
make
make install
为php添加Net_Tokyo_Tyrant模块
/usr/local/php/bin/pear channel-discover openpear.org
/usr/local/php/bin/pear install openpear/Net_TokyoTyrant-beta
现为beta版，当有正式版请使用
/usr/local/php/bin/pear install openpear/Net_TokyoTyrant
启动服务
/usr/local/sbin/ttservctl start
说明：启动后的监听的端口为1978
编写php文件
include_once 'Net/TokyoTyrant.php';
$tt = new Net_TokyoTyrant();
$tt->connect( 'localhost', 1978 );
$tt->put('test', 'PHP connet to Tokyo cabinet');
echo $tt->get('test');
$tt->close();
?>
执行刚刚的php文件，你将看到如下的文字
PHP connet to Tokyo cabinet
以上就完成第一个php对Tokyo cabinet的操作
当在memcache中保存数据时，重启memcache服务，所有的数据全部丢失
当在tokyo cabinet中保存数据时，服务器重启数据不丢失。
下面通过一个例子证明这点
/usr/local/sbin/ttservctl restart
编写php文件
include_once 'Net/TokyoTyrant.php';
$tt = new Net_TokyoTyrant();
$tt->connect( 'localhost', 1978 );
//$tt->put('test', 'PHP connet to Tokyo cabinet');
echo $tt->get('test');
$tt->close();
?>
执行php脚本，得到的结果还是
PHP connet to Tokyo cabinet
说明它的数据全部保存在磁盘上而不是内存中。
下期将推出，比较memcache与tokyo cabinet的执行效率
php操作Tokyo Cabinet与操作memcache效率比较
先说我的服务器环境，1G内存，双核Xeon 2.00的CPU，服务器采用rpm方式部署apahce，php
Tokyo Cabinet的安装方法及PHP操作Tokyo Cabinet方法请见上篇
在测试之前，先安装一个php模块--Benchmark，安装方法如下
/usr/local/php/bin/pear install Benchmark
下面写一个脚本分别对tokyo cabinet进行一万次插入，一万次查询，一万次更新
一万次删除操作
脚本的内容如下
include_once( 'Benchmark/Timer.php' );
$timer = new Benchmark_Timer();
include_once( 'Net/TokyoTyrant.php' );
$tt = new Net_TokyoTyrant();
$tt->connect( 'localhost', 1978 );
$timer->start();
for ( $i = 0; $i < 10000; $i++) $tt->put( 'test_'.$i, $i );
$timer->setMarker('TOKYO CABINET - INSERT 10,000 RECOREDS');
for ( $i = 0; $i < 10000; $i++) $tt->get( 'test_'.$i );
$timer->setMarker('TOKYO CABINET - SELECT 10,000 RECOREDS');
for ( $i = 0; $i < 10000; $i++) $tt->put( 'test_'.$i, $i );
$timer->setMarker('TOKYO CABINET - UPDATE 10,000 RECOREDS');
for ( $i = 0; $i < 10000; $i++) $tt->out( 'test_'.$i );
$timer->setMarker('TOKYO CABINET - DELETE 10,000 RECOREDS');
$timer->stop();
$timer->display();
$tt->close();
?>
执行脚本得到的结果如下图
下面对memcache进行测试，为测试方便在同一台机器上执行一下脚步
memcached -d -m 256 -l 127.0.0.1 -p 11211 -u root
以root用户对memcahe分配256M的内存，分配的端口号为11211
下面再写一个脚本分别对memcahe进行一万次插入，一万次查询，一万次更新
一万次删除操作，脚本内容如下：
include_once( 'Benchmark/Timer.php' );
$timer = new Benchmark_Timer();
$memcache = new Memcache;
$memcache->connect('localhost', 11211);
$timer->start();
for ( $i = 0; $i <10000; $i++ ) $memcache->set( 'test_'.$i, $i );
$timer->setMarker('MEMCACHE - INSERT 10,000 RECOREDS');
for ( $i = 0; $i <10000; $i++ ) $memcache->get( 'test_'.$i );
$timer->setMarker('MEMCACHE - SELECT 10,000 RECOREDS');
for ( $i = 0; $i <10000; $i++ ) $memcache->replace( 'test_'.$i, $i );
$timer->setMarker('MEMCACHE - UPDATE 10,000 RECOREDS');
for ( $i = 0; $i <10000; $i++ ) $memcache->delete( 'test_'.$i );
$timer->setMarker('MEMCACHE - DELETE 10,000 RECOREDS');
$timer->stop();
$timer->display();
$memcache->close();
?>
执行的结果如下:
从上面测试的结果来看，tokyo cabinet的速度非常快，比memcahe稍差。
在执行1万次操作所花费的时间在1.2s左右，而memcahe所花的时间比tokyo cabinet快了0.2秒，但是memcache down掉后数据全部丢失，而tokyo cabinet即使重启了，db文件不坏掉，数据就不会丢失。
Tokyo Tyrant备份和还原
Posted: 2009年4月23日 星期四 – 下午10:52
人为的误操作，机器的不可靠性导致数据的丢失，这是会经常发生在我们的身边。为减少数据的丢失，定期的备份可以解决部分数据丢失的可能。
Tokyo Tyrant（以下简称tt）提供备份还原机制实现高可靠性的功能。
只需要简单简单的把数据库文件进行拷贝，就能完成备份功能，具体实现方法见下图
下面通过简单的实例进行测试：
在同一台机器上启动2个终端，在终端A中启动服务
ttserver /tmp/casket.tch
在终端B中插入测试数据
tcrmgr put localhost TTTest TestByZLJ
在终端B中查询刚刚插入的测试数据
tcrmgr get localhost TTTest
在终端B中备份数据库文件
tcrmgr copy localhost /tmp/backup.tch
模拟服务down掉，在终端A中按下ctrl-c键
模拟数据库文件丢失，在终端A中删除数据库文件
rm /tmp/casket.tch
还原数据库文件
cp /tmp/backup.tch /tmp/casket.tch
在终端A中重新启动服务
ttserver /tmp/casket.tch
在终端B中检索数据
tcrmgr get localhost TTTest
最后我们得到的结果还是：TestByZLJ，说明成功的还原了数据
以上只是通过简单的文件复制完成了数据备份与还原，这种方法有它的缺点就是，在上面的文件备份过程中更新的数据有可能就得不到还原。下面将通过另外一个功能解决以上的缺点
在mysql 可以通过binary log的方式恢复数据，oracle也有redo log的方式恢复数据，
tt同样也有通过更新log的方式恢复数据，也就是说，所有对db的更新操作在log中都有操作记录，通过tt自有的log还原数据机制能把数据还原回来。
下面通过简单的实例进行测试：
在同一台机器上启动2个终端，建立一个目录用来保持log
mkdir /tmp/ulog
在终端A中启动服务
ttserver -ulog /tmp/ulog /tmp/casket.tch
在终端B中插入测试数据
tcrmgr put localhost TTTest TestByZLJ
在终端B中查询刚刚插入的测试数据
tcrmgr get localhost TTTest
模拟服务down掉，在终端A中按下ctrl-c键
模拟数据库文件丢失，在终端A中删除数据库文件
rm /tmp/casket.tch
备份更新log文件
mv /tmp/ulog /tmp/ulog-back
在终端A中重新启动服务
ttserver /tmp/casket.tch
通过更新log还原数据
tcrmgr restore localhost /tmp/ulog-back
在终端B中检索数据
tcrmgr get localhost TTTest
最后我们得到的结果还是：TestByZLJ，说明成功的还原了数据。
它有个缺点：每次操作都有log记录，慢慢的文件就会变得越来越大，很容易磁盘用尽，可以通过备份数据库文件和保存部分更新log文件，两者一起解决这个问题，具体做法：定期备份数据文件和更新log，对很老的备份更新log进行删除，当需要还原数据时，先通过还原备份数据库文件，由于在还原数据时写入的数据会写更新log文件，还原后再通过更新log文件
进行还原数据库时写入的数据，就可以完全的还原数据，具体做法看下图
搭建Tokyo Tyrant replication
Posted: 2009年4月24日 星期五 – 上午2:37
篇介绍了Tokyo Tyrant（以下简称tt）的备份和还原，保证了数据完整性,由于它不是实时备份，因而不能保证数据的完整性，当磁盘坏掉了,而这时数据没有备份，因而导致数据的不完整性。
为解决上述问题，大家知道mysql中有个replication机制可以解决数据的完整性,同样tt也有replication机制保证数据的完整性，具体实现方法，数据库服务器把本机的更新log,分批次的实时传输到别的数据库服务器，传输更新log的服务器就是我们常说的主服务器，接收更新log的服务器就是我们常说的辅服务器。replication的好处就是，管理者配置好服务器,
主辅DB服务器自动保持数据的一致性。当主服务器down后，可以把辅服务器变为主服务器
提供服务，而保证不间断服务，同时也使管理员有时间重新为辅服务器添加一个新辅服务器，重新搭建replication。
具体实现方法见下图
通过上图看到，平时辅服务器几乎不接受请求，因而造成资源浪费，特别在大压力的情况下
主服务器的负荷很重，而辅服务器几乎没有负荷。由于主服务器的数据几乎是同步的，可以采用读写分离的方式，分散服务器的压力。这也是许多高负荷系统对DB采取的一种方式。
具体实现如下图
下面通过一个实例来介绍通过tt实现replication
在同一台机器上启动3个终端
在终端A中创建主DB更新log文件夹
mkdir /tmp/ulog-master
在终端A中启动服务
ttserver -port 1978 -ulog /tmp/ulog-master /tmp/casket-master.tch
在终端A中创建辅DB更新log文件夹
mkdir /tmp/ulog-master
在终端B中启动辅DB
ttserver -port 1979 -ulog /tmp/ulog-slave -mhost localhost -mport 1978 -rts /tmp/slave.rts /tmp/casket-slave.tch
在终端C中对主DB插入测试数据
tcrmgr put -port 1978 localhost TTTest TestByZLJ
在终端C中查询主DB
tcrmgr get -port 1978 localhost TTTest
在终端C中查询辅DB
tcrmgr get -port 1979 localhost TTTest
查询主DB跟查询辅DB得到同样的结果‘TTTestByZLJ’，虽然只是对主db进行了数据插入操作
但是查询辅db得到了同样的结果，这样的话就不用担心服务器磁盘坏了没有备份了。
但是replication也不是万能的，它也有它的缺点，主DB与辅DB的之间的传输有数10微秒到数100微秒的延迟，在大并发下，延迟期间，主DB down掉了，有可能在延迟时产生的数据就丢失了。同时主DB down掉以后，它不能自动的切换到辅DB，而需要人工的参与，不能实现自动化运维。
搭建Tokyo Tyrant的故障转移
Posted: 2009年4月27日 星期一 – 上午5:41
以前写了一篇关于tokyo tyrant的replication实现了高可靠性，文中最后说了它的几个缺点，本文中将通过tokyo tyrant更高级的特性，故障转移机制，解决这些问题。本文介绍tokyo tyrant的的故障转移机制，有点像lvs的主从机制。当主DB down掉的时候，自动的把备份DB转为主db，提供服务，而不需要人工的干预。同时采用tokyo tyrant的replication机制，保证数据完整性的同时，还具有遇到故障自动切换主从服务器，实现高可靠性。
下面是一个tokyo tyrant的故障转移的实例，现看实现原理图
在同一台机器上打开3个窗口。
在终端A中创建主DB更新log文件夹
mkdir /tmp/ulog-a
在终端A中启动服务
ttserver -port 1978 -ulog /tmp/ulog-a -sid 1 -mhost localhost -mport 1979 -rts /tmp/a.rts /tmp/casket-a.tch
在终端B中创建辅DB更新log文件夹
mkdir /tmp/ulog-b
在终端B中启动辅DB
ttserver -port 1979 -ulog /tmp/ulog-b -sid 2 -mhost localhost -mport 1978 -rts /tmp/b.rts /tmp/casket-b.tch
在终端C中对主DB插入测试数据
tcrmgr put -port 1978 localhost TTTest TestByZLJ
在终端C中查询主DB
tcrmgr get -port 1978 localhost TTTest
在终端C中查询辅DB
tcrmgr get -port 1979 localhost TTTest
模拟主DB down掉，在终端A中按下Ctrl+C
在终端C中对辅db进行数据插入操作
tcrmgr put -port 1979 localhost test TTTest
在终端C中对辅DB进行数据检索操作
tcrmgr get -port 1979 localhost test
在终端A中重新启动主DB
ttserver -port 1978 -ulog /tmp/ulog-a -sid 1 -mhost localhost -mport 1979 -rts /tmp/a.rts /tmp/casket-a.tch
在终端C中对主DB进行数据检索
tcrmgr get -port 1978 localhost test
最后查询得到的结果还是TTTest，在对辅DB进行插入操作的时候主DB已经down掉了，而当主DB重新起来后，对主DB再次进行查询得到了我们想要的结果。也就是说主DB重新起来后自动的从辅DB进行数据同步操作，保证数据的完整性，同时也为SA有时间去处理这类故障。
