On Wed, Jun 1, 2016 at 1:17 AM, Piotr Dałek <branch@xxxxxxxxxxxxxxxx> wrote: > On Wed, Jun 01, 2016 at 12:49:53AM +0800, Haomai Wang wrote: >> Hi Sage and Mark, >> >> As mentioned in BlueStore standup, I found rocksdb iterator *Seek* >> won't use bloom filter like *Get*. >> >> *Get* impl: it will look at filter firstly >> https://github.com/facebook/rocksdb/blob/master/table/block_based_table_reader.cc#L1369 >> >> Iterator *Seek*: it will do binary search, by default we don't specify >> prefix feature(https://github.com/facebook/rocksdb/wiki/Prefix-Seek-API-Changes). >> https://github.com/facebook/rocksdb/blob/master/table/block.cc#L94 >> >> [..] >> --- a/db/db_bench.cc >> +++ b/db/db_bench.cc >> @@ -2923,14 +2923,12 @@ class Benchmark { >> int64_t key_rand = thread->rand.Next() & (pot - 1); >> GenerateKeyFromInt(key_rand, FLAGS_num, &key); >> ++read; >> - auto status = db->Get(options, key, &value); >> - if (status.ok()) { >> - ++found; >> - } else if (!status.IsNotFound()) { >> - fprintf(stderr, "Get returned an error: %s\n", >> - status.ToString().c_str()); >> - abort(); >> - } >> + Iterator* iter = db->NewIterator(options); >> + iter->Seek(key); >> + if (iter->Valid() && iter->key().compare(key) == 0) { >> + found++; >> + } >> + >> if (key_rand >= FLAGS_num) { >> ++nonexist; >> } > > Aren't you missing "delete iter" here? oh, sure. I retest this, now it's 20us/op. Much better :-). 20 vs 4. And actually this test set is seq int key and the value is small, it will be make the gap not so much. Consider the binary search vs bloom filter, I think the latency is huge. We shouldn't use any iterate except we ensure it's a continuous key set. > > -- > Piotr Dałek > branch@xxxxxxxxxxxxxxxx > http://blog.predictor.org.pl > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
