数据库存储的内部机制详解是什么，数据库存储的内部机制详解

很多朋友对数据库存储的内部机制详解是什么，数据库存储的内部机制详解不是很了解，每日小编刚好整理了这方面的知识，今天就来带大家一探究竟。

在本文中，我将解释数据库存储的一些内部机制，如何优化数据库以提供惊人的速度及其优缺点。当我们谈到数据库的内部存储结构时，人们会想到B-tree或B-tree，但我们在这里不会谈到这些数据结构的原理。我们将展示为什么这些数据结构适合作为数据库存储的内部结构，以及使用这些数据结构的目的。

传统的关系型数据在磁盘上以B树的形式存储数据，他们也使用B树来维护这些数据在RAM上的索引，以保证更快的访问速度。插入的行存储在B树的叶节点中，所有中间节点用于存储导航查询语句的原始数据。因此，当数百万的数据被插入数据库时，索引和数据存储量会变得非常大。

因此，为了快速访问，需要将磁盘中的所有数据加载到内存中，但RAM一般没有这么大的空间来存储所有数据。因此，数据库必须从磁盘中读取一些数据。下图显示了此数据加载场景：

磁盘I/O耗时较长，是影响数据库性能的主要原因之一。b树是一种紧凑的自平衡数据结构，支持随机读写和就地替换，但受限于磁盘I/O速度。随机读取是指在访问磁盘数据时，磁头必须移动到柱面上的指定位置，因此会消耗大量时间。

b树被设计成以块的形式存储数据，因为对于操作系统来说，读取一个块数据要比读取一个单字节数据快得多。MySQL的InnoDB存储引擎的块大小为16KB。这意味着每次读写数据时，大小为16KB的块数据会从磁盘加载到RAM中，并写入新的数据，再次写回磁盘。

假设数据库表中每行数据为128字节(实际大小会有变化)，一个块(叶节点)为16KB，存储(16 * 1024)/128=128行数据。B树的高度一般小于10，但每层节点很多，可以管理上万个数据。基于以上特点，B树适合作为数据的内部存储结构。

所以在B树上读比较快，因为只需要遍历一些节点，做的磁盘I/O请求比较少。此外，范围查询更快，因为数据可以以块的形式获得和操作。您可以执行以下操作来提高基于B树的数据库的性能：

减少索引节点的数量：这是提高关系数据库性能的常用策略。索引越多，需要为插入和更新操作管理的索引就越多。当数据库数据运行的时间越来越长时，就需要删除一些旧的或无用的索引，谨慎地添加新的索引。但是，您还应该注意，索引越少意味着查询性能越差，您需要在查询性能和插入更新性能之间做出选择。

顺序插入：如果能根据主键大小顺序插入大量数据，插入数据的速度会很快。因为插入行所属的块在插入过程中已经在内存中了，所以数据库可以直接将行插入内存的数据结构中，然后通过一个磁盘I/O提交给几个磁盘，当然这些都取决于数据库的具体实现，但是我觉得现代数据库一般都会进行类似的优化。

但是B树并不是所有场景的最优存储结构。B树结构的写性能很差，甚至比随机读取还要差，因为数据库必须从磁盘加载数据对应的页面，然后修改它，将新的写刷新到磁盘。随机写入的平均写入速度为每秒100字节，受限于磁盘的基本工作原理。其实单纯依靠使用缓存、索引搜索和更多内存可以处理更多的读操作，但是处理更多的写操作就比较麻烦了。

当需要写入或更新大量数据时，B树结构并不是最正确的选择。长期以来，传统数据库都有很大的优化。例如，InnoDB试图使用缓冲来减少磁盘I/O操作。具体操作如下：

数据库写操作可以通过增加磁盘的带宽来提高速度，但目前关系数据库还没有这样做。而且关系数据库管理系统一般都非常复杂，因为使用了锁、并发、ACID事务等操作，使得写操作更加复杂。

在当今的信息时代，在以客户为中心的服务(如消息、聊天、实时通信和物联网)中，以及在具有大量非结构化数据的分布式系统中，每小时都要进行数百万次写入操作。因此，这些系统是基于写的系统，为了满足这些系统的需要，数据库需要能够快速地插入数据。

典型的数据库无法很好地满足类似场景，因为它们无法满足高可用性、尽可能的最终一致性、无格式数据的灵活性和低延迟的要求。

LSM树(日志结构化合并树)应运而生。LSM不是一个类似于B树的数据结构，而是一个系统。在LSM系统中，没有数据的就地替换；数据一旦写入磁盘，就永远无法修改。显然是一个只能在末尾追加的书写体系。一些日志结构的文件系统，比如ext3/4，使用类似的原理。因此，系统就像是按顺序记录数据日志。

基本上，LSM系统利用了顺序写入的优势。传统磁盘驱动器的写入操作最高可达100MB/s，而现代固态硬盘在顺序写入时速度更快。事实上，SSD驱动器有一些内置的并行机制，允许它同时写入16到32MB的数据。LSM树和固态硬盘的特性非常匹配。顺序写入比随机写入快得多。

为了正确理解上面的场景，让我们简单看看脸书的卡珊德拉数据库是如何使用LSM原则的。

Cassandra或者任何LSM系统都会维护一个或者多个用来在写入磁盘前存储数据的内存数据结构（如上图中的memtable），比如说子平衡树（AVL）、红黑树、B树或者跳表。该内存数据结构维护一个排序的数据集。不同的LSM实现互使用不同的数据结构来适应不同的需求，并不存在标准的LSM实现。

当内存中存储的数据超过配置的阈值时，内存中存储的数据就会被放置在将会被写入磁盘的队列中。为了flush数据，Cassandra顺序地写入排序的数据到磁盘中。磁盘维护一个叫做“SSTable”（Sorted Strings Table）的数据结构，该数据就是写入文件数据的有序的快照，SSTable是不可变的。LSM系统可以管理磁盘上的多个文件。

因此，如果数据在内存中没有被发现，Cassandra需要扫描所有磁盘上的SSTables来搜索该数据。因此，Cassandra的读操作相对来说要比写操作慢，但是这里有一些可以处理的方法。Cassandra或者其他LSM系统会在后台运行压缩程序来减少SSTable的数量。压缩程序对SSTable进行归并排序，在新的SSTable找那个插入新的排序数据并且删除老的SSTables。

但是使用压缩程序有时候无法应付数据库中数以百万计的更新操作。

因此，一些概率数据结构（probabilistic data structures）比如Bloom filters被应用来快速判断是否一些数据存在于SSTable。Bloom filters十分适合对内存中的数据进行判断，因为它需要进行大量的随机查询来进行数据是否存在的概率性判断。Bloom filters算法可以极大地减少遍历查询SSTables的花费。因此，LSM系统解决了在大数据中写操作需要花费大量时间的问题。

LSM系统也有Read amplification的问题-会读取出比它实际需要更多的数据。因此，还有介于B Tree和LSM Tree之间的解决方法来给出我们最优（不一定准确）的读写效率吗？

Fractal Tree Index是基于B-Tree的数据结构。依据开发人员给出的benchmark，该数据结构有比B-Tree更优良的性能。Fractal tree支持在非叶节点上的信息缓存。MySQL的高性能存储引擎Tokudb就使用了Fractal tree。

如上图所示，在Fractal Tree中，你进行的添加列，删除列，插入，更新等任何操作都会被当做操作消息存储在非叶节点上。由于操作只是被简单地存储在缓存或者任何次级索引缓存（secondary index buffer）中，所以，所有的操作都会被迅速执行结束。当某一个节点的缓存满了之后，这些操作消息会依次从根节点，经过非叶节点，向叶节点进行传递。叶节点仍然存储着真实数据。

当进行读时，读操作会考虑查询路径节点上的所有操作消息来获取真实的数据状态。但是由于tokudb会尽力将所有非叶节点缓存在内存中，所以这一过程也很快。

tokubd中的block最大可以达到4MB，而不是InnoDB中的16KB。这样的大小可以允许一次I/O操作时加载或写回更多的数据，这也有助于一次压缩更多数据来减少磁盘上数据的存储大小。因此，tokudb强调借助更大的block大小能够实现更好的数据压缩和更少的磁盘I/O。

tokudb宣称它们的存储引擎比InnoDB更快，提供比InnoDB更快的读写吞吐，并且tokudb也宣称自己有更少的碎片（fragmentation）问题，它也支持多集群索引等。下图是benchmark的相关统计图：

只有你系统中的benchmark可以帮助你判断正确的数据点和需求解决方案。但是MySQL的存储引擎会持续地不断改进和支持新出现的需求。LSM树是为了高写入场景的系统，然而B树是为了传统的场景应用。Fractal树的索引改进了B树索引存在的一些缺陷。因此，未来会不断地出现技术上的革新，包括数据库存储技术，硬件，磁盘驱动和操作系统，让我们拭目以待。责任编辑人：CC

以上知识分享希望能够帮助到大家！