揭秘大数据时代的数据库存储引擎：关系型、NoSQL与NewSQL如何选择？
在大数据和AI时代，数据库成为各类应用不可或缺的紧张构成部分。而数据库中的数据依赖存储引擎进行管理，包罗数据的存储、查询、更新和删除等。因此，在计划体系时，选择正确的数据库存储引擎方案变得尤为紧张。这篇文章将以关系型、NoSQL和NewSQL数据库，以及OLTP、OLAP和HTAP处理方式为切入点，深入探究不同类型的数据库背后的存储引擎方案选型取舍。作者：文小飞
01 关系型数据库&NoSQL数据库&NewSQL数据库
下图展示了关系型数据库、NoSQL数据库、NewSQL数据库的发展过程。
https://img-blog.csdnimg.cn/direct/c43128cdc685455a803a777f93f4203b.png
1. 关系型数据库
关系型数据库也称为SQL数据库，最早的数据库发展可以追溯至1970年IBM研发的第一个SQL数据库System R，这也是最早的SQL数据库，再后来1980～1990年这段时间涌现出来了一些SQL数据库产品，例如Oracle、DB2、SQL Server、PostgreSQL、MySQL等。
到2000年左右，关系型数据库越来越丰富，出现了很多迄今一直在发挥紧张的组件，例如MySQL、Oracle等。
SQL数据库按照以“行”为单位的二维表格存储数据，这种方式最符合实际世界中的实体，同时通过事件的支持为数据的一致性提供了非常强的包管。因此SQL数据库主要适合的场景是读多写少的场景。
关系型数据库中为了适配不同的应用场景，通常会将存储引擎计划为插件式的接口。然而主流的存储引擎，仍然是读多写少的特点。以MySQL为例，InnoDB存储引擎被广泛运用，它通过B+树来存储索引和数据。B+树这种数据结构，由于其独特的特性使得查询的性能非常高。
B+树存储引擎实用于需要高效的数据查找、范围查询和顺序访问的场景。它在关系型数据库中被广泛应用，如MySQL的InnoDB存储引擎和Oracle的B+树索引。然而，B+树存储引擎对于频繁的数据插入和删除操纵可能会有肯定的开销，因为这会触发节点的分裂和合并操纵。
2. NoSQL数据库
在面对海量数据存储、高并发访问的场景下，关系型数据库的扩展性和性能会受到限定。随着互联网的飞速发展，到2000年左右，存储海量数据、高并发处理读写的需求变得非常显着。这对SQL数据库提出了巨大挑战。为相识决这个题目，出现了支持数据可扩展性、最终一致性的NoSQL数据库。因此，NoSQL数据库可以看作是基于SQL数据库的缺陷而诞生的一种新产品。
NoSQL组件普遍选择牺牲复杂SQL的支持及ACID事件功能，以换取弹性扩展本事和更高的读写性能。这类体系主要存储半结构化或非结构化数据。根据存储的数据种类，NoSQL数据库主要分为基于文档存储的文档数据库（Document-based Database）、基于键-值存储的键值数据库（Key-Value Database）、图数据库（Graph-based Database）、时序数据库（Time Series Datebase）、宽列式存储（Wide Column-based Store）以及多模数据库（Multi-Model Database）。
不同类型的NoSQL数据库特性如下图所示。
https://img-blog.csdnimg.cn/direct/36c11c6984144c7f832938b1987c5a4b.png
NoSQL数据库典型的特点是具备很高的读写性能，但数据一致性包管较弱。绝大多数的NoSQL数据库适合写多读少、写多读多的场景。以列式数据库、时序数据库而言，它们通过LSM的头脑，提供了非常高的写入性能。这类体系的存储引擎广泛意义上也称为LSM Tree存储引擎，这些体系单机的存储引擎有RocksDB、LevelDB等。别的再以键值数据库为例，它们绝大部分通过利用哈希表这种数据结构，外加内存介质存储数据。实现非常高的读写性能。Redis就是这类体系的典型代表。
3. NewSQL数据库
虽然NoSQL数据库办理了关系型数据库存储的缺陷，但它也没法完全替代掉关系型数据库。在NoSQL数据库出现后的一段时间内，互联网软件的构建基本上都是联合二者来提供服务。在不同的场景下选择不同的数据库进行存储数据。虽然如许的互助方式很好，但是在如许的模式下，一个用户可能会因为场景的不同而存储多份雷同的数据到不同的数据库中，当用户量级和存储数据量很小的环境下没什么题目。一旦量级发生厘革就会引发出新的题目。
随着存储数据量的不停增长，造成资源的浪费和成本的上升不容忽略。于是工业界和学术界都在寻找更好的办理方案，直到2010年左右，诞生了NewSQL数据库（也称为分布式数据库）。它的出发点是联合关系型数据库事件一致性，又具备NoSQL数据库的扩展性及访问性能。这无疑给体系的计划及实现带来了更大的挑战，NewSQL数据库不仅要思量单机环境下高效存储的题目，还需要思量多机环境下数据复制、一致性、容灾、分布式事件等题目。目前NewSQL数据库典型的代表作有TiDB、OceanBase、CockroachDB等。NewSQL数据库中绝大部分的体系照旧采用LSM 树存储引擎，来实现体系高性能的写入。
02 OLTP&OLAP&HTAP对比
在现代数据管理领域，OLTP、OLAP和HTAP是常见的数据库类型，它们各自针对不同的数据处理场景和需求。本文将对这三种数据库进行对比，以资助读者更好地理解它们的特点和实用性。
1. OLTP数据库
OLTP数据库（联机事件处理）是专门计划用于处理事件性工作负载的数据库体系。它们被广泛应用于业务应用步伐，如在线购物、银行生意业务和订单处理等。OLTP数据库的主要特点是高并发、低延迟和高事件吞吐量。它们通过支持ACID（原子性、一致性、隔离性和持久性）特性来确保数据的一致性和可靠性。OLTP数据库通常采用规范化的数据模子，以支持高效的事件处理和即时的数据更新。
OLTP数据库主要的功能是处理用户在线实时的哀求，直接为用户提供服务，因此这类数据库通常对处理哀求的时延要求比较高，绝大部分的哀求正常环境下会在毫秒级完成。OLTP数据库很多，除了大家最认识的关系型数据库（如MySQL、Oracle）外，尚有Redis、MongoDB等这些非关系型数据库。绝大部分的OLTP数据库则是采用B树、B+树甚至哈希表来构建存储引擎。
2. OLAP数据库
OLAP数据库（联机分析处理），它们专注于支持决策支持和分析工作负载。OLAP数据库用于处理大量数据的复杂分析查询和报表生成。OLAP体系的关键特点是高度可扩展、支持复杂的分析操纵和提供机动的数据聚合本事。为了实现这些特性，OLAP数据库通常采用了针对分析查询优化的特别数据结构，如多维数据模子（如星型或雪花模子）和列存储技能。别的，OLAP数据库还提供了机动的查询语言和数据切片、切块、钻取等功能，以支持交互式的数据分析和探索。
OLAP数据库在功能上侧重于对数据或者任务进行离线处理，它不直接对用户提供服务。OLAP体系对哀求的处理通常比OLTP慢得多，一般在秒级、分钟级甚至小时级，通常在数据统计、报表分析、保举体系数据聚合分析等场景用的比较多。这一类数据库典型的代表有HBase、Teradata、Hive、Presto、Druid、ClickHouse等。互联网企业往往都需要利用OLTP和OLAP。因此为了满足这两类需求，通常需要联合多个体系一起开辟利用。如许的做法固然是可行的，而且基本也是采用这种方式进行实现。绝大部分的OLAP数据库是采用LSM树构建存储引擎。
3. HTAP数据库
随着数据处理需求的不停演变，需要存储的数据量爆炸式增长，在这种模式下直接带来的存储成本题目成为新的抵牾点，人们开始探索是否能诞生一种数据库将OLTP和OLAP这两类应用合二为一呢？于是，HTAP（混合事件/分析处理）数据库应运而生。HTAP数据库旨在将OLTP和OLAP的功能集成到同一个数据库体系中，以满足实时分析和事件处理的需求。HTAP数据库通过在同一数据库上同时支持事件处理和分析查询，消除了数据复制和数据移动的需求，提供了更高的数据一致性和实时性。HTAP数据库通常采用了内存计算、分布式架构和智能查询优化等技能，以包管高性能和机动性。这类数据库既可以处理在线事件处理，又可以处理在线分析处理。可以认为HTAP=OLTP+OLAP。HTAP的主要代表有TiDB、OceanBase、CockroachDB等。
在选择数据库时，需要思量具体的业务需求和性能要求。如果您需要处理大量的事件性工作负载，如在线生意业务，那么OLTP数据库是一个理想的选择。如果您的需求是进行复杂的数据分析和报表生成，那么OLAP数据库可能更适合。而如果您需要同时满足实时分析和事件处理的需求，那么HTAP数据库是一个值得思量的选项。
总而言之，OLTP、OLAP和HTAP数据库各自针对不同的数据处理场景和需求。相识它们的特点和实用性，可以资助您在选择数据库时做出明智的决策，并确保满足业务的需求和性能要求。
03 总结
如果以组件的类型是关系型数据库还好坏关系型数据库，并联合服务的场景是OLTP照旧OLAP来对业界各种存储组件进行分别的话，可以得到如下图所示的结果。关系型数据库中既有为OLTP计划的，也有为OLAP计划的，同时尚有新兴发展起来兼容二者的HTAP数据库。这些体系都有各自实用的业务场景，它们在存储引擎选型时，往往会根据实用场景来决定。如果是读多写少的场景，通常会选择B+树、哈希表来构建存储引擎。而如果是写多读少的场景，往往会选择LSM树来构建存储引擎。
https://img-blog.csdnimg.cn/direct/8a05549d667646c68165670cac861afb.png
关于作者：文小飞 （网名：jaydenwen/jaydenwen123），大厂资深研发工程师、公司级讲师。曾就职于腾讯等互联网公司，从事底子架构、后端开辟、保举体系架构等工作，具有丰富的底子架构经验。对技能布满热情，尤其对存储引擎、分布式共识算法等技能有较为深入的理解，曾编写开源册本“自底向上分析 BoltDB 源码”，并发布“数据存储与检索”等网络课程。业余时间喜欢阅读开源项目源码，学习新技能。
− E N D − - END - −END−
本文摘编自《深入浅出存储引擎》，经出版方授权发布。
https://img-blog.csdnimg.cn/direct/1245ca5854144d81b0dbeb2ed7415278.png
延伸阅读《深入浅出存储引擎》 延伸阅读《深入浅出存储引擎》 延伸阅读《深入浅出存储引擎》
保举语：带你吃透存储引擎底层原理与实践本事，攻克业务难题。通过阅读本书，读者不仅能对存储引擎，尤其是单机的存储引擎有一个团体的框架，而且能对两类存储引擎的实现思路及背后原理有个深刻的掌握，只有深刻理解了存储引擎的背后实现原理，读者不仅可以本身动手开辟本身的存储引擎，更可以很快掌握关系型数据库或者NoSql这类组件的核心原理，对未来实际应用与开辟提供参考。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]