AI智能摘要
你是否好奇,一款高性能数据库是如何在速度与安全之间找到完美平衡的?TcaplusDB 的存储分配策略揭秘来了!本文通过清晰图解,深入剖析其如何高效利用内存与磁盘空间:前1G空间优先映射内存提升访问速度,Key数据集中存放优化遍历性能,Best-Fit算法减少碎片。更关键的是,它如何通过先写Value、再写Key的顺序,保障数据一致性?一张图拆解完整分配流程,带你读懂背后的设计逻辑。
— AI 生成的文章内容摘要
前言
保存数据的方法多种多样,最直接的方法是在内存中建一个数据结构,保存数据。比如用一个List,每当收到一条数据就向List中追加一条记录。
这个方案非常简单,性能良好,但问题是数据存放在内存中,一旦服务器停机或重启,数据就会永久丢失。
为了解决数据丢失问题,可以把数据持久化存放在非易失存储介质(比如硬盘)中。可以使用磁盘的文件,每当收到一条数据就向文件中 Append 一行。这是一个持久化存储数据的解决方案,但如果磁盘损坏呢? RAID是一个单机冗余存储方案,那如果主机损坏呢?
网络存储是一个解决方案,通过软件层进行存储副本的复制。似乎我们可以解决数据安全问题,但是做存储副本复制过程中是否能保证副本之间的一致性?
TcaplusDB的开发人员考虑到了这些存储问题,在本期的知识库中,TcaplusDB君将介绍TcaplusDB的存储分配策略,关于数据的读写逻辑我们将会在下期的知识库中进行介绍。
存储空间分配的基本策略
- TcaplusDB优先使用数据文件的前1G的空间。原因是存储引擎启动时,会将数据文件的前1G空间通过mmap映射到内存中,访问效率较高,而剩余的空间中数据是直接对接文件IO的方式访问的;
- 数据的Key比数据的Value更有权利优先使用前1G的空间。原因是通常情况下Key的访问频率要比Value高。当前1G空间中原先分配给Key使用的空闲块不足时,会将前1G空间中原先分配给Value使用的空闲块挪给Key使用;
- 所有数据的Key尽量存放在一起。这是因为我们有很多Key遍历的场景(比如数据迁移),Key放在一起,可以一定程度上加快遍历的过程,减少磁盘IO;
- 空闲块的查找策略为Best-Fit,即找满足需求的最小空闲块,目的是为了尽可能的让数据存在同一块中,避免数据的Split。
存储空间的详细分配过程参见下图(下图拆分成了两个部分,两幅图通过虚线框的”尝试从文件空间分配“节点联系在一起):
![[TcaplusDB知识库]TcaplusDB的存储分配策略图解-图片1](https://www.it2021.com/wp-content/themes/begin/img/loading.png)
存储空间详细分配过程图
![[TcaplusDB知识库]TcaplusDB的存储分配策略图解-图片2](https://www.it2021.com/wp-content/themes/begin/img/loading.png)
从文件空间中分配图
策略设计的考虑
存储引擎根据空间分配策略,会先分配数据Value的存储空间,写入数据Value部分后,再分配数据Key的存储空间,并写入数据Key部分。之所以是这样的顺序,有两方面的原因:
- 数据Key的头部需要记录它所指向的Value的存储地址,需要先分配Value的存储空间,得到Value的存储地址头,再写Key;
- 数据访问入口是Key,按照这个顺序,Key写成功,我们也基本可以认为Value也是写成功了,可以减少数据不一致的情况。
最后
我们已经了解了 TcaplusDB 的存储分配策略,后续我们将揭开更多TcaplusDB设计的特殊奥秘。

浙江省 1F
这策略挺靠谱的。
广东省广州市 2F
感觉还行。
广东省东莞市 B1
@ 墨绿幽影 还行的话,后面如果有更多细节会更有价值。
江苏省常州市 3F
前1G空间满了会自动切到后面的文件吗?这会不会影响写入性能?
河南省郑州市 4F
我之前在用别家DB,Key分散导致遍历慢,这策略倒是省心。
重庆市 5F
这图真是看得眼花。
日本 B1
@ 暴躁的火山 图里层层判断确实密集,建议先抓关键路径再细看。
北京市 6F
Best-Fit的空闲块查找其实会产生碎片,建议定期做空间整理。
印度尼西亚 B1
@ 哗哗啦 的确,定期整理能把碎片压平,保持命中率。
浙江省 7F
看完图后感觉作者把每一步都写得很细致,尤其是热点Key的处理,感觉像在玩高阶的资源调度游戏,真是让人想多了解下内部实现细节。
福建省宁德市 8F
说的没错,Key优先也可能导致Value被挤压。
韩国 9F
那如果Key特别大,是不是会直接走SSD路径?有没有对应的性能数据?
印度 10F
TcaplusDB真不错,👍。
山东省淄博市 11F
这个Key优先的思路挺实在的。
上海市青浦区 12F
前1G映射到内存,读写速度确实能提升不少,尤其是频繁查询的Key。
日本 13F
看到Best-Fit配合Key聚集的设计,感觉整体性能调优很到位,尤其是遍历时的IO减少,期待后面Value的处理细节。
江西省九江市 14F
其实空闲块也可以先合并再分配,减少碎片。
印度尼西亚 15F
热点Key的判定阈值是多少?
福建省厦门市 16F
如果Key非常大,会不会直接走SSD,性能会不会下降?
内蒙古呼和浩特市 17F
说碎片会严重,其实Best-Fit本身已经控制得不错。
澳大利亚 18F
之前用过某DB,遍历慢得要命,这种Key聚集真的提升不少。
湖南省郴州市 19F
Value先写这个顺序挺巧妙的。
北京市 20F
前段时间我们项目里碰到磁盘IO瓶颈,改用TcaplusDB后Key聚集让迁移速度提升了近两倍。
越南 21F
Best-Fit这个策略挺细的。
台湾省新竹市 22F
图里那层层判断,眼睛都要跟着跑。
湖北省武汉市 23F
看到热Key的处理,感觉像玩策略游戏。
北京市 24F
Key优先放一起这思路有点意思。
广东省佛山市 B1
@ 清歌浅唱 是吧,感觉对提升性能挺关键的
北京市 25F
图里标的‘是否为热点Key’,好像在说:我就是那个被频繁访问的明星Key。
广东省汕头市 26F
Key和Value分配顺序这个细节挺讲究的。
湖北省武汉市 27F
整体思路清晰。
四川省内江市 28F
Best-Fit这个策略选得挺巧的。