数据库漫谈（二）

编者按：

本文作者系Scott（中文名陈晓辉），现任大连华信资深分析师 ，ORACLE数据库专家，曾就职于甲骨文中国。个人主页：segmentfault.com/u/db_perf ，经其本人授权发布。

【免责声明】本公众号文章仅代表个人观点，与任何公司无关。

今天不聊八卦，聊一点儿和技术相关的东西。

话说数据库从一开始就遇到了两个重要大的挑战：I/O设备（硬盘）的读写速度和多个Process如何同时更新一条记录。

先说I/O设备读写速度。

在 SSD（Solid State Disk或Solid State Drive）硬盘被大量使用之前，计算机使用的主流存储设备都是 HDD（Hard Disk Drive）硬盘。

HDD硬盘是在平整的磁性表面存储和检索数字数据，信息通过离磁性表面很近的磁头，由电磁流来改变极性方式被电磁流写到磁盘上。

HDD硬盘主要由磁盘盘片、磁头、主轴与传动轴等组成，数据就存放在磁盘盘片中。大家见过老式的留声机吗？留声机上使用的唱片和我们的磁盘盘片非常相似，只不过留声机只有一个磁头，而硬盘是上下双磁头，盘片在两个磁头中间高速旋转，大体是长成这个样子。

也就是说，机械硬盘是上下盘面同时进数据读取的。而且HDD硬盘的旋转速度要远高于唱片（目前机械硬盘的常见转速是 7200 r/min），所以机械硬盘在读取或写入数据时，非常害怕晃动和磕碰。

另外，因为机械硬盘的超高转速，如果内部有灰尘，则会造成磁头或盘片的损坏，所以机械硬盘内部是封闭的，如果不是在无尘环境下，则禁止拆开机械硬盘。

我们已经知道数据是写入磁盘盘片的，那么数据是按照什么结构写入的呢？这就依靠HDD硬盘的逻辑结构设计。

HDD硬盘的逻辑结构主要分为磁道、扇区和柱面，我们来看看下图。

什么是磁道呢？每个盘片都在逻辑上有很多的同心圆，最外面的同心圆就是 0 磁道。我们将每个同心圆称作磁道（注意，磁道只是逻辑结构，在盘面上并没有真正的同心圆）。硬盘的磁道密度非常高，通常一面上就有上千个磁道。但是相邻的磁道之间并不是紧挨着的，这是因为磁化单元相隔太近会相互产生影响。

那扇区又是什么呢？扇区其实是很形象的，大家都见过折叠的纸扇吧，纸扇打开后是半圆形或扇形的，不过这个扇形是由每个扇骨组合形成的。在磁盘上每个同心圆是磁道，从圆心向外呈放射状地产生分割线（扇骨），将每个磁道等分为若干弧段，每个弧段就是一个扇区。每个扇区的大小是固定的，为 512Byte。扇区也是磁盘的最小存储单位。

柱面又是什么呢？如果硬盘是由多个盘片组成的，每个盘面都被划分为数目相等的磁道，那么所有盘片都会从外向内进行磁道编号，最外侧的就是 0 磁道。具有相同编号的磁道会形成一个圆柱，这个圆柱就被称作磁盘的柱面，如下图所示。

所以HDD硬盘的大小是使用"磁头数 x 柱面数 x 扇区数 x 每个扇区的大小"这样的公式来计算的。其中，磁头数（Heads）表示硬盘共有几个磁头，也可以理解为硬盘有几个盘面，然后乘以 2；柱面数（Cylinders）表示硬盘每面盘片有几条磁道；扇区数（Sectors）表示每条磁道上有几个扇区；每个扇区的大小一般是 512Byte。

而HDD硬盘读取响应时间可以分为以下几个阶段：

1. 寻道时间：磁头从开始移动到数据所在磁道所需要的时间，寻道时间越短，I/O操作越快，目前磁盘的平均寻道时间一般在3－15ms，一般都在10ms左右。
2. 旋转延迟：盘片旋转将请求数据所在扇区移至读写磁头下方所需要的时间，旋转延迟取决于磁盘转速。普通硬盘一般都是7200r/min，所以旋转延迟时间非常小。
3. 数据传输时间：完成传输所请求的数据所需要的时间。这个过程是电信号传播，不涉及机械运动，所以也非常快。

接下来我们再来看看关系数据库是怎样利用HDD硬盘存储数据，还以ORACLE数据库为例说明。

ORACLE数据库是以数据块为最小单位进行I/O操作的，数据块大小有几个选择：2K,4K,8K,16K,32K. 由数据库参数db_block_size控制，默认是8K。

然后我们想象一下最常使用的数据库记录增加的场景：

1. 数据库记录一般随着业务的进行，用INSERT语句插入到数据库中。
2. 数据块随着记录的不断插入，不断的从OS的文件系统被追加到数据库的数据文件中，并被分配给相应的表空间（Tablespace）和段（Segment）中。
3. 上面过程被许多不同的处理在几乎同时的时间上执行，造成了一个表（Table）的数据块被存储在不同物理位置上。

到上面为止，你也许会认为即使存储位置离的再远，人工发起的处理也不会因为这几十个ms感受到多少延迟吧。

恭喜你答对了。因为INSERT处理基本都只对一个几个数据块操作就足够了，不会有太多的I/O延迟。即使是批量INSERT处理，那这时会使用连续的多个数据块，属于“连续I/O”，和我们下面谈论的“随机I/O”是不同的。相反，它是解决由“随机I/O”造成迟延的一个解决方案。关于这个我会在以后的文章里详细解释，这里就不赘述了。

既然记录被初次存储到数据库的过程的确没有受到多少HDD硬盘读取响应时间的影响。但是数据只是为了写进数据库里吗？

当然不是，数据存进数据库除了存储，更是为了方便的维护（UPDATE/DELETE）和查询（SELECT）。

那么问题来了。

SELECT/UPDATE/DELETE的处理一般都是有条件的，通过“Where”语句指定。当一个处理涉及到的记录数很多，这些数据块的物理位置又很不幸的不连续。那这个处理的I/O是怎么实现的呢？

不错，应用程序（数据库）只能根据需要一次又一次的发行I/O请求，HDD硬盘寻道，读取数据，再传回给应用程序。这就是最令所有数据库厂商所深恶痛绝的“随机I/O”。

为了帮助大家理解“随机I/O”为什么如此的臭名昭著，我给大家举个简单的栗子。

根据HDD硬盘使用最多的“循环扫描算法”(CSCAN，又被称为电梯算法)，磁头是单向移动的，即磁头只能从最里磁道到磁盘最外层磁道，然后再由最外层磁道移动到最里层磁道。

这时假设有一个SELECT处理需要访问3个数据块，它们分别存储在具有10个磁道（0-9）的HDD硬盘的第5磁道，4磁道，9磁道。再假设I/O开始时磁头在0磁道，那么这个I/O的寻道处理会这样进行：

0磁道 --> 5磁道(读数据块) --> 9磁道 --> 4磁道(读数据块) --> 0磁道 --> 9磁道(读数据块)

看到这里，大家明白了吗？为了读3个数据块，寻道了30个磁道，浪费了90%的寻道时间。

也许有些爱思考的同学又会想到，那我们为啥不整合一下I/O请求，排序后按照下面的步骤寻道呢？

0磁道 --> 4磁道(读数据块) --> 5磁道(读数据块) --> 9磁道(读数据块)

这样的话，一次0到9的寻道就解决了所有问题,效率提高了200%。

你真是太聪明了，因为ORACLE数据库直到12c才导入了这样的设计，叫“Batched I/O”。但是这也带来一些其他的问题，这篇文章里不想扯的那么远，具体会有什么样的影响，就暂时留给大家思考了。

综上所述，传统的HDD硬盘，寻道时间 最容易成为整个系统的I/O瓶颈。

今天就写到这儿吧，需要干正经工作了。

下次更新和大家继续聊ORACLE数据库如何优化这个问题的，欢迎继续关注！