本文为阅读书籍Next Generation Databases: NoSQL, NewSQL, and Big Data 第7章: The End of Disk? SSD and In-Memory Databases的笔记。

磁盘已死?

比尔.盖茨在1981年曾说过:

640K of memory should be enough for anybody.

在2001年,他意识到之前的说法是错误的:

I’ve said some stupid things and some wrong things, but not that.

从第一个数据库诞生以来,数据库专家就一直努力尽量避免磁盘I/O,因为磁盘比内存,CPU慢好几个数量级。
在CPU,内存和磁盘的密度遵循摩尔定律飞速发展时,由于磁盘的机械特性,磁盘速度的进展却远远滞后。
SSD的产生使磁盘的性能带来了飞跃,最近几年价格下降使得其成为了提升数据库性能的主流技术。与此同时,内存容量的增加以及价格的下降也使得内存技术成为加速数据库性能的另一选择,一些小的数据库可以完全放置于内存中,通过内存集群也可以容纳更大的数据库。在对性能要求严苛的环境下,内存比SSD更具吸引力。

磁盘发展于上世纪50年代,尽管磁盘密度不断提升,但磁盘的核心架构却基本未变,还是机械臂移动磁头到盘片的磁道上读取数据而已。

机械磁盘之后,又有了固态硬盘(SSD),SSD没有移动部件,I/O延迟低。目前,大部分的SSD都是用NAND flash实现的。
SSD对于读的性能实现了较大的提升,例如,机械磁盘的随机读需要4毫秒,而高端SSD只需要25微秒,快了150倍。
但SSD并不能适用所有的工作负载,对于修改操作,SSD就表现一般了。
SSD将信息存于cell中,对于SLC,每一个cell存一个bit信息,对于MLC,每一个cell通常存两个bit,或3个bit信息。cell组织成4k的page,256 page又组织成block。

Read operations, and initial write operations, require only a single-page IO. However, changing the contents of a page requires an erase and overwrite of a complete block.

这就是SSD的软肋了,SSD对于写的性能远低于读,比物理磁盘也许也快不了多少。

flash SSD is significantly slower when performing writes than when performing reads.

由于SSD有一定的擦写寿命,为了避免erase操作的开销,厂商使用了’wear leveling’的技术,通过均匀的分布写来延长磁盘寿命。解释如下,详见NAND Flash FAQ。

Wear-leveling is a technique that spreads the memory use evenly to different physical pages so that the entire NAND Flash devices is used evenly to maximize the life span of the device and the system.

SSD会替代磁盘吗? 目前应不会,虽然SSD的成本在降,磁盘的成本也同时在降。SSD的单位I/O能力强,磁盘具更好单位成本优势。比较合理的结果是内存,SSD和磁盘的结合。

SSD适合于随机写,物理磁盘适合于顺序写,在SSD上运行数据库性能未必会提升。例如当交易提交时,会写redo log,这就是顺序写。因此对于写密集的数据库是不适合SSD的。

内存数据库

SSD对于数据库架构的改变是渐进式的,随着内存价格的下降和容量的增加,将整个数据库置于内存中则带来革命性的架构变化。 (参见http://www.jcmit.com/memoryprice.htm)

对于中小型的数据库,已经可以完全置于内存中,更大容量的数据库则可以通过内存集群技术来利用内存的性能。
传统的数据库利用内存作为缓存来提升性能,但一些操作如commit和checkpoint还是会访问物理磁盘,因此内存数据库需要架构上的改变,即不使用cache和新的持久化模式。

内存数据通常使用以下的技术来保证数据不丢失:
1. 数据复制
2. 将整个数据库映像写盘(snapshot或checkpoint)
3. 将事务写入事务日志或journal

TimesTen

TimesTen是发展较早的关系型内存数据库,成立于1995年,2005年被Oracle收购。
TimesTen早期遵循ANSI-SQL标准,被收购后,又扩展了PL/SQL。
TimesTen数据库的整个数据库都置于内存中,通过checkpoint和事务日志技术保证数据不丢失。
和Oracle不同,缺省模式下,写是异步的,这可能会造成数据丢失,因此ACID中的Durability并不能保证。虽然也可以指定同步模式,但这样会影响性能。
TimesTen的架构如下图:

Redis

和TimesTen的关系型内存数据库不同,Redis (Remote Dictionary Server)采用的是key-value内存存储。
Redis产生于2009,之后VMware和Pivotal对其进行了资助。
Redis的查询只支持主键作为key,不支持二级查询。value方面通常是string集合, 如list, hash map等。
虽然Redis的设计是将整个数据库置于内存中,但也可以结合磁盘来容纳更大的数据库。 此功能TimesTen不具备。

it is possible for Redis to operate on datasets larger than available memory by using its virtual memory feature. When this is enabled, Redis will “swap out” older key values to a disk file. Should the keys be needed they will be brought back into memory. This option obviously involves a significant performance overhead, since some key lookups will result in disk IO.

Redis持久化的策略和TimesTen类似,也是使用snapshot和Journal(redis的术语称为Append Only File 或AOF)。Redis也支持异步的数据复制,但也不能完全保证数据不丢失。
Redis的AOF可以配置为每一个操作后都写,这类似于TimesTen的Durable Commit,对性能有影响。
Redis的架构如下图:

Redis is popular among developers as a simple, high-performance key-value store that performs well without expensive hardware. It lacks the sophistication of some other nonrelational systems such as MongoDB, but it works well on systems where the data will fit into main memory or as a caching layer in front of a disk-based database.

HANA

SAP在2010年推出了HANA,主要用于BI,但也可用于OLTP。
HANA也是关系型数据库,数据表可以选择列式或行式存储,两者只能选一,通常OLTP选用行式,而BI选用列式。后面会提到Oracle 12c中的In-memory对于一个表同时支持行式和列式。
行式数据确保在内存中,列式数据缺省从磁盘中加载。而对于Oracle In-memory,行式数据使用以前的缓存技术,列式数据和HANA类似。
HANA的持久化策略和TimesTen,Redis类似,也是定期将内存写入Savepoint文件中,之后与数据文件合并。
事务一致性通过事务日志保证,在commit时写日志,为避免I/O性能影响,HANA建议将日志置于SSD盘上。
HANA的架构如下图:

此图需要说明的是,对于列式存储表的写首先是存为非压缩的行式(L1 Data Store),然后转化为压缩的列式(L2 Data Store)

Transactions to columnar tables are buffered in this delta store. Initially, the data is held in row-oriented format (the L1 delta). Data then moves to the L2 delta store, which is columnar in orientation but relatively lightly compressed and unsorted. Finally, the data migrates to the main column store, in which data is highly compressed and sorted.

HANA在commit和列式表按需从磁盘载入内存时会涉及到磁盘操作。

VoltDB

TimesTen,HANA,Redis都不可避免的有磁盘读写,而VoltDB号称纯内存数据库,交易在内存中提交,然后通过内存复制实现持久化。例如如果要保证 K-safety为2,则需要至少复制到两台机器。
VoltDB也支持磁盘日志,可以是同步或异步的。
VoltDB支持关系型模式,不过最适合的还是基于key将数据分片或分区分布。如果数据间没有关联可以大大提高并非性,如果需要聚集操作则需访问多个节点,存在开销。
更多的细节可以参见文章。

Oracle 12c “in-Memory Database”

In-Memory是12的一个option,是用列式存储来补充基于磁盘的行式存储的,主要是用来应对HANA的。 所以并非所有数据都在内存中。每个表都有行式和列式两种格式,对于用户是透明的,应用无需更改。
Oracle 12c In-Memory的架构如下:

上图中IMCU表示列式存储,In-Memory Columnar Unit,而Snapshot Metadata Unit (SMU) 是用来跟踪IMCU中数据的有效性的(是否被OLTP应用修改),以与行式数据同步。
Oracle的这篇文章Oracle’s In-Memory Database Strategy for OLTP and Analytics很好的阐述了TimesTen和In-Memory的区别。

Berkeley Analytics Data Stack and Spark

如果说TimesTen和HANA适合内存关系型,Redis适合内存key-value,则Spark适合内存Hadoop。
Hadoop已成为大数据处理的基石,传统的MapReduce基于磁盘,适合于批量处理非结构化和半结构化数据。而Spark的出现则将Hadoop带人实时处理的领域。
2011年,AMPlab在加州伯克利大学成立,来解决大数据环境下的高级分析和机器学习的问题,随后推出的Berkeley Data Analysis Stack (BDAS)包括Spark,Mesos(内存集群管理,类似于YARN)和Tachyon(内存分布式文件系统),其中Spark得到了大量采用。
Spark是基于内存的具有容错的分布式处理框架,它将MapReduce做了上层抽象,从而提高了开发效率,同时解决了传统MapReduce的磁盘I/O问题。
Spark和Hadoop紧密配合,并使用HDFS做持久化。
Spark也支持SQL,

Spark SQL provides a Spark-specific implementation of SQL for ad hoc queries, and there is also an active effort to allow Hive— the SQL implementation in the Hadoop stack—to generate Spark code.

Spark, Hadoop, and the Berkeley Data Analytics Stack的框架如下:

Cloudera, Hortonworks和MapR都集成了Spark。
Spark基于JVM实现,Spark可以存储string, Java对象,主要还是key-value存储。
Spark虽希望将数据在内存中处理,但Spark还是主要用于无法将所有数据完全置于内存中的情形。
Spark并非面向OLTP,因此也就没有事务日志的概念。
Spark也可以访问JDBC兼容的数据库,包括几乎所有的关系型数据库,以及NoSQL数据库如HBase 或 Cassandra。
Spark的处理流程如下图:

结论

断言磁盘已死还为时过早,毕竟磁盘对于冷数据和温数据具成本优势,特别是在大数据时代。
当性能的需求比存储成本更重要时,就可以考虑SSD和内存数据库,特别是当数据库可以整个置于内存中时,内存数据库具有更大的吸引力。
总之,没有一种技术可以解决所有问题,这取决于你的需求,预算等因素,更多看到的应是磁盘,SSD和内存技术的结合。

SSD和内存数据库技术相关推荐

  1. 直接在内存里计算数据?先做一个内存数据库技术选型吧

    -     前言    - 依靠内存来存储数据的数据库管理系统,也称为内存数据库,成为了解决高并发.低时延数据管理需求的技术路线.近年来,随着动态随机存储器(DRAM)容量的上升和单位价格的下降,使大 ...

  2. 内存数据库技术白皮书

    内存数据库又称主存数据库(In-memory或main memory database),是一种主要依靠内存来存储数据的数据库管理系统. 在数据库技术中,有一类内存优化技术,是在传统的磁盘数据库中,增 ...

  3. [SSD固态硬盘技术 0] SSD的结构和原理导论

    版权声明: 本文禁止转载 机械硬盘的存储系统由于内部结构,其IO访问性能无法进一步提高,CPU与存储器之间的性能差距逐渐扩大.以Nand Flash为存储介质的固态硬盘技术的发展,性能瓶颈得到缓解. ...

  4. [SSD固态硬盘技术 17] 缓存(DRAM)对性能的影响机制

    #[国庆活动]带上CSDN一起玩转国庆# 目录 前言 名词解释 1. SSD 缓存 1.1 DRAM SSD 1.2 无DRAM SSD 1.3 HMB SSD 1.4 有无DRAM 的 SSD 对比 ...

  5. [SSD固态硬盘技术 7] 主控核心设计

    摘要 本文介绍了此类设计选择的分类,并使用跟踪驱动的模拟器和从实际系统中提取的工作负载跟踪分析各种配置的可能性能.我们发现SSD性能和生命周期对工作负载非常敏感,并且通常较高的复杂系统问题出现在存储堆 ...

  6. [SSD固态硬盘技术 4] 主控详解

    固态硬盘(Solid State Drives),简称SSD.它是一种电脑存储设备,由闪存(FLASH). 闪存控制器.高速缓存(DRAM)组成.这是是固态硬盘的三个基本部件,对性能有关键影响. 了解 ...

  7. [SSD固态硬盘技术 6] DRAM缓存技术详解

    固态硬盘(Solid State Drives),简称SSD.它是一种电脑存储设备,由闪存(FLASH). 闪存控制器.高速缓存(DRAM)组成.这是是固态硬盘的三个基本部件,对性能有关键影响.

  8. 英特尔首度公开展示SSD超频技术

    之前曾有新闻报道,英特尔将在下周的IDF展会上展示SSD超频特性,不过没等到下周,英特尔今天在西雅图举行的PAX Pax展会上就向公众展示了其SSD超频的特性. 据报道,英特尔使用其之前发布的Extr ...

  9. [SSD固态硬盘技术 8] 固件概述和固件升级

    固件英文叫Firmware,就是"固化在硬件中的软件",不太恰当但是毕竟好理解的就是:固件就是硬盘的操作系统.固件Firmware是安装在硬盘的一个小记忆芯片上的,用于引导硬盘工作 ...

  10. ssd内部是多个flash一起操作_一键自毁军工级SSD固态硬盘的技术亮点

    通过短路方式实现,烧毁时可见明火及冒烟,5秒(时间可调整)防误触发功能,每2秒烧毁一片闪存芯片,独特的反馈电路实时反馈烧毁状态,确保所有闪存全部被烧毁.烧毁后电子盘彻底报废,无法通过任何手段恢复数据. ...

最新文章

  1. 这38篇原创文章,带我入门深度学习!
  2. graythresh matlab,Matlab-图形算法和图像处理指南
  3. 沙龙报名 | 探索新零售时代的数字化创新
  4. XP系统,在文件或文件夹属性里找不到安全选项卡
  5. oracle delete原理,如何恢复并理解oracle删除数据的原理
  6. 算法练习day8——190326(队列实现栈、栈实现队列)
  7. GIS实战应用案例100篇(二十一)-全国分省、市、县净初级生产力NPP数据制作实战(附代码)
  8. Linux shell(4)
  9. HTTP Status 404 -(tomcat,springmvc,ModelAndView)
  10. python实用技巧(一)
  11. android安装git插件安装教程,Android Studio 3.6.1上使用gitee
  12. jsp分页的常用写法
  13. 信息物理社会融合系统:一种以数据为中心的框架
  14. php导入word文件怎么打开,phpword 导入word
  15. pool(一)——入门
  16. 2023第八届少儿模特明星盛典 小超模矫沐含 担任全球赛代言人
  17. STM32F4+FreeRTOS+FreeRTosTcpIp移植教程
  18. 脑洞大开的思维工具:六顶思考帽
  19. python编程从入门到实践 项目一:外星人入侵
  20. 2k19徽章修改_您可以修改此会议徽章

热门文章

  1. html5在线聊天一对一,纯js网页在线聊天对话插件(原创)
  2. 【支付】——毕业设计中利用websocket做模拟支付
  3. 颜色空间的几种表示方法
  4. 微信公众号回复消息换行符处理
  5. 水果电商网站开发过程
  6. vue 使用iframe展示pdf文件
  7. python 处理 图像和视频
  8. 关于Bootstrap 中使用Tooltips不生效的问题
  9. Pdf转Word用Python轻松实现
  10. 案例分析:从误删除数据库血案看数据库系统的安全设计