看图了解RocksDB
它是一个高性能的Key-Value数据库。设计了完善的持久化机制,同时保证性能和安全性。能够良好的支持范围查询,因为K-V记录就是按照Key来排序的。
下图为写入的流程:
可以看到主要的三个组成部分,内存结构memtable,类似事务日志角色的WAL文件,持久化的SST文件。
数据会放到内存结构memtable,一定条件下触发写到到SST文件。写入WAL文件是可选的,用来恢复未写入到磁盘的memtable。
下图展示了读取的层次:
memtable和SST文件组成数据的全集。之上是缓存层,缓存为提升查询性能做了分片,底层都采用hash查询,不同缓存结构的区别在于热点数据的替换逻辑。访问数据库时,都是访问的打开时间点的view(我猜测一个key有不同时间戳的多条记录)。除了直接查询db,还提供了查询快照的机制。直接访问db时,会持有文件句柄,这样多个SST文件合并时,已经被合并但被访问的文件就不能被删除。而快照机制保证了访问过程中文件能被删除(我并未想明白如何做到的),不过打开期间被删除的key的记录还会在新合并的文件里存在。
memtable的结构有几种可选,本质都是排序的结构(为了支持范围查询)
其中之一是上图的跳跃表,不了解跳跃表机制的读者可以简单理解为有序支持近似二分查找的时间复杂度为log2(N)的结构
另外一种是hash结合跳跃表,是按照key的前缀做hash,单独访问一个key时性能更好,范围查询性能会差些
WAL文件结构如下图,按照写入的顺序来存储变长的K-V,按照固定长度来分组存储(可能一个K-V跨多个分组)的目的是便于读取
支持几种SST文件结构
上图为按照多块来存储的结构。每块的K-V都是有序的,而多块也是有序的。文件中包含元数据相关的信息,包括数据压缩字典、过滤器等。会按照数据块所属的K-V范围来创建索引,为提升查询性能会给索引分片。
另外一种结构是每个K-V来存储。它的索引比较特殊,由hash结构和二进制查找缓存两部分组成。依然按照key的前缀做hash,如果桶对应的K-V记录很少,则直接指向第一个key(有多个key属于该桶)的记录位置。如果属于桶的K-V记录多于16条,或者包含多于一个前缀的记录,则先指向二进制查找缓存(先二分查找),而后指向第一个key的记录位置。
随着K-V的写入,会生成很多的SST文件,这部分文件需要被合并到一起。从而降低打开文件数量,并且移除已经不存在的记录。通常可以配置两种方式,通用合并(下图左侧)与level合并(右侧)。
其中一个概念是level,可以简单理解成越老的数据在越高的level(也就是数据最初写入到最低的level,level0就是memtable)。
我将通用合并简单理解为一种简单粗暴的合并,可以尽量降低写磁盘的压力,会增大读取的压力,临时空间占用大。
一般多采用level合并的方式。每个level都有max大小,超出后会触发本level与下一level的文件合并到一起。不同level的合并是可以并发执行的。
对rocksdb做个总结。所有记录在业务上是有序的,对key的查询其实会执行类似二分查找。持久化是通过写入有序文件来实现的。高性能的写入是通过先写入内存结构来保证的(写满的内存结构刷到持久化文件)。提供了level机制对数据做分层,优先查询最新写入的level来优化查询性能。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Docker下使用selenium+testng实现web自动化
Windows下selenium+testng的web自动化环境搭建 做过自动化的人,肯定对selenium web环境的搭建非常熟悉了,特别是selenium在java中的使用。 先搭建好安装好JDK,配置好java开发环境(这个如果还是不知怎么操作的话可是要打PP了)。然后从官网下载对应selenium的jar包,加载到项目里;或者是使用maven,修改pom.xml文件直接加载selenium的依赖包即可: 1 <dependency> 2 <groupId>org.seleniumhq.selenium</groupId> 3 <artifactId>selenium-java</artifactId> 4 <version>3.14.0</version> 5 </dependency> 接着加上对应的浏览器驱动文件,就基本搞定环境了,可以开始自动化测试代码之路了。 当然大家在编写代码的过程中也会用到现在流行的单元测试框架testng。如何在这基础上增加test...
- 下一篇
Android 界面性能调优渲染+To检测+OverDraw+Rendering
界面是 Android 应用中直接影响用户体验最关键的部分。如果代码实现得不好,界面容易发生卡顿且导致应用占用大量内存。做 ROM 的公司更不一样,预装的应用一定要非常流畅,这样给客户或用户的第一感觉就是快。又卡又慢的应用体验,会影响客户或用户对产品的信心和评价,所以不可忽视。 一. 界面Android渲染 1.1 绘制原理 Android系统要求每一帧都要在 16ms 内绘制完成,平滑的完成一帧意味着任何特殊的帧需要执行所有的渲染代码(包括 framework 发送给 GPU 和 CPU 绘制到缓冲区的命令)都要在 16ms 内完成,保持流畅的体验。这个速度允许系统在动画和输入事件的过程中以约 60 帧每秒( 1秒 / 0.016帧每秒 = 62.5帧/秒 )的平滑帧率来渲染。 如果你的应用没有在 16ms 内完成这一帧的绘制,假设你花了 24ms 来绘制这一帧,那么就会出现掉帧的情况。 系统准备将新的一帧绘制到屏幕上,但是这一帧并没有准备好,所有就不会有绘制操作,画面也就不会刷新。反馈到用户身上,就是用户盯着同一张图看了 32ms 而不是 16ms ,也就是说掉帧发生了。 1.2 ...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Linux系统CentOS6、CentOS7手动修改IP地址
- Docker安装Oracle12C,快速搭建Oracle学习环境
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS7安装Docker,走上虚拟化容器引擎之路
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- 设置Eclipse缩进为4个空格,增强代码规范
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- 2048小游戏-低调大师作品