Tokyo Cabinet 主辅

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 Tyrant 是由同一作者开发的 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位操作系统。

它的官方首页是:http://tokyocabinet.sourceforge.net/index.html

最新版本: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 http://tokyocabinet.sourceforge.net/tokyocabinet-1.4.16.tar.gz

./configure

make

make install

安装tokyotyrant

curl -O http://tokyocabinet.sourceforge.net/tyrantpkg/tokyotyrant-1.1.23.tar.gz

./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文件

<?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文件

<?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进行一万次插入,一万次查询,一万次更新

一万次删除操作

脚本的内容如下

<?php

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进行一万次插入,一万次查询,一万次更新

一万次删除操作,脚本内容如下:

<?php

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有时间去处理这类故障。

你可能感兴趣的:(tc,tokyo,Cabinet)