zhangjiaqiao / 2019-dbms-project Goto Github PK

TA你好，有关主要数据文件

1. LeafGroup结构：| usedNum(8 bytes) | bitmap(n bytes) | Leaf1 | ... | leafN |
2. catelog：| maxFileId(8 bytes) | freeNum(8 bytes) | treeStartLeaf(PPointer) |
3. freeList：| (fId, offset)1, ..., (fId)N |
   可不可以每种给出一个样例文件，不然不知道该如何读取以及写入数据

另外，关于一个叶子，怎么判断是free还是used，是不是只有遍历freeList才可以

因此 fp_tree_test.cpp 这里有误

查资料时发现有个Apriori算法和PFtree有关，但是看论文这个好像又和Apriori没什么关系，所以不知道和Apriori有关的那个tree是不是就是我们要用到的这个FPTree呢？

在我们的测试当中，加载效率比levelDB高4倍，但是运行效率慢4倍。（之前更惨，100倍）
我刚才采样检测了程序，发现占用程序时间的是keyHash()函数。
将LeafNode::find()里面关于fingerprint的比较相关代码注释掉之后效率比levelDB高1倍。

请问我们应该去除指纹机制，还是改掉哈希函数，还是其他方法？

ta您好，我想问一下这个initFilePmemAddr()是要将freelist里面的节点的fileid与pmem_addr放入map()中吗

README可以在后续中进一步补充完善吗？

如果一个leafGroup代表一个文件的话, 那么p_allocator.cpp中的newLeafGroup()分配一个新的leafGroup, 也就是说新文件该怎么命名呢?

那个maxfield在readme里面说是记录分配文件的最大标号，那么是分配一个文件就加一还是一开始建立树的时候就确定了多大(但是这样数据大量存储肯定就有限制，所以感觉是第一种)，但是在注释里面又说它是当前没有被使用的fileID，所以是不是又得理解成剩余还有多少空间可分配的意思？

TA你好
workloads里面的数据格式都是
INSERT 1234567891234567891
这种格式，请问哪个是key，哪个是value

我的理解的话，是leafnode的最大degree是utility.h定义的LEAF_DEGREE，innernode的最大的degree也是定义好的INNER_DEGREE
如果是这样理解的话，那leafnode和innernode定义的成员变量degree是用来干嘛的，fptree的degree是什么作用。
如果不这样理解的话，那leafnode和innernode定义的degree就是最大degree。那要怎么获得degree，fptree类的degree是私有变量，又没有接口方法获得fptree的degree

INSERT 6284781860667377211
ycsb测试的条目的键值都为8字节，是指将6284781860667377211视为一个uint64_t，键和值都为这个8字节的值，还是截取前8个数字如62847818作为键和值的值？

请问fptree的期望性能有多高？
我使用ycsb同样的代码测试leveldb和fptree，发现在load阶段fptree比leveldb慢了一倍，在run阶段两者性能差不多

在我们的实现中,每次修改叶子后都会立即调用LeafNode::persist，我们每次都判断叶子是否是pmem地址，若是则用pmem_persist持久化，如不是则用pmme_msync持久化，其实现代码为：

void LeafNode::persist() {
    if (pmem_is_pmem(this->pmem_addr, calLeafSize())) {
        pmem_persist(this->pmem_addr, calLeafSize());
    } else {
        pmem_msync(this->pmem_addr, calLeafSize());
    }
}

ta您好，想问一下插入的第一个节点是根节点还是叶子节点还是两者都是

在fptree_test.cpp中

TEST(FPTreeTest, SingleInsert) {
    FPTree* tree = new FPTree(2);
    tree->insert(1, 100);
    LeafNode* leaf = (LeafNode*)(tree->getRoot()->getChild(0));
    EXPECT_NE(nullptr, leaf);
    if (!leaf) {
        return;
    }
    EXPECT_EQ(leaf->find(1), 100);
    EXPECT_EQ(leaf->getPPointer().fileId, 1);
    EXPECT_EQ(leaf->getPPointer().offset, LEAF_GROUP_HEAD + calLeafSize() * (LEAF_GROUP_AMOUNT - 1));
    LeafNode* t_leaf = new LeafNode(leaf->getPPointer(), NULL);
    EXPECT_EQ(t_leaf->getBit(0), 1);
    EXPECT_EQ(t_leaf->find(1), 100);
    removeFile();
}

为什么TA用

    EXPECT_NE(nullptr, leaf);
    if (!leaf) {
        return;
    }

而不是用

ASSERT_NE(nullptr,leaf);

我想问下这样写的好处是什么，

(没错，我就是杠精

简单讲解下开发的系统是什么，每阶段实现了什么，如何使用等。这个自由发挥，后续内容按阶段补充，目的是让第三方可以看得到你们做的是什么

LeafGroup结构：| usedNum(8 bytes) | bitmap(n bytes) | Leaf1 | ... | leafN |
catelog：| maxFileId(8 bytes) | freeNum(8 bytes) | treeStartLeaf(PPointer) |
freeList：| (fId, offset)1, ..., (fId)N |

三个文件都是定长的话, leafGroup前面两个是8字节+16字节, 后面的从Leaf1到LeafN的大小该怎么确定呢? freeList的文件大小该怎么确定?(有点头秃)
从文件映射到虚拟地址时flag用 PMEM_FILE_CREATE 可以映射已经存在的文件吗?

网上的一些博客里都写到了，直接在pcsb根目录下使用./ycsb leveldb run -P.... 类似的指令来完成ycsb测试。但是当使用./ycsb shell leveldb进入命令行时，没有对输入的批量insert，只能一个一个插入key。所以这个cpp是专门为了对输入数据进行批量操作，我们只需要将测试文件读入，比如：10w-rw-50-50-load.txt文件，然后就能实现这数据的插入了，学长我理解的对吗？
17343065

1.根据伪代码貌似是寻找中间键，之后完全移动源页的数据，这个做法感觉有点怪，是否是正确的？
2.但是注释中的寻找中间键的过程中提示删除左侧的内容，此时按照伪代码流程，数据还未被复制，直接删除不是就会丢失数据吗？这个是不是注释有误，把split的任务安排在findSplitKey中了？

/usr/bin/ld: /tmp/ccB0tH2v.o: in function main': lycsb.cpp:(.text+0x26): undefined reference to leveldb::Options::Options()'
/usr/bin/ld: lycsb.cpp:(.text+0x8f): undefined reference to `leveldb::DB::Open(leveldb::Options const&, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, leveldb::DB**)'
collect2: error: ld returned 1 exit status

求问是否需要增加特殊的编译指令？

请问应该如何模拟crash?

论文里提到叶子的头部（即bitmap+pNext+fingerprints）部分的大小应该设置为一个cache-line大小，而当前主流CPU的cache-line大小都是64byte，那么叶子的度应该设置为26（4byte bitmap + 8byte pNext + 26 * 2byte fingerprints = 64byte）才能取得最佳性能。
而fptree框架的默认叶子的度的大小为56，这不是论文提及的最优值，是否应在最终实现时把叶子的默认的度改回26（测试代码不兼容）。

叶子的默认的度的大小设为56有什么额外的考虑吗？

我把叶子的度的大小改为26后，运行ycsb的220w测试，整体性能相比叶子的度的大小为56时提升了10%到20%