CMU数据库（15-445）实验2-B+树索引实现(下+课上笔记)

时间  2021-01-27
标签 node c++ git github 算法 数据库 编程 安全 多线程 并发 栏目 SQL 繁體版
原文   原文链接

4. Index_Iterator实现

这里就是须要实现迭代器的一些操做,好比begin、end、isend等等node

下面是对于IndexIterator的构造函数c++

template <typename KeyType, typename ValueType, typename KeyComparator>
IndexIterator<KeyType, ValueType, KeyComparator>::
IndexIterator(BPlusTreeLeafPage<KeyType, ValueType, KeyComparator> *leaf,
              int index_, BufferPoolManager *buff_pool_manager):
    leaf_(leaf), index_(index_), buff_pool_manager_(buff_pool_manager) {}

1. 首先咱们来看begin函数的实现

  1. 利用key值找到叶子结点
  2. 而后获取当前key值的index就是begin的位置
INDEX_TEMPLATE_ARGUMENTS
INDEXITERATOR_TYPE BPLUSTREE_TYPE::Begin(const KeyType &key) {
  auto leaf = reinterpret_cast<BPlusTreeLeafPage<KeyType, ValueType,KeyComparator> *>(FindLeafPage(key, false));
  int index = 0;
  if (leaf != nullptr) {
    index = leaf->KeyIndex(key, comparator_);
  }
  return IndexIterator<KeyType, ValueType, KeyComparator>(leaf, index, buffer_pool_manager_);
}

2. end函数的实现

  1. 找到最开始的结点
  2. 而后一直向后遍历直到nextPageId=-1结束
  3. 这里注意须要重载!=和==

end函数git

INDEX_TEMPLATE_ARGUMENTS
INDEXITERATOR_TYPE BPLUSTREE_TYPE::end() {
  KeyType key{};
  auto leaf= reinterpret_cast<BPlusTreeLeafPage<KeyType, ValueType,KeyComparator> *>( FindLeafPage(key, true));
  page_id_t new_page;
  while(leaf->GetNextPageId()!=INVALID_PAGE_ID){
    new_page=leaf->GetNextPageId();
    leaf=reinterpret_cast<BPlusTreeLeafPage<KeyType, ValueType,KeyComparator> *>(buffer_pool_manager_->FetchPage(new_page));
  }
  buffer_pool_manager_->UnpinPage(new_page,false);
  return IndexIterator<KeyType, ValueType, KeyComparator>(leaf, leaf->GetSize(), buffer_pool_manager_);
}

==和 !=函数github

bool operator==(const IndexIterator &itr) const {
  return this->index_==itr.index_&&this->leaf_==itr.leaf_;
}

bool operator!=(const IndexIterator &itr) const {
  return !this->operator==(itr);
}

3. 重载++和*(解引用符号)

  1. 重载++

简单的index++而后设置nextPageId便可算法

template <typename KeyType, typename ValueType, typename KeyComparator>
IndexIterator<KeyType, ValueType, KeyComparator> &IndexIterator<KeyType, ValueType, KeyComparator>::
operator++() {
//
 // std::cout<<"++"<<std::endl;
  ++index_;
  if (index_ == leaf_->GetSize() && leaf_->GetNextPageId() != INVALID_PAGE_ID) {
    // first unpin leaf_, then get the next leaf
    page_id_t next_page_id = leaf_->GetNextPageId();

    auto *page = buff_pool_manager_->FetchPage(next_page_id);
    if (page == nullptr) {
      throw Exception("all page are pinned while IndexIterator(operator++)");
    }
    // first acquire next page, then release previous page
    page->RLatch();

    buff_pool_manager_->FetchPage(leaf_->GetPageId())->RUnlatch();
    buff_pool_manager_->UnpinPage(leaf_->GetPageId(), false);
    buff_pool_manager_->UnpinPage(leaf_->GetPageId(), false);

    auto next_leaf =reinterpret_cast<BPlusTreeLeafPage<KeyType, ValueType,KeyComparator> *>(page->GetData());
    assert(next_leaf->IsLeafPage());
    index_ = 0;
    leaf_ = next_leaf;
  }
  return *this;
};
  1. 重载*

return array[index]便可数据库

template <typename KeyType, typename ValueType, typename KeyComparator>
const MappingType &IndexIterator<KeyType, ValueType, KeyComparator>::
operator*() {
  if (isEnd()) {
    throw "IndexIterator: out of range";
  }
  return leaf_->GetItem(index_);
}

5. 并发机制的实现

0. 首先复习一下读写🔒机制

  1. 读操做是能够多个进程之间共享latch的而写操做则必须互斥
  2. 加入MaxReader数就是为了防止等待的⌛️写进程饥饿

首先来看若是没有🔒机制多线程会发生什么问题编程

  1. 线程T1想要删除44。
  2. 线程T2 想要查找41
image-20210126184533688
  1. 假设T2在执行到D位置的时候又切换到线程T1
  2. 这个时候T1进行从新分配，会把41借到I结点上
  3. T1执行完成切换回T2这时候T2再去原来的执行寻找41就会找不到
image-20210126184727498

就会出现下面的状况。❓安全

image-20210126184901306

由此咱们须要读写🔒的存在多线程

  1. 对于find操做

因为咱们是只读操做，因此咱们到下一个结点的时候就能够释放上一个结点的Latch并发

image-20210126185917549

剩下的操做都是同样的

  1. 对于delete则不同

由于咱们须要写操做

这里咱们不能释放结点A的Latch。由于咱们的删除操做可能会合并根节点。

image-20210126190112632

到D的时候。咱们会发现D中的38删除以后不须要进行合并，因此对于A和B的写Write是能够安全释放了

image-20210126190229333
  1. 对于Insert操做

这里咱们就能够安全的释放掉A的锁。由于B中还有空位，咱们插入是不会对A形成影响的

image-20210126190452937

当咱们执行到D这里发现D中已经满了。因此此时咱们不会释放B的锁，由于咱们会对B进行写操做

image-20210126190613339

上面的算法虽然是正确的可是有瓶颈问题。因为只有一个线程能够得到写Latch。而插入和删除的时候都须要对头结点加写Latch。因此多线程在有许多个插入或者删除操做的时候，性能就会大打折扣

这里要引入乐观🔒

乐观的假设大部分操做是不须要进行合并和分裂的。所以在咱们向下的时候都是读Latch而不是写Latch。只有在叶子结点才是write Latch

  1. 从上到下都是读Latch。并且逐步释放
  2. 到叶子结点须要修改的时候才为写Latch。这个删除是安全的因此直接结束
image-20210126192408392
  1. 当咱们到最后一步发现不安全的时候。则须要像上面咱们没有引入乐观🔒的时候同样。从新执行一遍
image-20210126192548748

B-Link Tree简介

延迟更新父结点

这里用一个🌟来标记这里须要被更新可是尚未执行

image-20210126195848104

这个时候咱们执行其余操做也是正确的好比查找31

image-20210126200003320

这里咱们执行insert 33

当执行到结点C的时候。由于这个时候有另外一个线程持有了write Latch。因此这个时候🌟操做要执行。随后在插入33

image-20210126200239782

最后一点补充关于扫描操做的

  1. 线程1在C结点上持有write Latch
  2. 线程2已经扫描完告终点B想要得到结点C的read Latch

这时候会发生问题，由于线程2没法拿到read Latch

这里有几种解决方法

  1. 能够等到T1的写操做完成
  2. 能够从新执行T2
  3. 能够直接让线程T2中止抢得这个Latch。

注意这里的Latch和Lock并不同

img

1. 辅助函数UnlockUnpinPages的实现

  1. 若是是读操做则释放read锁
  2. 不然释放write锁
INDEX_TEMPLATE_ARGUMENTS
void BPLUSTREE_TYPE::
UnlockUnpinPages(Operation op, Transaction *transaction) {
  if (transaction == nullptr) {
    return;
  }

  for (auto page:*transaction->GetPageSet()) {
    if (op == Operation::READ) {
      page->RUnlatch();
      buffer_pool_manager_->UnpinPage(page->GetPageId(), false);
    } else {
      page->WUnlatch();
      buffer_pool_manager_->UnpinPage(page->GetPageId(), true);
    }
  }
  transaction->GetPageSet()->clear();

  for (const auto &page_id: *transaction->GetDeletedPageSet()) {
    buffer_pool_manager_->DeletePage(page_id);
  }
  transaction->GetDeletedPageSet()->clear();

  // if root is locked, unlock it

  node_mutex_.unlock();
  }

四个自带的解锁和上锁操做

/** Acquire the page write latch. */
inline void WLatch() { rwlatch_.WLock(); }

/** Release the page write latch. */
inline void WUnlatch() { rwlatch_.WUnlock(); }

/** Acquire the page read latch. */
inline void RLatch() { rwlatch_.RLock(); }

/** Release the page read latch. */
inline void RUnlatch() { rwlatch_.RUnlock(); }

这里的rwlatch是本身实现的读写锁类下面来探究一下这个类

因为c++ 并发编程我如今还不太会。。。因此就简单看一下啦后面学完并发编程再补充

  1. WLock函数

    1. 首先获取一个锁
    2. 用一个记号writer_entered表示是否有写操做
    3. 若是以前已经有了如今的操做就须要等(这个线程处于阻塞状态)
    4. 当前若是有其余线程执行读操做。则仍须要阻塞(别人读的时候你不能写)
    void WLock() {
  std::unique_lock<mutex_t> latch(mutex_);
  while (writer_entered_) {
    reader_.wait(latch);
  }
  writer_entered_ = true;
  while (reader_count_ > 0) {
    writer_.wait(latch);
  }
}

  2. WunLock函数

    1. 写标记置为false
    2. 而后通知全部的线程
    void WUnlock() {
  std::lock_guard<mutex_t> guard(mutex_);
  writer_entered_ = false;
  reader_.notify_all();
}

  3. RLock函数

    1. 若是当前有人在写或者已经有最多的人读了则阻塞
    2. 不然只须要让读的计数++

    由于是容许多个线程一块儿读这样并不会出错

    void RLock() {
  std::unique_lock<mutex_t> latch(mutex_);
  while (writer_entered_ || reader_count_ == MAX_READERS) {
    reader_.wait(latch);
  }
  reader_count_++;
}

  4. RUnLatch函数

    1. 计数--
    2. 若是当前有人在写而且无人读的话须要通知全部其余线程
    3. 若是在计数--以前达到了最大读数，释放这个锁以后须要通知其余线程，如今又能够读了。
    void RUnlock() {
  std::lock_guard<mutex_t> guard(mutex_);
  reader_count_--;
  if (writer_entered_) {
    if (reader_count_ == 0) {
      writer_.notify_one();
    }
  } else {
    if (reader_count_ == MAX_READERS - 1) {
      reader_.notify_one();
    }
  }
}

6. Summary

好了终于磕磕绊绊的写完了Lab2.关于数据库的Lab2应该会停一段时间。这段时间要补一补深度学习（毕竟要毕业）而后赶工一下老师给的活。同时学一下c++并发编程和看一下侯捷老师的课程。

最后附上GitHub的🔗
https://github.com/JayL-zxl/CMU15-445Lab

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程