写点什么

闪存将改变数据库存储引擎的设计

  • 2014-09-11
  • 本文字数:1765 字

    阅读完需:约 6 分钟

过去十年,固态硬盘(俗称闪存)已经从根本上改变了计算机信息处理技术。在客户端,U 盘取代了 CD;在服务器端,它有高于 RAM 和磁盘驱动器的性价比。但在过去的几年里,数据库才刚刚开始赶上这一趋势,而且大部分仍然依赖于针对旋转磁盘内部数据结构和存储管理的优化来提升性能。

近日, O’Reilly Media 资深编辑 Andy Oram 发表了一篇文章,他基于对数位数据库专家的采访,详细介绍了闪存如何改变了数据库存储引擎的设计,其中包括 Aerospike、Cassandra、FoundationDB、RethinkDB 和 Tokutek 的代表人物。对于正在设计应用程序和寻找最佳存储方案的读者而言,他们给出的各种方法会有一定的指导意义。

根据介绍,闪存影响数据库存储引擎设计的关键特性如下:

  • 随机读:闪存不同于传统磁盘,它像内存一样,不管两次读的物理距离相差多远,它都可以以同样的速度提供数据。不过,它每次会读取整个块,所以,应用程序可能仍然会受益于访问局部性。比如,如果本次读与上次读的位置相近,那么本次操作可能可以直接从内存或者缓存读取数据。
  • 吞吐量:有记录的原始吞吐量已达到每秒几十万次的读 / 写,这比磁盘高两个数量级,甚至更高。而且,随着磁盘密度的提高,吞吐量还在增长。
  • 延时:据 FoundationDB CEO David Rosenthal 说,通常,闪存的读延时大约为 50 到 100 微秒。而 RethinkDB CEO Slava Akhmechetat 指出,闪存至少比磁盘快 100 倍。不过,闪存的延时已经达到了极限。
  • 并行:闪存驱动器提供多个控制器或者单个性能更高的控制器。这对于能够使用多个线程和内核的数据库设计大有裨益,它可以将工作负载划分成许多独立的读写操作。

那么,这些特性对数据库存储引擎的设计有什么影响呢?为了说明这个问题, Oram 介绍了一些企业的现行做法。

Aerospike 是第一款从设计之初就选择了闪存的数据库产品。它将索引存储在 RAM 中,其它数据存储在闪存中。这样,他们可以在 RAM 中快速查找索引,然后从多个闪存驱动器中并行检索数据。由于索引在 RAM 中更新,向闪存写数据的次数就大大减少了。

Cassandra 通过排序数据实现了访问局部性。它的基本数据结构是日志结构的合并树(LSM- 树)。和闪存一起使用时,该结构可以显著减少写操作。据项目负责人 Jonathan Ellis 说,为了保证 LSM- 树的效率,Cassandra 承担了许多碎片整理工作,而大部分应用程序都把这项工作留给文件系统来做。而据 Rosenthal 说,FoundationDB 团队的做法则与此相反,他们依赖闪存控制器解决写碎片问题。闪存控制器可以完成 LSM 在数据库引擎层面所做的工作。现在,大部分闪存控制器都提供了这些算法。这里有一点需要注意,实现访问局部性会增加写操作的开销。在闪存吞吐量如此大的情况下,这部分开销可能会超过多次读操作的开销。

Tokutek 提供了一个聚簇数据库 TokuDB,他们发现聚簇是检索范围数据的理想选择。TokuDB 的压缩比很高(在 MySQL 或 MariaDB 上为 5 比 1 或 7 比 1,在 MongoDB 上为 10 比 1),这有效地减少了读写开销,并降低了存储成本。而且据官方介绍,它所使用的分形树索引结构减少了写操作次数,延长了闪存的使用寿命。

Aerospike、FoundationDB、RethinkDB 和 Tokutek 都是用 MVCC 或类似的概念连续写入新版本数据,并在稍后清理老版本数据,而不是直接用新值替换已存数据。因此,数据库的一个写请求会变成多个操作,这称为写入放大,是闪存的一个缺点。但据Bulkowski 说,通过将索引存储在内存中,Aerospike 的写入放大仅为2,而在其它应用程序中,这个值通常为10。

此外,按照Rosenthal 的说法,闪存的速度和并发为数据库设计带来了最大的变化。他说,“在传统关系型数据的设计中,每个连接一个线程,这在磁盘是瓶颈的时代可以工作的很好,但现在,线程成了瓶颈。”因此,FoundationDB 内部使用它自己的轻量级进程。在闪存延迟无法再改善的情况下,并发显得更重要了。而Bulkowski 则表示,由于大量的并发,深队列在闪存上比在旋转型磁盘上工作的更好。

总之,这些新的数据库存储引擎设计已经抛弃了许多传统的设计方案。为了利用这些新的发展成果,应用程序开发人员应该重新审视他们的数据库模式和访问模式了。


感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。

2014-09-11 02:284282
用户头像

发布了 256 篇内容, 共 85.1 次阅读, 收获喜欢 12 次。

关注

评论

发布
暂无评论
发现更多内容

可观测指标管理体系建设落地及插件功能设计和生态打造

嘉为蓝鲸

可观测 自动化运维 嘉为蓝鲸

还不知道线程池的好处,快来了解一下

华为云开发者联盟

开发 华为云 华为云开发者联盟 企业号 3 月 PK 榜

Vue.$nextTick的原理是什么-vue面试进阶

bb_xiaxia1998

Vue 前端

企业号 3 月 PK 榜,火热开启!

InfoQ写作社区官方

热门活动 企业号 3 月 PK 榜

前端必会react面试题

beifeng1996

前端 React

山东大学数字图像处理实验:MATLAB的图像显示方法

timerring

数字图像处理

不要因为这件小事,让你的网站在危险中“狂飙”

嘉为蓝鲸

自动化运维 weops 嘉为蓝鲸

新一代通信协议—— RSocket

老周聊架构

响应式编程 2月月更 rsocket

老生常谈React的diff算法原理-面试版

beifeng1996

前端 React

干货 | 中小型金融企业该如何进行灾备建设?

嘉为蓝鲸

金融 自动化运维 嘉为蓝鲸 灾备建设

CutLER:更好地训练无监督识别模型

Zilliz

问:React的setState为什么是异步的?

beifeng1996

前端 React

顶层设计出台 浪潮云破局再生长丨与千行百业扬帆数字蓝海

云计算

重磅福利!阿里云机器学习平台PAI+AI开源项目测评来啦

阿里云大数据AI技术

AI

如何快速理解事务隔离

Dinfan

数据库 innodb 事务隔离

美团前端常见react面试题(附答案)

beifeng1996

前端 React

前端常见vue面试题(必备)

bb_xiaxia1998

Vue 前端

前端一面常见vue面试题合集

bb_xiaxia1998

Vue 前端

推荐系统[四]:精排-详解排序算法LTR (Learning to Rank)_ poitwise, pairwise, listwise相关评价指标,超详细知识指南。

汀丶人工智能

自然语言处理 推荐系统 搜索算法

开发者体验:现代企业架构的关键一环

SEAL安全

平台工程 企业号 3 月 PK 榜 开发者体验

云原生可观察性工具泛滥的思考

HummerCloud

云原生 可观察性

Python:Excel自动化实践入门篇 乙【送图书活动继续】

eng八戒

Python Excel Python自动化办公

从一次CPU打满到ReDos攻击和防范

京东科技开发者

正则表达式 Web 企业号 3 月 PK 榜 ReDoS

Switchquery:移动端秒级配置触达平台

京东科技开发者

App 配置原理 用户触达 企业号 3 月 PK 榜

Vue的computed和watch的区别是什么?

bb_xiaxia1998

Vue 前端

MASA MAUI Plugin (九)Android相册多选照片(使用Android Jetpack套件库)

MASA技术团队

.net MASA MAUI

浅析大促备战过程中出现的 fullGc,我们能做什么?

京东科技开发者

JVM 内存 GC java 企业号 3 月 PK 榜

基于头肩部检测的过线客流统计

华为云开发者联盟

人工智能 华为云 华为云开发者联盟 企业号 3 月 PK 榜

网络性能总不好?网络调优专家AOE帮你来“看看”

华为云开发者联盟

人工智能 华为云 网络性能 华为云开发者联盟 企业号 3 月 PK 榜

直播 | StarRocks 实战系列第三期--StarRocks 运维的那些事

StarRocks

数据库 开源 运维

“堆内存持续占用高 且 ygc回收效果不佳” 排查处理实践

京东科技开发者

前端 堆内存 回收器 JavaScrip 企业号 3 月 PK 榜

闪存将改变数据库存储引擎的设计_语言 & 开发_马德奎_InfoQ精选文章