K/V数据库-Tokyo Cabinet
2012-12-07 16:54:10 
阿炯
Tokyo Cabinet 是一个DBM的实现，这里的数据库由一系列key-value对的记录构成。key和value都可以是任意长度的字节序列，既可以是二进制也可以是字符串，这里没有数据类型和数据表的概念。 
当做为Hash表数据库使用时，每个key必须是不同的,因此无法存储两个key相同的值。提供了以下访问方法:提供key,value参数来存储，按 key删除记录，按key来读取记录，另外，遍历key也被支持，虽然顺序是任意的不能被保证。这些方法跟Unix标准的DBM，例如GDBM、NDBM 等等是相同的，但是比它们的性能要好得多因此可以替代它们) 。Tokyo Cabinet是一个管理数据库的方法库，而数据库就是一个包含了记录的简单的数据文件，其中每条记录都是一个Key/Value对。每一个Key和Value都由变长的顺序字节组成，二进制数和字符串都可以用来作为Key和Value。在Tokyo Cabinet中既没有数据表的概念也没有任何数据类型，记录直接被组织到哈希表、B+树或者定长数组中。
对于哈希表数据库，数据库中的每一个Key都必须是独一无二的，所以在Key相同的情况下不可以存储两个或者更多个记录。在访问记录时，数据库提供了如下方法：以Key/Value的形式存储一条记录，通过Key删除一条记录，通过Key检索一条记录以及遍历所有给定Key的记录。对于B+树数据库，Key值相同的记录可以被存储。同哈希数据库一样，B+树同样提供了存储、删除和检索等方法。记录在存储的时候可以根据用户指定的比较函数进行排序，所以使用游标就可以按照递增或者递减的顺序访问每一条记录。基于这种机制，针对字符串的向前匹配查询和针对整数的范围查询均可以实现。对于定长数组数据库，记录在存储的时候都附带一个唯一的自然数，同一个Key值无法存储两个或者更多个记录。此外，每个记录的长度都被限定在指定的长度范围内，而对记录的访问方法也和哈希表数据库一致。除了以上三种数据库之外，Tokyo Cabinet还提供了另外一种哈希表数据库的变种——表数据库，在这种数据库中，每条记录由主键Primary Key来标识并且包含了一组命名的列，这样即使没有数据模式的概念也可以通过任意列的索引来处理复杂的条件查询。它们具有如下一些特点：
一、DBM的衍生物
作为GDBM和QDBM的后继者，Tokyo Cabinet真正做到了青出于蓝而胜于蓝。
1.它提高了空间效率：更小的数据库文件；
2.它提高了时间效率：更快的处理速度；
3.它提高了并发度：在多线程环境下更高的性能；
4.它提高了易用性：简单化的API；
5.它提高了健壮性：数据文件即使在发生灾难的情况下也不会崩溃；
6.支持64位架构：可以使用更大的内存空间和更大的数据库文件。
Tokyo Cabinet消除了传统DBM的三大局限：一个进程只能处理一个数据库，Key和Value的大小有限，数据库文件是稀疏的。此外它还消除了QDBM的三大局限：数据库文件大小限定在2GB，字节排序不一样的环境无法共享一个数据库文件，在同一时间只有一个线程可以查询数据库。在如此多的方面进行改进后，Tokyo Cabinet可以运行的非常快，对于哈希数据库存储一百万条记录只需0.7秒，而对于B+树数据库来说也只需要1.6秒。同时Tokyo Cabinet数据库的规模也很小，对于一条记录来说哈希数据库的额外空间代价为16字节，而B+树数据库仅为5个字节。此外其扩展性也很好，数据库大小可达到8EB。
二、哈希数据库的高效实现
Tokyo Cabinet使用哈希算法来检索记录，如果一个桶数组包含了多个数目的元素，检索的时间复杂度为O(1)，也就是说检索一条记录的时间恒定在不考虑数据库规模的情况下，对于存储和删除来说也是一样。对于可能出现哈希值冲突，系统通过独立的链来进行管理，链的数据结构为二分查找树，这样即使一个桶数组含有非常多元素，检索时间复杂度也仅仅是O(log n)。
Tokyo Cabinet通过将整个桶数组加载到RAM中来提高检索性能。如果一个桶数组在RAM中的话，通过一系列的文件操作就可以访问到目标记录，一个存储在文件中的桶数组在被‘Read’调用时不是被读取到RAM中而是使用‘mmap’调用直接映射到RAM，这样连接到一个数据库的准备时间就非常短，而且两个或者更多进程就可以共享相同的内存映射表。
传统DBM在存储操作时提供两种模式：‘insert’和‘replace’。在Key和一个已经存在的记录发生重叠的时候，‘insert’模式保持已有的值而‘replace’模式将更新为制定的值。除了这两种模式以外，Tokyo Cabinet还提供了‘concatenate’模式，在这种模式下待存储的值被添加到已存在值的末尾，所以在想添加一个元素给一个值来作为数组的时候这种模式非常有用。
通常来说，在进行连续更新时，已有空间就会发生分段现象，而一个数据库的规模也会迅速增长。Tokyo Cabinet通过将不需要的区域合并重用解决了这个问题。当使用一个尺寸大于原有值的Value重写一个记录的时候，就需要将这段区域移动到文件的另一个地方，而因为操作的复杂度取决于这个记录区域的大小，所以连续地扩展值是很低效的，但是Tokyo Cabinet通过对齐解决了这个问题。如果增长的部分可以添加到填充部分，移动区域就不是必要的了。
为了高效地重用不再需要的区域，这里实现了一个"free block pool"——空闲块池，它维护了一个可重用区域的链表并挑选出那些最合适的区域来重用。但因为分段是不可避免的，这里实现了两种优化机制。第一种方法是静态优化，这种方法首先把所有记录放置到另外一个文件去，然后再一次性重写回最初的文件。第二种方法叫做动态优化，这种方法是通过替换记录和空闲空间的位置来逐渐收集空闲区域。
三、B+树数据库的有效实现
尽管B+树数据库要比哈希数据库慢，但它具有按序访问每条记录的特点，而且排序方式可以由用户进行指定。B+树的记录是排好序地放置在逻辑页面中。B树中组织的稀疏索引对每个页都进行维护，所以检索等操作的时间复杂度为Olog n。在B+树数据库中还可以使用游标来有序地访问每一条记录，游标可以跳跃到键值指定的任何位置并且基于这个位置向前或者向后依次访问记录，又因为每个页都被组织为一个双向链表，所以移动游标的时间复杂度为O1。
B+树数据库是在以上提到的哈希数据库的基础上实现的，因为B+树的每个页在存储的时候都作为哈希数据库的记录，所以B+树继承了哈希数据库存储管理的高效性。在B+树数据库中，因为每条记录的头部更小而且每个页的排列根据页的大小都进行了调整，所以在大多数情况下，数据库文件的大小和哈希数据库相比都减少了一半。此外，尽管很多页操作都需要更新B+树，Tokyo Cabinet通过缓存页和减少文件操作加速了这一过程。在大多数情况下，因为整个稀疏索引都被缓存在内存中，检索一条记录还是很高效的。
B+树的每个页都可以压缩存储，当前系统支持两种压缩方法：Deflate of ZLIB和Block Sorting of BZIP2。因为页中的记录有相似的模式，所以使用Lempel-Ziv或者BWT算法可以得到很高的压缩效率。在处理text数据时，一个数据库的大小可以减少到25%。如果一个数据库规模很大而且磁盘I/O是一个瓶颈的话，使用压缩可以使处理速度提升到很大的一个程度。
四、定长数据库的简单实现
定长数据库的局限性在于每个Key都必须是一个自然数且Value的长度受限，然而如果用例可以接受这样的限制的话，在时间和空间效率上，定长的数据结构都要好于其他结构。因为数据库整个区域都通过'mmap'调用映射到内存中的一个多维数组，所以和文件I/O相关的负担就会减少。因为结构简单，定长数据库比哈希数据库运行得都快，在多线程环境下的并发也更好。
数据库的大小与Key的范围和Value的大小限制成比例，也就是说Key的范围或者Value的长度越小，空间效率就越高。例如，如果Key的最大值为1000000，Value的上限为100个字节，数据库的大小就为100MB，因为相关记录周边的区域也会加载到RAM中，所以用户可以将数据库的大小提升到虚拟内存的大小。
五、表数据库的灵活实现
表数据库不使用简单的Key/Value结构而是使用一种类似于关系数据库表的结构。每条记录都由Key标识并包含一组可以任意命名的列。例如，一个公司里的员工可以由一条使用员工ID作为Key并包含这个员工名称、部门、工资等信息作为列的记录来表示。与关系数据库不同的是，表数据库不需要定义任何数据模式且可以包含彼此结构不同的记录。
表数据库不仅支持针对Key的查询功能，同时还支持针对任意列的条件查询，其中每个条件都由列名和条件表达式组成。对于String类型，系统支持全部匹配、向前匹配、正规表达式匹配等操作；对于number类型，系统支持全部匹配、范围匹配等操作；为了得到逻辑交，一个查询可以包含多个条件；为了得到逻辑并，可以通过多个查询来进行搜索；此外，系统还支持标签搜索和全文搜索。需要注意的是，对于查询的结果集，系统支持按照String或者number的升降序进行排列。
为了提高搜索和排序的性能，用户可以针对任意列创建索引。尽管列没有数据类型，但索引可以有String或者number类型。同时，针对空格分隔的token和N个字符的token，系统支持倒排索引。在建立了这些索引之后，根据每个查询，查询优化器会使用合适的索引来加快查询的速度。
当按B+树来存储时，拥用相同key的记录也能被存储。像hash表一样的读取，存储，删除函数也都有提供，记录按照用户提供的比较函数来存储。可以采用顺序或倒序的游标来读取每一条记录。依照这个原理，向前的字符串匹配搜 索和整数区间搜索也实现了。另外B+树的事务也是可用的。
对于定长的数组，记录按自然数来标记存储，不能存储key相同的两条或更多记录。另外每条记录的长度受到限制，读取方法和hash表的一样。
Tokyo Cabinet是用C写的，同时提供c、perl、ruby、java的API，其在提供了POSIX和C99的平台上都可用，它以GNU Lesser Public License协议发布。
TC因为支持灵活的数据结构而倍受欢迎，特别是Hash Table类型，很像传统的关系型数据库，只是每条存储记录的列是自由定义的，可以通过列作为条件来查询，十分方便。这是很多key-value结构的NoSQL产品所不具备的特性。当然，Hash Table类型和Hash、B+ tree相比存取效率会低一些，任何事物都是有两面性的，在带来高度灵活度的同时，必然要牺牲部分的效率。
TC与下文提及的TT是一个久经考验的很稳定的产品，在千万及以下数据量级别表现出色。但是开发者由于种种原因，已经很长时间没有更新版本了，而是推出了对应升级产品，叫做Kyoto Cabinet和Kyoto Tycoon，这也给TC/TT的前景带来了不明朗的因素，很明显作者是鼓励人们使用升级的产品，但是由于新产品没有更多的成功案例，在业界的影响力反而不如TC/TT，因此在现阶段，TC/TT仍然是一个不错的NoSQL选择。
Tokyo Cabinet is a library of routines for managing a database. The database is a simple data file containing records, each is a pair of a key and a value. Every key and value is serial bytes with variable length. Both binary data and character string can be used as a key and a value. There is neither concept of data tables nor data types. Records are organized in hash table, B+ tree, or fixed-length array.
Tokyo Cabinet is developed as the successor of GDBM and QDBM on the following purposes. They are achieved and Tokyo Cabinet replaces conventional DBM products.
improves space efficiency : smaller size of database file.
improves time efficiency : faster processing speed.
improves parallelism : higher performance in multi-thread environment.
improves usability : simplified API.
improves robustness : database file is not corrupted even under catastrophic situation.
supports 64-bit architecture : enormous memory space and database file are available.
Tokyo Cabinet is written in the C language, and provided as API of C, Perl, Ruby, Java, and Lua. Tokyo Cabinet is available on platforms which have API conforming to C99 and POSIX. Tokyo Cabinet is a free software licensed under the GNU Lesser General Public License.
Tokyo Tyrant
单单的TC数据库，用处不大，宿主程序需要进行很多开发。TC的作者开发了Tokyo Tyrant (TT)这个网络服务程序，除了自己的二进制协议，还提供了现在被广泛应用的HTTP协议，memcached协议来访问TC数据库，这样一来，一下子就扩展了TC的使用范围，让TC从一个单纯的开发库变成了易用，高效的数据库系统。TT支持的协议包括memcached的持续连接，http1.1的长连接，并且数据文件，有热备，更新日志，复制功能，这些都给TT很高的可用性和高性能。并且TT内嵌lua脚本的支持，可以对数据进行处理。
Tokyo Tyrant在启动的时候，通过数据库文件名后缀来表示使用哪种数据结构。
以下是结构和后缀对应表：
Hash Database ：.tch
B+ tree database ：.tcb
fixed-length database ：.tcf
table database ：.tct
Tokyo Cabinet提供了Hash、Fixed-length、Table和B+ Tree四种数据结构，不同的结构特性和应用场景都不一样。TC本身提供了专门测试和调试工具tc(h/f/t/b)mgr。
一)、Hash Database
Hash Database是最基本的结构了，只提供key-value存储方式，类似于memcached，Hash Database的特点是查找速度很快，bucket越多，数据越分散，查找越快。
Hash database支持的参数有："mode", "bnum", "apow", "fpow", "opts", "rcnum", "xmsiz", 和 "dfunit".
内存Hash Database支持的参数有："bnum", "capnum", 和 "capsiz"
二)、Fixed-length Database
Fixed-length Database的读写速度是最快的，并且存储所需的空间是最小的(因为不需要存储数据以外的结构关系，但是因为是定长的，所以会有空间浪费)，key只能是数字，而value的长度是有限的，所以必须设置一个合适的value长度，太长会浪费空间，间接影响性能(TPS)。
Fixed-length database支持的参数有："mode", "width", 和 "limsiz".
三)、B+ Tree Database
B+ Tree Database的特点是一个key可以有重复value，而且允许在value之间上下移动，value按插入顺序排列，可以范围查找key，也可以前缀查找key，查找的复杂度是O(log n)，所以n越大性能越低。
B+ tree database支持的参数有："mode", "lmemb", "nmemb", "bnum", "apow", "fpow", "opts", "lcnum", "ncnum", "xmsiz", and "dfunit"
内存B+ Tree Database支持的参数有："capnum" and "capsiz".
四)、Table Database
Table Database的特点是支持检索，支持多列字段，支持列索引，性能不如其它结构。 它提供了类似RMDB的存储功能，一个主键可以有多个字段，例如，在RMDB中user表可能会有user_id、name和password等字段，而在Table Database也提供这种支持。
Table database支持的参数有："mode", "bnum", "apow", "fpow", "opts", "rcnum", "lcnum", "ncnum", "xmsiz", "dfunit", and "idx".
TC有自己的一套读写缓冲机制，通过xmsiz设置内存缓冲大小，这个参数对整体性能影响比较大。
一、Hash Database
Hash Database是最基本的结构了，只提供key-value存储方式，类似于memcached，Hash Database的特点是查找速度很快，bucket越多，数据越分散，查找越快。
Hash database支持的参数有："mode", "bnum", "apow", "fpow", "opts", "rcnum", "xmsiz", 和 "dfunit".
内存Hash Database支持的参数有："bnum", "capnum", 和 "capsiz"
二、Fixed-length Database
Fixed-length Database的读写速度是最快的，并且存储所需的空间是最小的(因为不需要存储数据以外的结构关系，但是因为是定长的，所以会有空间浪费)，key只 能是数字，而value的长度是有限的，所以必须设置一个合适的value长度，太长会浪费空间，间接影响性能(TPS)。
Fixed-length database支持的参数有："mode", "width", 和 "limsiz".
创建数据库
# tcfmgr create user.f
插入数据
# tcfmgr put user.f 123 00
# tcfmgr put user.f 124 'aa'
查询
# tcfmgr get user.f 123
00
三、B+ Tree Database
B+ Tree Database的特点是一个key可以有重复value，而且允许在value之间上下移动，value按插入顺序排列，可以范围查找key，也可以前缀查找key，查找的复杂度是O(log n)，所以n越大性能越低。
B+ tree database支持的参数有："mode", "lmemb", "nmemb", "bnum", "apow", "fpow", "opts", "lcnum", "ncnum", "xmsiz", and "dfunit"
内存B+ Tree Database支持的参数有："capnum" and "capsiz".
创建数据库
# tcbmgr create user
插入记录，重复key
# tcbmgr put -dd user u1 123
# tcbmgr put -dd user u1 456
# tcbmgr put -dd user u1 789
# tcbmgr put -dd user u2 abc
# tcbmgr put -dd user u2 efg
查询所有记录
# tcbmgr list -pv user
u1 123
u1 456
u1 789
u2 abc
u2 efg
前缀查找
# tcbmgr list -pv -fm u1 user
u1 123
u1 456
u1 789
范围查找
# tcbmgr list -pv -rb u1 u2 user
u1 123
u1 456
u1 789
u2 abc
u2 efg
四、Table Database
Table Database的特点是支持检索，支持多列字段，支持列索引，性能不如其它结构。
Table Database提供了类似RMDB的存储功能，一个主键可以有多个字段，例如，在RMDB中user表可能会有user_id、name和password等字段，而在Table Database也提供这种支持。
Table database支持的参数有："mode", "bnum", "apow", "fpow", "opts", "rcnum", "lcnum", "ncnum", "xmsiz", "dfunit", and "idx".
1.类RMDB的表结构
Table Database最大的特点是支持类RMDB的表结构功能。
创建user表
# tctmgr create user
向表里插入记录
# tctmgr put user 1 "name" "u1" "password" "123"
# tctmgr put user 3 "name" "u3" "password" "123456"
# tctmgr put user 9 "name" "u9" "password" "123456789"
删除记录
# tctmgr out user 3
2.查询
查询所有记录
# tctmgr list -pv user
1 name u1 password 123
3 name u3 password 123456
9 name u9 password 123456789
通过主键查询
# tctmgr get user 1
name u1
password 123
通过其它字段查询
# tctmgr search -pv user name STREQ "u1"
1 name u1 password 123
# tctmgr search -pv user name STREQ "u1" password STREQ "123"
1 name u1 password 123
附查询条件表达式（前面加~，相当于标准sql中的非）[资料来源于采用tokyo cabinet搭建表格型DBM]
STREQ ：完全包含字符串，相当于标准sql中的where 字段='字符串'
STRINC ：包含此字符串，相当于标准sql中like '*字符串*'
STRBW ：以此字符串开头的内容，相当于标准sql中like '字符串*'
STREW ：以此字符串结尾的内容，相当于标准sql中like '*字符串'
STRAND ：包含在某区间内的内容，如标准sql中like 'a-z'，那么他只能是a到z的字母
STROR ：不包含在某区间内的内容，如标准sql中like '!a-z'，那么他只能是数字或其他的符号
STRRX ：组合式结构，如标准sql中like "a"!b-m"#"
NUMEQ ：数值大小一样 相当于标准sql中 where a='1'
NUMGT ：数值大于某一值 相当于标准sql中 where a>'1'
NUMGE ：数值大于等于某一值 相当于标准sql中 where a>='1'
NUMLT ：数值小于某一值 相当于标准sql中 where a<'1'
NUMLE ：数值小于某一值 相当于标准sql中 where a<='1'
NUMBT ：数值处于某一数值区间，相当于标准sql中 where a> 1 and a < 10
NUMOREQ ：数值不处于某一数值的区间，如果是a大于1，小于10的话，那这个表达式右边的内容应该相当于标准sql中 where a< 1 or a > 10
3.排序
# tctmgr search -pv -ord name STRDESC user
9 name u9 password 123456789
3 name u3 password 123456
1 name u1 password 123
排序参数含义如下：
STRASC：按字符升序
STRDESC：按字符降序
NUMASC：按数字升序
NUMDESC：按字符降序
4.设置索引
# tctmgr setindex -it "lexical" user name
索引类型
lexical：词汇
decimal：数字
token：不明白
qgram：不明白
void：不明白
5.tctmgr
tctmgr支持的命令和参数
tctmgr create [-tl] [-td|-tb|-tt|-tx] path [bnum [apow [fpow]]]
创建数据库
tctmgr inform [-nl|-nb] path
输出数据库的状况
tctmgr put [-nl|-nb] [-sx] [-dk|-dc|-dai|-dad] path pkey [cols ...]
创建记录
tctmgr out [-nl|-nb] [-sx] path pkey
删除记录
tctmgr get [-nl|-nb] [-sx] [-px] [-pz] path pkey
通过主键查询记录
tctmgr list [-nl|-nb] [-m num] [-pv] [-px] [-fm str] path
输出所有记录
tctmgr search [-nl|-nb] [-ord name type] [-m num] [-sk num] [-kw] [-pv] [-px] [-ph] [-bt num] [-rm] [-ms type] path [name op expr ...]
通过自定义条件查询记录
tctmgr optimize [-tl] [-td|-tb|-tt|-tx] [-tz] [-nl|-nb] [-df] path [bnum [apow [fpow]]]
优化数据库
tctmgr setindex [-nl|-nb] [-it type] path name
设置索引
tctmgr importtsv [-nl|-nb] [-sc] path [file]
Store records of TSV in each line of a file.
查看版本
Print the version information of Tokyo Cabinet.
小结
Tokyo Cabinet (简称TC)是Mikio Hirabayashi开发的一种DBM的开发库，其数据文件只有一个，里面存放多个<key，value>的数据记录，所有操作都是依据 key做主键操作。key，value都可以是连续不定长，即可以是二进制，也可是是字符串。数据文件中的记录组织有三种模式，hash表，B+树，定长 数组。
做为hash表，主键key必须是唯一的，方法有：按key来存储value到一个记录，按key来删除一个记录，按key来获取一个记录的 value。另外还有一个获取所有key的方法，获取的key是不排序的。TC可以做为NDBM，GBM的替代品，因为有更高的性能。
当采用B+树时，可以存储相同key的多条记录，有存储，删除，读取的方法，还可以按照一定顺序来读取记录。做为一个定长数组，key必须是自然数，其它的和hash表完全一样，因为key是自然数，所以速度比hash表要快。
以上三种数据库即可以只保存在内存中，也可以指定保持到硬盘。应用最广泛的当然就是hash表了。
测试与管理程序
tcrtest ：测试程序， tc remote test
tcrmttest ：多线程测试程序 tc multi-thread test
两个测试程序写入的数据key，value均是8字节的，按照00000001，00000002格式
tcrtest write host rnum : 写入 rnum条记录（是重新写，不是追加）
tcrtest read host : 读出所有记录
tcrtest remote host : 删除所有记录
tcrmgr : 测试和调试ttserver的程序，很多用法就就见官方文档了，主要有：
tcrmgr inform host : 获取服务器的信息
tcrmgr put host key value : 添加记录
tcrmgr get host key : 获取记录
tcrmgr out host key : 删除记录
tcrmgr list host : 列出数据库中所有的key（这个在memcached中是需要patch才能实现的）
tcrmgr vanish host : 删除所有数据
还有一些命名是和主从同步，备份相关的
ttserver和用户数据库
TC、TT这种DBM方式的数据库，对目前的应用来说，最适合的是用来作用户数据库，完全用userid做key。通常存储用户数据库，都使用的是关系型数据库，例如：mysql，pgsql，oracle。从用户数据库特性（数据格式单一，访问量大等）来说，DBM格式是最适合的。在采用TC，ttserve上，最大的问题就是技术支持和持久性。仔细分析这点，对很多普通公司（不深入到opensource代码级）来说，用 mysql，pgsql，oracle等关系型数据库出现问题时，也就是用这些数据库提供的管理命令来调调参数，重启，从备份中恢复。其实使用 TC、ttserver时所做的事情都是一样。再退一万步来说，如果真需要深入到源代码级寻找问题，TC、ttserve两个加起来才1M不到，和 mysql，pgsql源代码的复杂程度相比只有其几十分之一。
google的账户数据库就是<key，value>形式的Berkeley DB (简称：BDB，已经被oracle收购了)， Google. Accounts uses Berkeley DB HA for the storage and retrieval of user 。
ttserver和memcached
ttserver是数据库，memcached是缓存。两者都是保存<key，value>形式的数据，通过key进行任何操作。ttserver可以将数据持久化保存，memcached全部是保存在内存中，memcached会自动删除过期数据，最长不超过30天。memcached在和一些api配合时，能自动进行数据的出入序列化，读取反序列化。ttserver有主从复制的功能，操作日志等，这完全是数据库才有的东西。据说memcached正在对整体架构做调整，到时候支持plugin机制.会把网络，事件处理，内存存储剥离开来，以后要做基于磁盘的key-value存储就可以写一个存储引擎就成了。
TC和BDB
BDB配置开发起来比较麻烦，因为它没有ttserver这个一样的网络接口。BDB的数据文件会比较大，有时需要执行文件收缩，利用BDB开发的memcachedb就有这种问题。BDB开发已经很长时间了，成熟度高，无论是bug，支持资料会比tc要好很多。
ttserver和关系型数据库
ttserver是<key,value>形式，在根据key进行读取，写入时速度是飞快的，但在做统计的时候，就比较麻烦了，还是需要自己写程序，从ulog中到处log，转换成sql语句，后台写入关系型数据库，然后再利用成熟的接口逻辑进行统计。或者应用在更改ttserver时，发送消息(mq,syslog等)到辅助进程，辅助进程进行相应的数据操作。这种情况下，关系数据库完全是ttserver的另一种形式的存在，除了性能有所缺陷，在应用，统计上更加方便。
使用B+存储，可以构造FIFO的队列，通过tcbmgr put -dd c.tcb a aa 可存放进具有重复主键的值，在get的时候，只获取第一个。而使用out命令，可以删除第一个值。
-dd 是 dbputdup缩写的意思。
详细使用可参见《Kyoto Cabinet 基本规格书》
TokyoCabinet安装使用问题集
最新版本：1.4
在1.4.0版本的tc后，又多了一种存储方式 tct，包含了字段的概念。
项目主页：https://dbmx.net/tokyocabinet/