Rethink the path to build storage #14
wangrunji0408
started this conversation in
Ideas
Replies: 1 comment
-
资瓷.jpg storage 部分的难点就是要写完很多东西以后才可以真正跑起来,因此如果只着眼于单个项目自底向上设计的话,写起来会比较难过。 如果是根据 "why design" 这篇文档来设计,可能就更符合人的一般认知了。#13 那么我们从第一步开始就能跑一个端到端的引擎(直接把 Block / Data Chunk 刷到盘上),然后加入 Column 以后把 column 刷到盘上,加入 RowSet 之后把 RowSet 刷到盘上,etc. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
我大致浏览了一下 @skyzh 对 World3 存储部分的代码设计(#9 #11 #12),有一些新的想法。
目前的实现路径是:01-memtable,02-block,03-column,04-rowset。到这里的代码量大约是 1500 行,但是还没有形成一个端到端可用的磁盘存储引擎,所以在 sqllogictest 中没有办法测试这部分代码。这样的话就有点偏离 tutorial 最初设想的由 e2e 测试驱动开发的方式了。
我觉得最理想的实现路径是每一步的效果都能在端到端测试中体现出来,这样任务目标很明确,同时也便于量化同学们的实现进展。对于存储这部分来说,我觉得第一步应该以最快的方式实现数据落盘。具体的存储格式先不关心,比如可以直接用 serde 去序列化 Array 和 DataChunk,每个 DataChunk 存成一个文件,只要能够写下去并读上来即可。在 e2e 测试中,我们可以在任意两个语句之间重启整个数据库,来测试是否正确实现了数据持久化。这样我估计能在 100 行左右的规模下实现一个最最简单的磁盘存储引擎。
第二步可以引入 memtable 作为写缓存,同时在读的一侧实现 iterator 来隐藏不同的数据源。这样体现到 e2e 测试中就是让 insert 和 select 更快一些(?
按照这个思路,第三步可以支持 delete,第四步为了优化 delete 实现 compaction……在此过程中再根据需要细化存储结构,逐步引入 rowset/column/block/index 等。具体步骤我还没想清楚,但总的来说是想做出一种 由需求驱动结构演化 的效果,这样同学们就能更好地理解每一个设计背后的原因了。
以上是我的一些脑洞,欢迎讨论!
Beta Was this translation helpful? Give feedback.
All reactions