TCDatabase介绍(3)

四、存储数据结构

1、TCT的存储数据结构

TC的不同的数据类型,有不同的数据存储结构。这里主要介绍TC的Table类型的存储结构。

每个TC的Table,起码有一个*.tct文件。这个tct,是在hash数据库的基础上改进而来的。下面转贴几张张宴的PPT里的图。

abca024d-7c21-4bbd-b04e-ad04237cd8e9665ba35e-e9d9-422f-877c-483bd93d4792

fb69c4c9-bf10-49ff-865e-cf7cf20ffdcd[4]

TCT的改进,就是在Hash的Key-Value的Value部分,动了一些手脚,将多个字段打成一个大包,都存在一个Value里去了。

另外,TCTDB,有可能会有一个*.tct.idx文件,这个idx,是一个B+Tree结构,将一个table中的各个需要建立索引的字段数据,在TCBDB中建立索引。

TCBDB的结构图如下:

a408324c-cc21-43b6-b35c-21e5f3b16c57

在idx文件里,则是将value与key反过来存放。

2、TCDatabase的存储数据结构

为了解决之前提到过的TCTDB存在的问题,我们设想的TCDatabase的结构,将是这样的:

1、表结构(data.tcb.cfg) TCHDB
table_name1 => {column1=>string,column2=>int}
table_name1_count => 10
table_name1_index => {column1,column2}
table_name2 => {column1=>string,column2=>int}
table_name2_count => 10
table_name2_index => {column1,column2}
2、记录集(data.tcb)  TCBDB
table_name1/pkey1.column1 => value1
table_name1/pkey1.column2 => value2
table_name1/pkey2.column1 => value3
table_name1/pkey2.column2 => value4
table_name2/pkey1.column1 => value5
table_name2/pkey1.column2 => value6
3、索引(data.tcb.idx)  TCBDB
table_name1/column1/value1\0pkey1 => pkey1
table_name1/column1/value3\0pkey2 => pkey2
table_name1/column2/value2\0pkey1 => pkey1
table_name1/column2/value4\0pkey2 => pkey2
table_name2/column1/value5\0pkey1 => pkey1
table_name2/column1/value6\0pkey2 => pkey2

下面做一些解释:

  • 增加一个cfg文件,一个Hash DB方式存储表结构信息,包括一个表包含哪些字段,这些字段分别是什么属性,一个表的记录总数,这个表需要建立哪些索引等等。
  • 记录集以B+ Tree方式存放,而非原来的Hash DB,这样可以在数据量上亿以后,获得更好的性能
  • 在记录集中,一行数据的各个字段的值,分别存在不同的key-value中,因此,如果一个表有3个字段,那么它的每条记录,就要占3个key。
  • 在读写数据时,有两种方式可以选择:按行读写,或按列读写
    • 所谓按行读写,就是一次读写一个primary key指向的n个字段,具体有哪些字段,由cfg决定。
    • 所谓按列读写,就是一次只读写一个primary key指向的那一行中的具体一个字段,这时的读写,不受cfg中的table字段定义的限制。
  • 索引数据,以B+ Tree方式存放,因为不同的行(primary key),在某一个字段,可能存在值重复,因此key的规则为:value\0key。这样保证每一个primary key,会有一个对应的索引key。如果以“table_name/column/value”的方式查询,则可以将同值的多个key,都查出来。

(未完待续)

TCDatabase介绍(2)

三、TokyoTyrant的网络协议

1、简单介绍

介绍这个,其实价值不大,因为详细的文档都在那里呢:http://1978th.net/tokyotyrant/spex.html#protocol

不过,还是要说一下,因为我对TT的协议,颇有些不满。

TT的协议,各位如果仔细看,就会发现,这是一个典型的未经重构的,临时拼凑起来的协议。最初的TT,只考虑了基本的put、putkeep、putcat、out、get、mget等等命令,每个命令都以0xC8开头,然后再加上一个16位二进制数。

put          0x10

putkeep   0x11

putcat      0x12

putshl      0x13

putnr       0x18

out          0x20

get          0x30

mget       0x31

……

但是,他还有一个misc命令,所有与Table数据类相关的命令,都包含在misc里面,misc的格式是这样的:

[magic:2][nsiz:4][opts:4][rnum:4][nbuf:*][{[asiz:4][abuf:*]}:*]

magic:  0xC8 0x90

nsiz:     name的长度

opts:    option参数

rnum:   后续参数的个数

nbuf:    name

asiz与abuf交替出现,表示每一个参数

因此,我们针对RDBTBL的操作,最终都会调用misc命令。

rdb = RDB::new

rdb.open(“localhost”, 3900)

rdb.put(“foo”, “hop”)

#发出0xC8 0x10 0x0003 0x0003  “foo”    “hop”

#      magiccode ksiz      vsiz       kbuf*   vbuf*

rdb = RDBTBL::new

rdb.open(“localhost”,3900)

rdb.put(“foo”,{“hop”=>”value”})

#发出0xC8 0x90 0x0003 0x0000  0x0003  “put”    0x0003 “foo”     0x0003 “hop”    0x0005 “value”

magiccode nsiz      opts      rnum      nbuf*  asiz1    abuf1*  asiz2    abuf2*  asiz3    abuf3*

看上去非常类似的代码,发出的网络数据流,却完全不同。

2、misc的问题

TT的协议中,最麻烦的,就是这个misc命令,效率最低的,也是这个misc命令,Table型数据,一共支持10个不同的命令,却全部被堆到一个misc里来完成了。

按照某种合理的逻辑,这些命令,应该跟正常的其他命令类似,各自分配到自己的magic code,各自有自己的命令格式和定义,而不是像现在这个样子。

即使是这个misc本身,也非常糟糕,将key与value,放到一个数组里,而且整个数组也没有一个总的长度,使得解析也变得效率低下了。

目前的TCDatabase,因为是在TT的skeleton基础上开发,因此接收的命令与TT完全一致。这当然降低了开发的难度。但是,要想进一步改善TT,或者说要想做出一个TCDatabase,抛弃现有的二进制协议,另起炉灶,应该是一个必然的选择。

3、TCDatabase的协议设想

这个是一个初步的设想,还需要跟riceball详细讨论,才能确定下来:

  • 每个命令一个不同的magic code
  • [key_size] 如果需要key作为参数的话
  • [key_buf*] 如果需要key作为参数的话
  • [opts]        选项
  • [arguments_size]  参数总长度
  • [arguments_length]  参数个数
  • [arguments_1_size]  第一个参数的长度
  • [arguments_1_buf*]  第一个参数
  • ……

相比原来的TT协议,这样应该更容易解析一些,效率也会有提升。

(待续)

TCDatabase介绍(1)

TCDatabase,是我在创新院的同事,riceball的一个开源项目。http://code.google.com/p/tcdatabase

他自己也写了两篇blog作介绍。tcdatabase(一) tcdatabase(二)

不过我总感觉写得太像干巴巴的技术文档了,所以我自告奋勇的来帮他另写一个介绍,以下是第一部分:

 

一、TokyoCabinet、TokyoTyrant简介

我们常说的TC/TT,是TokyoCabinet/TokyoTyrant的简称。这两个开源项目,都是由日本人平林幹雄开发的。(Mikio Hirabayashi’s Homepage twitter: @hirabayashiM)

1、TokyoCabinet

TC,是一个Key-Value的数据库library,你可以通过C语言程序来访问TC提供的各种函数,也可以使用其他各种语言绑定,例如perl、ruby、java、lua。

TC对外的表现形式,无非是一组put/get方法,从内部实现来说,TC一共支持6种不同的数据结构,包括hash数据库,B+树数据库,定长数据库、表格数据库、内存hash数据库以及内存B+树数据库。

以ruby语言举例:

hdb = HDB::new

hdb.open("casket.tch", HDB::OWRITER | HDB::OCREAT)

hdb.put("foo", "hop")

value = hdb.get("foo")

hdb.close

这样就可以创建一个名为casket.tch的Hash数据库文件,并进行put/get的操作。

也可以通过ADB(Abstract database),以完全相同的API,创建并访问不同的数据库。

adb = ADB::new

adb.open(name) 

adb.close

其中,如果name为*,则创建一个内存hash数据库;name为+,则是内存B+树数据库;文件名为*.tch、*.tcb、*.tcf、*.tct则分别对应于hash、B+Tree、fixed-length和table类型。

2、TokyoTyrant

至于TT,则是在TC基础上实现的一个server。TT接受来自socket连接的各种请求,作为一个网络服务而存在着。通常我们会这样来启动TT。

ttserver –port 3900 /ttdata/casket.tch

这样,在3900端口,就启动了一个数据库服务,这个数据库的数据,就保存在/ttdata/casket.tch中。

而在client端,也多种不同的语言实现,例如ruby的代码会写成这样:

rdb = RDB::new

rdb.open("localhost", 3900)

rdb.put("foo", "hop")

value = rdb.get("foo")

rdb.close

对于table类型的数据库,则需要创建一个RDBTBL的对象实例,因为它提供了更多的一些访问API,例如:

rdb = RDBTBL::new

rdb.open("localhost", 1978)

rdb.put("1", { "name" => "mikio", "age" => "30", "lang" => "ja,en,c" })

qry = RDBQRY::new(rdb)

qry = RDBQRY::new(rdb)

qry.addcond("age", RDBQRY::QCNUMGE, "20")

qry.addcond("lang", RDBQRY::QCSTROR, "ja,en")

qry.setorder("name", RDBQRY::QOSTRASC)

qry.setlimit(10)

res = qry.search

res.each do |rkey|

  rcols = rdb.get(rkey)

  printf("name:%s\n", rcols["name"])

end

这样的操作,就已经相当接近于对一个传统表的操作了。

 

二、TCDatabase对TokyoTyrant的扩展

1、skeleton机制

TT对于扩展的支持相当友好,在ttserver中,有一个-skel参数,可以在启动ttserver的时候,挂一个自己写的骨架系统,例如:

ttserver -skel mydb.so -port 3900 myfile.tct

这样,ttserver的功能,就成了一个简单的网络接口,而接收到的各种请求,都为转交给mydb.so来处理。接下来的事情,就海阔天空了。对于client端来说,他访问的是标准的TT接口,而在server端,却完全可以通过自己写的一个扩展,将数据存到mysql里面去。

而tcdatabase,就是TT的一个skeleton实现。所以,他的启动参数是这样的:

ttserver -skel tcdatabase.so -port 3900 db_filename.tcb

2、TCTDB的不足之处

作为最像传统表的Key-Value数据库,TCTDB有很多优点,这成为我们项目选择的主要考虑对象,但是它也存在着诸多问题:

  • 一个Table Database仅支持一个表,也就是说value中的字段必须固定一致。假设一个项目中使用了80多个表,这意味着你需要开启80多个 ttserver进程,并为每一个“表”提供支持。
  • 功能的增强,也就意味着要牺牲性能。TCTDB 表格型数据库的平均读取速度大约在40万条/秒,相比 TCHDB哈希数据库的180万条/秒和TCBDB B+Tree数据库 的100万条/秒要慢。
  • TCTDB虽然可以建立数值型索引,但是它是将所有value数据都当成字符型来处理的,无法区分value类型。
  • TCTDB单数据库文件存储的记录数上亿条后,性能会有比较明显的下降。
  • 不能单独获取value中的某一个字段的值;
  • 不能支持仅更新UPDATE key中某一个字段:必须先取出value的全部字段,再存入;

3、TCDatabase的改进

  • 支持多个table从一个端口访问,从table变成真正的database,
  • 数据文件改用采用TCBDB(B+Tree Database)进行存储,为了解决数据量上亿后的HashDB性能的问题
  • 支持列读写
  • 应该还有其它更多改进,不过都还在规划之中

 

(待续)