码迷,mamicode.com
首页 > 数据库 > 详细

tair源码分析——leveldb存储引擎使用

时间:2014-07-27 22:41:49      阅读:574      评论:0      收藏:0      [点我收藏+]

标签:style   blog   color   使用   数据   io   for   问题   

分析完leveldb以后,接下来的时间准备队tair的源码进行阅读和分析。我们刚刚分析完了leveldb而在tair中leveldb是其几大存储引擎之一,所以我们这里首先从tair对leveldb的使用和修改来窥探在这个分布式的存储引擎中是如何将area和bucket持久化到存储,并且方便bucket和area的处理的。

我们首先来看tair中key的结构,我们以大致梳理存储和查询一个KV的流程来确认key的处理。tair_client_api::put直接调用tair_client_impl::put,impl中首先会对key和value(data)进行合法性判断,然后调用get_server_id取得存储当前key的server_id后将组装好的request_put发送到服务器端。服务端接收到消息后handlePacketQueue解码然后会调用对应的process函数,这里是 request_processor::process(request_put *, ……)这个函数。这个函数会进行一些plugin和是否存储在本地等一些处理和判断,我们这里只需关注其调用到了tair_manager::put,这个函数里面对可以进行了一定的处理

data_entry mkey = key; // key merged with area
mkey.merge_area(area);
int bucket_number = get_bucket_number(key);

而
       void merge_area(int _area)
       {
         if(has_merged) {
           return;
         }
         if(size < 0) return;
         //now should check is alloc by me. I have 2 extra head.
         if(m_true_size==size+2)
         {
           m_true_data[0]=(_area & 0xFF);
           m_true_data[1]=((_area >> 8) & 0xFF);
           size=m_true_size;
           data=m_true_data;
         }else{
            //一些重新分配空间然后和if分支类似的处理
         }
       }

这里即将area编码后放到了key_entry的最前两位,接下来看LdbInstance::put,里面处理得到cdate、mdate、edate,然后获得一个

LdbKey ldb_key(key.get_data(), key.get_size(), bucket_number, edate);
//再看LdbKey的处理

       LdbKey(const char* key_data, int32_t key_size, int32_t bucket_number, uint32_t expired_time = 0) :
          data_(NULL), data_size_(0), alloc_(false)
        {
          set(key_data, key_size, bucket_number, expired_time);
        }

        inline void set(const char* key_data, int32_t key_size, int32_t bucket_number, uint32_t expired_time)
        {
          if (key_data != NULL && key_size > 0)
          {
            free();
            data_size_ = key_size + LDB_KEY_META_SIZE;
            data_ = new char[data_size_];
            build_key_meta(data_, bucket_number, expired_time);
            memcpy(data_ + LDB_KEY_META_SIZE, key_data, key_size);
            alloc_ = true;
          }
        }

        static void build_key_meta(char* buf, int32_t bucket_number, uint32_t expired_time = 0)
        {
          encode_fixed32(buf, expired_time);
          encode_bucket_number(buf + LDB_EXPIRED_TIME_SIZE, bucket_number);
        }

        static void encode_bucket_number(char* buf, int bucket_number)
        {
          for (int i = 0; i < LDB_KEY_BUCKET_NUM_SIZE; ++i)//LDB_KEY_BUCKET_NUM_SIZE = 3 
          {
            buf[LDB_KEY_BUCKET_NUM_SIZE - i - 1] = (bucket_number >> (i*8)) & 0xFF;
          }
        }

从代码可以看出,这次再往key的前面分别编码了4字节的expired_time和3字节的bucket_no,到此时整个可以的组成就变成了

expire(4B) | bucket_no(3B) | area (2B) | user_key

再往下可以看到会有db_version_care_和put的version_care的判断,这里不进行详细的描述,主要功能是如果设置的db_version_care_那么每次put的时候需要先查询是否已经有插入过数据将其取出来,在后在根据本次插入的version_care判断本次插入传入的version是否和当前数据库中存储的version是否相等,如果不等则本次插入失败,如果相等则可以插入(更新),并且将改key的version加1,进行完相应的这些设置以后就可以把对应的KV对插入leveldb中了。这里需要说明的是在tair的存储引擎中实现了一种纯内存存储的memdb,而tair的leveldb也对此进行了一些修改增加了一个db_cache的概念,这里你就可以选择将memdb作为leveldb的一个cache以加快查询的速度。

到此我们就将重新组装后的KV对插入到leveldb中了,然而你有没有发现有何问题呢?对,就是这里的key是以expire开头的,而我们回忆leveldb内部默认使用的Comparator是BytewiseComparator,如果是使用率这个Comparator的话leveldb内部就将首先按照expire的时间来排序。从数据过期的处理来说,按expire排序那么我们就可以很容易的将expire的key排出掉,但是我们知道leveldb是会进行迁移的,当我们需要将一个area或者一个bucket的数据迁移到另外的机器上时那么我们岂不是要扫描整个数据库?二期查找的时候我如何能够确定这个key的过期时间呢?如果不能确定就不能获取到相应的值了。别担心,我们的leveldb不是有Comparator这个东西么,使用默认的BytewiseComparator不能达到要求,那么tair自己实现了一个Comparator叫做LdbComparator的东西来满足我们的需要。我们看看其Compare的代码

int LdbComparatorImpl::Compare(const leveldb::Slice& a, const leveldb::Slice& b) const
      {    // LDB_COMPARE_SKIP_SIZE = LDB_EXPIRED_TIME_SIZE = sizeof(uint32_t); 
        assert(a.size() > LDB_COMPARE_SKIP_SIZE && b.size() > LDB_COMPARE_SKIP_SIZE);
        const int min_len = (a.size() < b.size()) ? a.size() - LDB_COMPARE_SKIP_SIZE :
          b.size() - LDB_COMPARE_SKIP_SIZE;
        int r = memcmp(a.data() + LDB_COMPARE_SKIP_SIZE, b.data() + LDB_COMPARE_SKIP_SIZE, min_len);
        if (r == 0)
        {
          if (a.size() < b.size())
          {
            r = -1;
          }
          else if (a.size() > b.size())
          {
            r = +1;
          }
        }
        return r;
      }

这里compare的时候首先跳过了4个字节再进行memcmp,而我们知道4个字节正是expire的长度。

所以我们最终得出的结论是tair在使用leveldb时对key进行了重构,传入重构后的key结构为

expire(4B) | bucket_no(3B) | area (2B) | user_key

而又使用了自己实现的Comparator跳过开始的expire4个字节,这样最后就得到了整个leveldb中存储的数据就先以bucket_no排序,然后是area,最后才是安装user_key,经过这样的处理后我们以bucket进行迁移时就只需安装bucket_no生成对应的区间扫描的key就可以了。

 

本文介绍leveldb的key存储结构,希望以此为起点理清tair内部存储然后再以此为脉络进一步分析tair的实现。

tair源码分析——leveldb存储引擎使用,布布扣,bubuko.com

tair源码分析——leveldb存储引擎使用

标签:style   blog   color   使用   数据   io   for   问题   

原文地址:http://www.cnblogs.com/KevinT/p/3871594.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!