TokuDB之黑科技工具

刚过完年，美女程序员静静想学习下 TokuDB 相关技术，从何处入手呢？TokuDB的技术资料可是出了名的少！ 本篇就给大家介绍下两个“黑科技”工具，来帮助我们更深入的了解TokuDB。

黑科技之tokuftdump

此工具用来dump一个Fractal-Tree结构的数据文件。

这样我们就可以很直观的知道我写入的数据在磁盘上是个什么样子(disk layout)。

废话少说，一切尽在“栗子”中。

创建表t1:

  1. CREATE TABLE `t1` (
  2.   `a` int(11) NOT NULL,
  3.   `b` int(11) DEFAULT NULL,
  4.   PRIMARY KEY (`a`)
  5. ) ENGINE=TokuDB

写入数据并刷到磁盘:

  1. mysql> INSERT INTO t1 VALUES(1,1);
  2. mysql> INSERT INTO t1 VALUES(2,2);
  3. mysql> INSERT INTO t1 VALUES(3,3);
  4. mysql> UPDATE t1 SET b=4 WHERE a=3;
  5. mysql> FLUSH TABLES t1;

使用tokuftdump进行数据dump:

  1. ./bin/tokuftdump data/_test_t1_main_90_2_1b.tokudb
  2. ...
  3. {key={len=5 data="\000\001\000\000\000"} cI: xid=0000000000000000 val={len=5 data="\375\001\000\000\000"}}
  4. {key={len=5 data="\000\002\000\000\000"} cI: xid=0000000000000000 val={len=5 data="\375\002\000\000\000"}}
  5. {key={len=5 data="\000\003\000\000\000"} cI: xid=0000000000000000 val={len=5 data="\375\003\000\000\000"} pI: xid=000000009a93a265 val={len=5 data="\375\004\000\000\000"}}

可以看到，在数据文件里每一行数据都是一个对，再维护一个MVCC结构就可以满足ACID特性了。

最后一条记录就是执行完UPDATE后MVCC：有2个val存在，xid(transaction id)不同，需要注意的是 tokuftdump 会对数据进行重组织展现，并非磁盘上的原生结构。

如果你想深入了解TokuDB的Fractal-Tree结构，这是个必不可少的工具，它不仅可以 dump 数据，还可以 dump Fractal-Tree 的全部信息，让底层存储结构“跃然屏上”。

黑科技之 tdb_logprint

此工具用来dump TokuDB的redo-log，让我们了解TokuDB redo-log是如何组织的。

接下来我们看下执行完刚才的SQL后，窥探下redo-log里又是些什么鬼:

  1. ./tdb_logprint < data/log000000000002.tokulog27
  4. xbegin                   'b': lsn=64 xid=144,2 parentxid=144,0 crc=97572838 len=53
  5. enq_insert               'I': lsn=65 filenum=3 xid=144,2 key={len=15 data="./test/t1-main\000"} value={len=31 data="./_test_t1_main_90_2_1b.tokudb\000"} crc=d259724f len=95
  6. fcreate                  'F': lsn=66 xid=144,2 filenum=7 iname={len=30 data="./_test_t1_main_90_2_1b.tokudb"} mode=0666 treeflags=0 nodesize=4194304 basementnodesize=65536 compression_method=11 crc=3755db8b len=95
  7. xcommit                  'C': lsn=67 xid=144,2 crc=ffad0139 len=37
  8. change_fdescriptor       'D': lsn=68 filenum=7 xid=144,0 old_descriptor={len=0 data=""} new_descriptor={len=18 data="\011\000\000\000\001\000\000\004\000\005\000\000\000\001\004\000\000\000"} update_cmp_descriptor=true crc=acef9cdb len=68
  9. xcommit                  'C': lsn=69 xid=144,0 crc=ffa0c139 len=37
  10. fclose                   'e': lsn=70 iname={len=32 data="./_test_t1_status_90_1_1b.tokudb"} filenum=5 crc=73c0dbf1 len=61
  11. fclose                   'e': lsn=71 iname={len=30 data="./_test_t1_main_90_2_1b.tokudb"} filenum=7 crc=060f6b9f len=59
  12. fopen                    'O': lsn=72 iname={len=32 data="./_test_t1_status_90_1_1b.tokudb"} filenum=9 treeflags=0 crc=c8de90f1 len=65
  13. fopen                    'O': lsn=73 iname={len=30 data="./_test_t1_main_90_2_1b.tokudb"} filenum=11 treeflags=0 crc=b38239c5 len=63
  14. xbegin                   'b': lsn=74 xid=146,0 parentxid=0,0 crc=9a083238 len=53
  15. enq_insert               'I': lsn=75 filenum=11 xid=146,0 key={len=5 data="\000\001\000\000\000"} value={len=5 data="\375\001\000\000\000"} crc=658a7b0b len=59
  16. xcommit                  'C': lsn=76 xid=146,0 crc=ff98be39 len=37
  17. xbegin                   'b': lsn=77 xid=148,0 parentxid=0,0 crc=8602ef38 len=53
  18. enq_insert               'I': lsn=78 filenum=11 xid=148,0 key={len=5 data="\000\002\000\000\000"} value={len=5 data="\375\002\000\000\000"} crc=59dad00b len=59
  19. xcommit                  'C': lsn=79 xid=148,0 crc=ff9f3339 len=37
  20. xbegin                   'b': lsn=80 xid=150,0 parentxid=0,0 crc=821b8438 len=53
  21. enq_insert               'I': lsn=81 filenum=11 xid=150,0 key={len=5 data="\000\003\000\000\000"} value={len=5 data="\375\003\000\000\000"} crc=926d5d14 len=59
  22. xcommit                  'C': lsn=82 xid=150,0 crc=ff93b439 len=37
  23. xbegin                   'b': lsn=83 xid=152,0 parentxid=0,0 crc=8e1ca138 len=53
  24. enq_insert_multiple      'm': lsn=84 src_filenum=11 dest_filenums={num=1 filenums="0xb"} xid=152,0 src_key={len=5 data="\000\003\000\000\000"} src_val={len=5 data="\375\004\000\000\000"} crc=ecb1c6f0 len=67
  25. xcommit                  'C': lsn=85 xid=152,0 crc=ff962939 len=37
  26. fclose                   'e': lsn=86 iname={len=30 data="./_test_t1_main_90_2_1b.tokudb"} filenum=11 crc=8709a890 len=59
  27. fclose                   'e': lsn=87 iname={len=32 data="./_test_t1_status_90_1_1b.tokudb"} filenum=9 crc=c43070f7 len=61
  28. begin_checkpoint         'x': lsn=88 timestamp=1455623796540257 last_xid=153 crc=470dd9ea len=37
  29. fassociate               'f': lsn=89 filenum=0 treeflags=0 iname={len=15 data="tokudb.rollback"} unlink_on_close=0 crc=8606e9b1 len=49
  30. fassociate               'f': lsn=90 filenum=1 treeflags=4 iname={len=18 data="tokudb.environment"} unlink_on_close=0 crc=92dc4c1c len=52
  31. fassociate               'f': lsn=91 filenum=3 treeflags=4 iname={len=16 data="tokudb.directory"} unlink_on_close=0 crc=86323b7e len=50
  32. end_checkpoint           'X': lsn=92 lsn_begin_checkpoint=88 timestamp=1455623796541659 num_fassociate_entries=3 num_xstillopen_entries=0 crc=5cde4ff2 len=45

wow，redo-log其实就是FT(TokuDB底层存储引擎缩写，ft-index)所有操作指令的回放。

当我们执行CREATE TABLE的时候，FT执行指令是：

  1. 1) 开启事务
  2. 2) 把创建的表信息记录到元数据库 tokudb.directory
  3. 3) 创建表文件
  4. 4) 提交事务

创建表的过程是不是很清晰了？

接着看写数据，FT执行的指令：

  1. 1) 打开表文件
  2. 2) 事务开始
  3. 3) 写入记录
  4. 4) 事务提交
  5. ...
  6. 5) 关闭表文件
  7. ...

在redo-log的最后我们还看到checkpoint信息，包括checkpoint时的lsn以及时间等。

通过 tdb_logprint，我们可以很轻松的知道TokuDB底层到底在干什么，如果你想了解TokuDB底层行为，请开启你的 tdb_logprint 之旅吧。

如果你对TokuDB某个细节不清楚，请执行下你的SQL，结合这两个工具，再加上源码，基本可以做到胸中有数了。

静静你可以静静的学习TokuDB了 :D