首页 > 数据库 > 关于TC

关于TC

2010年1月28日 2,554 views 发表评论 阅读评论

Tokyo Cabinet 是日本人 平林幹雄 开发的一款 DBM 数据库. 关于TC,我认为这是一个优秀的作品,却不是一个优秀的产品.突然之间,TC火得一塌糊涂. 这中间有人推介,但他们却很少说他的坏处. 不过对于数据不敏感的场合,用tc还是很不错的,毕竟在一个操作里实现存取,持久化还是很方便研发同学的.也具备了一定的安全性.

公司目前许多应用都使用了TC,但是TC的灾难恢复性能仍然有待生产环境验证,tc的推广难度不在于维护人员的经验,而在于先天的维护性太差.因为虽然实例稳定,但机器却不一定稳定,而且目前的B+树组织的tc存在未知的原因,导致异常关闭会丢失数据.毕竟这是一个个人作品,而不是一个久经考验的商业产品,虽然作者很猛. 作者要是也开发一个强大的维护工具就好了.

tc虽然不如很多人宣传的那样神乎其神.,但满足应用一般无问题. ,因为采用简单高效的存储结构,存储key-value对,没有关系数据库的join操作,比较适合来做存储用户,session等,可以达到很好的并发 .实际上,如果mysql也使用很简单的数据结构,使用简单的操作,注意开发中的优化,配合memcached一样可以达到很高的吞吐率.

记录一些TC维护的注意事项:

1.正常关闭tt,没什么问题,但是异常关闭,数据的恢复却成为一个问题, TT不能满足我们的期望的灾难恢复性 .时间点回复,自动recover,一个都不支持.特别是B+形式组织的库,恢复性能更差. 还可能导致丢失数据. 所以我一般推荐研发同学使用HASH组织的库.

2.数据的统计. 这点上tc就是弱点了. 所以还是得借助关系型数据库,

3.对于TC,要有丢失数据的准备,应能够容许一定时间范围内的数据损失,这点在设计之前就应该确认,最好有后备的数据库备份;tc从库的备份,官方的说明,ms是拉数据的方式,但实际生产过程,从库的备份却会导致主库的性能下降,可能用户连接不上,所以这个备份机制仍然存在问题.

4.数据的记录数,key,value的长度,对性能影响大,需要事先确定, hash库会应用配置的记录参数初始化bucket array.  官方的测试是很简单的key-value对,而实际生产中的数据变化很大,且可能较大,所以实际生产环境的吞吐率可能低得多,因为最终io密集型的操作会受制于磁盘的读写速度,地盘的吞吐率,除非你使用主库memory,从库file的方式来架构数据服务器.

5.关于B+tree database,设置lcnum,bnum, lcnum(cache的叶节点的数量,每个页节点应该是保存一定量的数据记录,写入以leaf page为单位)大些好,但由于数据未及时flush到磁盘,会造成关闭tc可能很慢,因为需要写入脏数据到磁盘才能彻底关闭数据库, ,bnum(bucket number) 大于 1/128*记录总数 ;

6.关于hash database,设置bnum(bucket number),大于储存的记录数,保证一次命中,否则可能需要遍历链表(Collision of hash values is managed by separate chaining,Data structure of the chains is binary search tree);

7. hash database key值必须唯一,bucket number足够情况下,查找的时间复杂度为“O(1)”,查找速度和数据库的大小无关.

8. B+tree database支持数字的范围查找(range search)和字符串的向前匹配(forward matching search). #索引叶子节点之间是双向链接.
B+tree查找的时间复杂度为“O(log n)”.
9. 应尽可能的将索引和page都缓存在内存中.如果io和空间成为瓶颈,需考虑压缩选项(B+树组织的压缩率较高,压缩以leaf为单位吧,而hash库以记录为单位压缩,那么对于短记录,可能效果很差了,毕竟压缩校验本身也要数据位的)(增加了cpu运算,但至今我们维护的系统,cpu都还较空闲).
10.如果tt的性能日后已经不满足高并发,我们可采用主库on-memory hash database/tree,从库file hash/tree database,这样可以提高吞吐率,高并发下的读写tc可能崩溃(软硬件导致),会破坏数据页,这种架构从库可实现数据无损持久保持.ssd是一种好选择,但需要充分测试,并考虑到寿命的因素.
11.关于碎片问题,tc合并不需要的空间或者重用之,关于分配空闲block,用一个 “free block pool(链)来维护自由空间.算法为选择 the smallest region .不过暂未有更细致的文档讲述碎片的具体处理;
12 关于hash database匹配的冲突概率(the probability of collision of hash values):is about (56.7% if is half of records stored within a database ,36.8% if the same, 21.3% if twice, 11.5% if four times, 6.0% if eight times)
所以计算方式: 假如我们选择1倍数据记录的bucket array , 2亿记录所需要的内存大小为 200,000,000(记录数)*4(字节)=762M #The size of each element is 4 bytes
13.关于table database ,我在网页中未看到具体哪种模式支持,ms都支持.table database ms很好,支持复杂的条件查询(primary key ,other columns ,Union),索引(可在其上创建索引),排序等, #Indices(索引)是个独立文件.
14. 关于B+ tree  B+tree key允许重复,Records of B+ tree are sorted and arranged in logical pages B+ tree database is implemented, based on above hash database.
15. 关于事务,tc是支持事务的..(未验证何种组织的tc库支持)
Databases on the filesystem feature transaction mechanisms. It is possible to commit a series of operations between the beginning and the end of the transaction in a lump
支持的隔离级别为:serializable and read uncommitted
16 .关于锁,B+tree不是基于行的,而是基于整个文件的.
The locking granularity of hash database and fixed-length database is per record, and that of the other databases is per file
The End.

官方的一些tunning建议:
If you use a hash database, set the tuning parameter “#bnum=xxx” to improve performance. #bnum设置为大于记录数,设置成几倍也没关系,占用的内存并不多,且可减少冲突率;
If you use a B+ tree database, set the tuning parameters “#lcnum=xxx#bnum=yyy” to improve performance.The former specifies the maximum number of leaf nodes to be cached. It should be larger as long as the capacity of RAM on the system allows. The latter specifies the bucket number and should be more than 1/128 of the number of records to be stored. #lcnum设置为较大值,关闭的时候必须flush脏数据完才能关闭,可能耗时非常之久,没有什么io压力的话,不要设置过大,b+树的库bnum设置为超过1/128的数据记录即可,应该是在内存中构建一个hash数组来找寻index leaf(node) ,我设置为1/100总记录数,这个设置大了也没什么,I guess;
关于参数xmsiz: Set the size of the extra mapped memory. 设置为大于数据文件,应可提高性能,数据操作在可在映射的内存中进行.

部分参数
`lcnum’ specifies the maximum number of leaf nodes to be cached. If it is not more than 0, the default value is specified. The default value is 1024.
`ncnum’ specifies the maximum number of non-leaf nodes to be cached. If it is not more than 0, the default value is specified. The default value is 512.

`lmemb’ specifies the number of members in each leaf page. If it is not more than 0, the default value is specified. The default value is 128.
`nmemb’ specifies the number of members in each non-leaf page. If it is not more than 0, the default value is specified. The default value is 256.
`bnum’ specifies the number of elements of the bucket array. If it is not more than 0, the default value is specified. The default value is 32749. Suggested size of the bucket array is about from 1 to 4 times of the number of all pages to be stored.

 » 转载保留版权:老陈 » 《关于TC》
 » 如果喜欢可以: 点此订阅本站
分类: 数据库 标签: ,
  1. 本文目前尚无任何评论.
  1. 本文目前尚无任何 trackbacks 和 pingbacks.