table{ padding:2px; border:1px solid #aaaaaa; border-collapse:collapse; } td{ padding:2px; border:1px solid #aaaaaa; border-collapse:collapse; } 当cache开到1G大小时,数据如下(其中大小单位为字节,时间单位为秒):
由于cache非常大,几乎所有的数据都可以放在里面,所以两种索引方式的存取效率基本一样。
如果把cache改为32M,测试结果又如下:
其中“缺”字表示测试无法进行,因为当数据太大时,用Hash索引运行bdb几乎把机器搞死,我不得不中断测试。这组测试看得出:如果使用BTree,随着数据的翻倍,写的时间也近乎翻倍,但读的时间非常稳定,对于数据量大、写少读多的应用(比如bbs、图片服务等)应该尽量使用BTree索引。
总的来看,BerkeleyDB的Hash索引表现古怪,只在小cache小数据量的情况下查询速度快于BTree,可现在哪会有这种情况?还是用BTree索引保险一些。
Cache为1G时 | ||||
value大小(字节) | Hash写时间 | Hash读时间 | BTree写时间 | BTree读时间 |
32 | 12 | 6 | 4 | 3 |
64 | 8 | 4 | 4 | 3 |
128 | 7 | 4 | 5 | 3 |
256 | 7 | 4 | 6 | 3 |
由于cache非常大,几乎所有的数据都可以放在里面,所以两种索引方式的存取效率基本一样。
如果把cache改为32M,测试结果又如下:
Cache为32M时 | ||||
value大小(字节) | Hash写时间 | Hash读时间 | BTree写时间 | BTree读时间 |
32 | 11 | 6 | 5 | 39 |
64 | 205 | 62 | 17 | 50 |
128 | 缺 | 缺 | 44 | 42 |
256 | 缺 | 缺 | 186 | 51 |
其中“缺”字表示测试无法进行,因为当数据太大时,用Hash索引运行bdb几乎把机器搞死,我不得不中断测试。这组测试看得出:如果使用BTree,随着数据的翻倍,写的时间也近乎翻倍,但读的时间非常稳定,对于数据量大、写少读多的应用(比如bbs、图片服务等)应该尽量使用BTree索引。
总的来看,BerkeleyDB的Hash索引表现古怪,只在小cache小数据量的情况下查询速度快于BTree,可现在哪会有这种情况?还是用BTree索引保险一些。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/263089/viewspace-684037/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/263089/viewspace-684037/