过去十年的巨大数据增长影响了应用程序和应用程序使用的几乎所有方面。 由于几乎所有的应用程序都在某个时候与数据库交互,这意味着数据库也需要适应使用条件的变化。 数据库技术在过去十年中有了显著的发展,以满足不断变化的应用程序的需求。 企业通常需要扩展、修改或替换其数据库,以满足新的业务需求。

在数据库管理系统(数据库管理系统)中,有许多级别会影响性能,包括数据库存储引擎的选择。 令人惊讶的是,许多企业不知道他们可以选择存储引擎,也不知道特定的存储引擎类型是为处理特定场景而设计的。 通常,最佳选择取决于所讨论的数据库被设计来实现什么功能。

随着Percona对Tokutek的收购,我们已经从一个主要是MySQL的公司转变为拥有几个基于蒙古数据库的软件选项。

蒙古数据库是一个跨平台、面向NoSQL文档的数据库。 它不使用传统的基于表的关系数据库结构,而是使用带有动态模式的JSON类型的文档。 目的是使某些应用程序数据类型的集成更容易和更快。

这篇博客（本系列的第一篇(将简要回顾蒙古数据库数据库存储引擎的一些可用选项,以及每种选项的优缺点。 希望它能帮助数据库管理员、信息技术人员和企业认识到,在蒙古数据库方面,您并不局限于单一的存储引擎选择。

数据库存储引擎是数据库管理数据库同步工具 系统用来创建、读取、更新和删除数据库数据的底层软件。 存储引擎应该被认为是数据库（服务器守护进程(的”门闩“，它控制数据库与内存和存储子系统的交互。 因此,存储引擎实际上不是数据库,而是数据库用来存储和检索信息的服务。 假设存储引擎负责管理存储在数据库中的信息,它会极大地影响数据库的整体性能（如果选择了错误的引擎,则可能会影响数据库的整体性能).

大多数存储引擎使用以下结构之一来组织：日志结构合并(LSM)树B、树或分形树。

• LSM树— LSM树的性能特征使得它对于提供对具有高插入量的文件的索引访问很有吸引力。 LSM树寻求提供日志类型存储引擎的出色插入性能,同时最小化在严格按照插入顺序”排序”的数据结构中搜索的影响。 LSM缓冲区插入、更新和删除是通过使用增加大小的日志层,然后按照排序顺序合并以提高搜索效率。
• 二叉树— b树是数据库中最常用的数据结构。 自20世纪70年代初问世以来,它们一直是久经考验的存储引擎”方法论”之一。“B-树数据维护方法使搜索非常有效。 然而,维护有序数据结构的需要会对插入性能产生不利影响。
• 分形树— 分形树索引是一种树型数据结构,非常类似于B树（专为高效搜索而设计)，但也将数据吸收到类似日志的结构中,以有效利用内存,从而提高插入性能。 分形树旨在高速摄取数据,以便与高带宽应用的存储进行高效交互。

分形树和LSM树听起来非常相似。 然而,主要的区别因素是他们将数据分类到树中进行高效搜索的方式。 当日志填满时，LSM树将一系列日志中的数据合并成一棵树。 分形树沿着树中适当的数据路径将数据分类成类似日志的结构（消息缓冲区).

这个问题不简单。 为了决定选择哪个引擎,有必要确定每个引擎提供的核心功能。 核心功能通常可以归纳为三个方面：

• 锁定类型— 数据库引擎中的锁定定义了如何控制对信息的访问和更新。 当数据库中的某个对象被锁定进行更新时,在更新完成之前,其他进程无法修改（或在某些情况下读取(数据。 锁定不仅会影响多少不同的应用程序可以更新数据库中的信息,还会影响对该数据的查询。 监控查询如何访问数据很重要,因为数据在被访问时可能会被更改或更新。 一般来说,这种延迟是最小的。 大部分锁定机制致力于防止多个进程更新相同的数据。 由于对数据的添加（插入语句(和更改（更新语句(都需要锁定,您可以想象使用同一个数据库的多个应用程序会产生重大影响。 因此,锁定机制的”粒度”会极大地影响”多用户(或”高度并发”)环境中数据库的吞吐量。
• 索引— 在搜索和恢复数据时,索引方法可以显著提高数据库性能。 不同的存储引擎提供不同的索引技术,有些可能更适合您存储的数据类型。 通常,集合中定义的每个索引都是引擎使用的特定类型的另一种数据结构(WiredTiger是B树，PerconaFT是分形树,等等). 与您的工作负载相关的数据结构的效率非常重要。 一种简单的方法是将每个额外的索引视为有性能开销。 与非写优化数据结构相比,写优化数据结构在高插入应用程序环境中对每个索引的开销更低。 对于需要大量索引的用例,选择合适的存储引擎会产生巨大的影响。
• 交易- 事务在更新或插入信息期间提供数据可靠性,使您能够向数据库中添加数据,但仅在应用程序执行的其他条件和阶段成功完成时提交该数据。 例如,当将信息（如货币信用(从一个帐户转移到另一个帐户时,您将使用事务来确保一个帐户的借记和另一个帐户的贷记都成功完成。 通常,你会听到这被称为”原子性” .”这意味着捆绑在一起的操作是一个不可变的单元：要么所有操作都成功完成,要么没有。 尽管RocksDB、PerconaFT和WiredTiger能够支持事务,但从版本3开始。2此功能在蒙古数据库存储引擎应用编程接口中不可用。 多文档事务不能在蒙古数据库中使用。 然而,原子性可以在单个文档级别实现。 根据蒙古银行的声明。,将来将支持多文档交易,但截至本文撰写之时,尚未确定具体日期。

现在我们已经建立了一个总体框架,我们将继续讨论引擎。 对于本系列的第一篇博客,我们将关注MMAPV 1(蒙古数据库在第3版之前的默认存储引擎).0)0 .

找到它：蒙古数据库或Percona构建

MMAPv1是蒙古数据库的原始存储引擎,也是MongoDB 3中的默认引擎。0和更早版本。 它是一个基于B树的系统,将存储交互和内存管理的大部分功能卸载给操作系统。 蒙古数据库基于内存映射文件。

MMAP存储引擎使用一个称为”记录分配”的过程来获取用于文档存储的磁盘空间。 所有记录都连续地位于磁盘上,当一个文档变得大于分配的记录时,它必须分配一个新记录。 新的分配需要移动文档并更新引用该文档的所有索引,这比就地更新花费更多的时间,并导致存储碎片。 此外,在当前的迭代中,由于记录空间的过度分配和缺乏对压缩的支持，MMAPv1通常会导致文件系统的高空间利用率。

如前所述,存储引擎的锁定方案是数据库整体性能中最重要的因素之一。 MMAPv1具有集合级锁定,这意味着一次只有一个插入、更新或删除操作可以使用集合。 这种类型的锁定方案在并发工作负载中创建了一个非常常见的场景,其中更新/删除/插入操作总是等待它们前面的操作完成。 此外,这些操作流入的速度往往比存储引擎以串行方式完成的速度更快。 把它放在上下文中,想象一下周日下午一家大型超市只有一条收银线开放：顾客很多,但是吞吐量很低！

考虑到MongoDB 3中存储引擎应用编程接口带来的存储引擎选择。0，很难想象一个应用程序需要MMAPv1存储引擎来优化性能。 如果你从字里行间去体会,你会得出这样的结论：蒙古银行。 假设默认引擎在v3中被切换到WiredTiger，我会同意。2.

大多数人不知道在存储引擎方面他们有一个选择,这个选择应该基于数据库工作负载的样子。 Percona的瓦迪姆 特卡琴科进行了一次出色的基准测试,比较了RocksDB、PerconaFT和WiredTiger的性能,以帮助区分这些发动机。

在下一篇文章中,我们将研究蒙古数据库新的默认存储引擎WiredTiger的来龙去脉。

最初由乔恩 托宾和戴夫 艾弗里撰写

cs