tokuDB容量测试

结论1:toku引擎不支持char类型字段压缩.

结论2:在原toku表基础上,直接修改压缩比(ROW_FORMAT)后,在optimizer前,不会调整大小,optimizer后表和索引大小会调整,但表空间和索引空间大小不确定,一般都是变大(tokudb_uncompressed除外).

项目:测试toukeDB对于回溯表改善,
1,转移表为只有f开否的.
2,创建touke表,再进行数据转移,对比容量.


3,换表名,检查查询兼容性,包括关联查询.
4,sysbench测试插入效率.5,写出结论性报告.
6,咨询阿里,touke表现稳定性.阿里自己也在使用,应该没问题.




1,转移表为只有f开否的.完成.
2,创建touke表,再进行数据转移,对比容量.




CREATE TABLE `rs_plate_trace_toku` (
  `PLATE_TRACE_ID` varchar(36) NOT NULL COMMENT '主键',
  `PARK_ID` char(36) NOT NULL COMMENT '停车场ID',
  `PARK_CODE` char(36) NOT NULL COMMENT '停车场编码',
  `BAR_CODE` varchar(36) NOT NULL COMMENT '视频设备编码',
  `BERTH_NUMBER` varchar(12) DEFAULT NULL COMMENT '泊位号',
  `PARK_SPACE_ID` char(36) DEFAULT NULL COMMENT '泊位ID',
  `DATA_SOURCE` tinyint(4) DEFAULT NULL COMMENT '数据来源:',
  `IMAGE_TYPE` tinyint(1) NOT NULL COMMENT '图片类型：1=全景，2=特写',
  `IMG_PATH` varchar(200) NOT NULL COMMENT '图片路径',
  `UPLOAD_TIME` datetime DEFAULT NULL COMMENT '上传时间',
  `CREATOR_TIME` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '系统创建时间',
  PRIMARY KEY (`PLATE_TRACE_ID`),
  KEY `idx_rs_plate_trace_uploadTime` (`UPLOAD_TIME`),
  KEY `IDX_PLATE_TRACE_BAR_CODE` (`BAR_CODE`),
  KEY `idx_hardCode_imageType_uploadTime` (`BAR_CODE`,`IMAGE_TYPE`,`UPLOAD_TIME`)
) ENGINE=tokuDB DEFAULT CHARSET=utf8 COMMENT='路侧车牌图片跟踪记录'


insert ignore into `rs_plate_trace_toku`(
PLATE_TRACE_ID,PARK_ID,PARK_CODE,BAR_CODE,BERTH_NUMBER,PARK_SPACE_ID,DATA_SOURCE,IMAGE_TYPE,IMG_PATH,UPLOAD_TIME,CREATOR_TIME)
 select * from rs_plate_trace where plate_trace_id like 'ff%';


rs_plate_trace_vchar(原始表)
行数
719021
数据容量
214.00M
索引容量
119.05M




rs_plate_trace_toku (有多个char类型)
数据容量
192.00M
索引容量
96.00M


将char(36)全部改成varchar(varchar)后.  #通过容量得出结论,char类型字段,toku引擎不支持压缩.
数据容量
96.00M
索引容量
64.00M




1,清空toku,出入以上数据:
alter table `rs_plate_trace_toku` ROW_FORMAT=tokudb_zlib;
数据容量
48.00M
索引容量
96.00M
optimize后,表空间变大:
数据容量
96.00M
索引容量
96.00M


alter table `rs_plate_trace_toku` ROW_FORMAT=tokudb_quicklz;
数据容量
64.00M
索引容量
96.00M
optimize后,表空间变大(结果不稳定,但肯定变大):
数据容量
128.00M
索引容量
112.00M


alter table `rs_plate_trace_toku` ROW_FORMAT=tokudb_lzma;
数据容量
48.00M
索引容量
64.00M
optimize后,表空间变大(结果不稳定,但肯定变大):
数据容量
96.00M
索引容量
80.00M


alter table `rs_plate_trace_toku` ROW_FORMAT=tokudb_uncompressed;
数据容量
208.00M
索引容量
336.00M
optimize后,结果不稳定:
数据容量
384.00M
索引容量
192.00M


结论:在原toku表基础上,直接修改压缩比(ROW_FORMAT)后,在optimizer前,不会调整大小,optimizer后表和索引大小会调整,但表空间和索引空间大小不确定,一般都是变大(tokudb_uncompressed除外).