写点什么

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

  • 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:284784
用户头像

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

关注

评论

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

JavaScript 对象遍历为什么要使用 hasOwnProperty 检查属性

Lee Chen

JavaScript

一名开发者眼中的TiDB与MySQL选择

TiDB 社区干货传送门

数据库架构选型

Greptime 的 GitOps 实践

Greptime 格睿科技

k8s gitops IaC

前端开发:未来依旧光明 | 社区征文

海拥(haiyong.site)

三周年征文

OpenHarmony社区运营报告(2023年3月)

OpenHarmony开发者

OpenHarmony

华秋PCB生产工艺 | 第十二道主流程之FQC

华秋电子

HummerRisk V1.0.0:架构全面升级,开启新篇章

HummerCloud

云原生安全

【坚果派-坚果】OpenHarmony新增并编译芯片解决方案

坚果

OpenHarmony OpenHarmony3.2 三周年连更

macbook触摸板怎么按右键

互联网搬砖工作者

【4.7-4.14】写作社区优秀技术博文一览

InfoQ写作社区官方

热门活动 优质创作周报

总结一下Redis的缓存雪崩、缓存击穿、缓存穿透

全新适配鸿蒙生态,Cocos引擎助力3D应用开发

HarmonyOS开发者

HarmonyOS

TiDB 6.1/6.5 在 Rocky Linux 8 中的部署升级与 PITR 初体验

TiDB 社区干货传送门

版本升级 安装 & 部署 备份 & 恢复 扩/缩容 6.x 实践

每日 Scrum 与站立会议:有什么区别?

码界行者

Scrum

国内功率半导体需求将持续快速增长

华秋电子

Spring Security 的介绍和简单使用

会踢球的程序源

Java 后端 spring security Java进阶

Java中的异常处理详解(try、catch、finally、throw、throws) | 社区征文

共饮一杯无

Java 异常处理 三周年连更

SLBR通过自校准的定位和背景细化来去除可见的水印

合合技术团队

人工智能 图像处理 水印消除

Netty框架详解:高性能网络编程的设计与实现

网络编程 Netty 高性能

Parallels Desktop PD 18虚拟机关闭、停止、中止和暂停操作的区别

互联网搬砖工作者

企业级安全运维审计产品-行云管家堡垒机全新V7.0举行线上发布会

行云管家

运维 云堡垒机 安全运维 等级

阿里P8架构师爆肝分享内部开源的JVM垃圾回收PDF文档,共23.3W字

Java JVM 垃圾回收

新手测试必学的 API 接口文档知识

Apifox

测试 入门 接口文档 API API 文档

精华!Redis 知识总结

会踢球的程序源

Java Java进阶 redis 底层原理

各大金融企业都在用的堡垒机-行云管家堡垒机

行云管家

金融 数据安全 堡垒机

全面数字化时代,国有大型银行如何走好金融创新之路?

华为云开发者联盟

数据库 后端 华为云 华为云开发者联盟 企业号 4 月 PK 榜

活久见,java8 lamdba Collectors.toMap()报NPE

关键的Java JVM选项和参数

码界行者

JVM

网站不收录是受哪些因素影响?

海拥(haiyong.site)

三周年连更

更安全、更低耗的微服务架构改造之道

华为云开发者联盟

云计算 后端 华为云 华为云开发者联盟 企业号 4 月 PK 榜

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