数据库存储的内部机制详解.docx

??

?

??

数据库存储的内部机制详解

?

??

?

?

?

?

?

?

?

???

?

?

?

?

?

?

?

在这篇文章中，我将会讲解一些数据库存储的内部机制，数据库是如何进行优化操作来提供惊人速度及其优势和缺点。

当我们谈起数据库内部存储结构时，人们都会想到B树或者B+树，但是我们在这里并不会谈论这些数据结构的原理，我们会展示这些数据结构为什么适合作为数据库存储的内部结构以及使用这些数据结构的目的。

传统的关系型数据将数据以B树的形式存储在磁盘上，它们也会在RAM上使用B树维护这些数据的索引，来保证更快的访问速度。插入的行存储在B树的叶子节点上，所有的中间节点用来存储用于导航查询语句的原数据。因此，当有数以百万计的数据被插入到数据库中时，索引和数据存储会变得十分大。因此，为了快速的访问，需要从磁盘中加载所有数据到内存，但是RAM一般没有这么大的空间来存储所有的数据。因此，数据库必须从磁盘中读取部分数据。这种加载数据的场景如下图所示：

B树被设计为使用block的形式存储数据，因为操作系统读取读取一个block的数据要比读取单独字节数据要快的多。MySQL的InnoDB存储引擎的block大小为16KB。这意味着每次你读取或者写入数据时，大小为16KB的block数据会被从磁盘加载到RAM中，它会被写入新的数据，并且再次写回到磁盘上。假设数据库表的每一行数据为128字节（实际大小会变化），一个block（叶子节点）为16KB，存储了（16*1024）/128=128行数据。B树的高度一般小于10，但是每一层的节点数量却很多，由此可以管理数以万计的数据。基于上述特性，B树适合作为数据内部存储结构。

因此，在B树上进行读操作是相对来说比较快速的，因为该操作只需要遍历一些节点并且进行较少次数的磁盘I/O请求。而且，范围查询因为可以将数据以block的形式进行获取和操作而速度更快。你可以进行下列操作来让基于B-Tree的数据库性能更好：

减少索引节点数量：这是提升关系型数据库性能的常用策略。索引越多，插入和更新操作需要管理的索引数量也越多。当数据库数据运行时间越来越久时，就需要删除一些老旧或者无用的索引，并且谨慎地添加新的索引。但是你也要注意，索引越少意味着查询性能越差，你需要在查询性能和插入更新性能之间进行取舍（译者注：可以考虑数据库的读写比率）。

顺序插入：如果你能以主键大小为基础进行大量数据的顺序插入，那么插入数据的速度会十分的快。因为在插入过程中，插入行所属的block已经在内存中，所以数据库可以直接将行插入到内存的数据结构中，然后通过一次磁盘I/O提交到数磁盘中。当然，这些都取决于数据库的具体实现，但是我认为现代的数据库一般都会进行类似的优化。

但是B树并不是适合所有情景的最优存储结构。对B树结构的写操作性能很差，比随机读还要差，因为数据库必须从磁盘中加载数据对应的页，然后修改它并冲洗新写入到磁盘中。随机写入时平均有100字节每秒写入速度，这个限制是由于磁盘的基本工作原理。事实上，简单依赖于缓存的使用，索引搜索和更多的内存可以处理更多的读操作，但是应付更多的写操作就比较麻烦。当你需要写入或更新大量的数据时，B树结构并不是最正确的选择。长久以来，传统数据库进行了大量的优化，比如说InnoDB尝试使用缓冲来减少磁盘I/O操作。具体操作如下所示：

数据库写操作可以通过提升磁盘的带宽来提升速度，但是目前关系型数据库都没有这样做。而且关系型数据库管理系统一般都是十分复杂的，因为他们使用锁，并发，ACID事务等操作，这使得写入操作更加复杂。

当今信息时代，在比如消息、聊天、实时通讯和物联网等客户为中心的服务和大量无结构化数据的分布式系统中，每小时都会进行数百万计的写入操作。因此，这些系统是以写为主的系统，为了迎合这些系统的需要，数据库需要能够拥有快速插入数据的能力。典型的数据库并不能很好的满足类似的场景，因为它们无法应付高可用性，尽可能的最终一致性，无格式数据的灵活性和低延迟等要求。

LSM树（LogStructuredMergeTree）应运而生。LSM并不是一种类似于B树的数据结构，而是一个系统。在LSM系统中，并没有对数据的in-place替换；一旦数据被写入磁盘，它就再也不会被修改。显然，它是一种只能在末尾添加（appendonly）的写入系统。一些日志结构的文件系统比如ext3/4也使用类似的原理。因此，该系统就如同顺序的记录数据日志一般。基本上，LSM系统利用了顺序写的优势。传统的磁盘驱动的写操作最高可以达到100MB/s，现代的固态硬盘在顺序写时的速度则更快。事实上，固态硬盘驱动有一些内置的并行机制来让它可以同时写入16到32MB的数据。LSM树和固态硬盘的特性十分匹配。顺序写要比随机写快很多。

为了正确地