如何选择合适的数据库？

虽然使用您知道的数据库始终是一个不错的选择，但密切关注一些新技术是有意义的。

数据库通常是应用程序中最大的性能瓶颈之一。一旦在生产中使用，很难迁移，因此为应用程序的数据库做出正确的选择是至关重要的。

做出正确决定的很大一部分是了解您的选择。在过去的几年中，数据库格局一直在迅速变化，因此本文将通过讨论以下主题来尝试为您简化事情：

• 2023年数据库生态概览

• 从技术角度来看，实际上是什么让不同类型的数据库表现不同

• 何时使用专用数据库与通用数据库

2023 年的数据库市场格局

在深入探讨之前，让我们看一下当前数据库生态系统的快照以及各种类型数据库的市场份额：

如您所见，尽管围绕 NoSQL 数据库大肆宣传，关系数据库仍然是最常用的数据库类型。然而，如果我们看一下最近的趋势，排名就会略有不同。

这张图表显示，在过去的两年里，关系数据库在一些不同类型的数据库模型面前失去了一些优势。以下是开发人员采用的一些主要数据库模型：

• 文档数据库

• 图数据库

• 时间序列数据库

• 列式数据库

• 内存数据库

• 键值数据库

• 搜索引擎数据库

是什么让数据库表现不同？

当谈到数据库性能时，没有什么神奇的东西可以让一个人比另一个人表现得更好。与所有计算机科学一样，它归结为允许针对特定用例优化性能的权衡。具体对于数据库，CAP 定理很好地介绍了为调优性能所做的一些可能的权衡。

例如，在 NoSQL 数据库的早期，人们对其可扩展性进行了大量宣传，但权衡通常涉及牺牲标准关系数据库提供的数据一致性保证。

其他一些会影响数据库性能的设计因素：

• 磁盘存储格式——数据库在硬盘上实际存储和组织数据的方式对性能有重大影响。随着越来越多的公司开始存储大量用于分析工作负载的数据，以基于列的格式（如Parquet）将数据存储在磁盘上越来越受欢迎。

• 主索引数据结构——数据库如何索引数据也会对性能产生重大影响。数据库通常有一个由其存储引擎使用的主索引，然后允许用户定义二级索引。索引将有助于提高读取性能，但会增加写入新数据点的开销。

• 数据压缩——数据的压缩方式将影响存储数据的成本和数据库的查询性能。一些压缩算法旨在尽可能减少数据的大小。其他压缩率可能较低，但在解压缩数据时速度更快，这意味着您可以获得更好的数据查询性能。

• 热存储和冷存储——许多数据库系统现在允许数据在更快和更昂贵的“热”存储与更便宜但更慢的“冷”存储之间移动。从理论上讲，这可以为频繁查询的数据提供更好的性能并节省存储费用，同时仍然允许访问冷存储中的数据而不是彻底删除。

• 持久性/灾难恢复——数据库如何处理灾难恢复对性能也有影响。设计数据库以减轻各种故障通常会降低性能，因此对于某些数据不是关键任务且偶尔丢失数据点没有问题的场景，数据库可以删除一些安全性保证以挤出更好的性能。

所有这些因素以及许多其他未涵盖的因素都会影响数据库的性能。通过扭转这些杠杆，数据库可以针对非常具体的性能特征进行优化，并且牺牲某些东西实际上不会成为问题，因为在某些情况下不需要它们。

何时为您的应用程序使用专用数据库

决定为您的应用程序使用哪个数据库有很多因素。让我们来看看在为您的应用程序选择数据库时需要考虑的一些主要事项。

数据访问模式

选择数据库的主要因素是如何创建和使用应用程序中的数据。最广泛的入手方式可能是确定您的工作负载是联机分析处理 (OLAP)还是联机事务处理 (OLTP)。OLAP 工作负载以分析为中心，与关系数据库旨在处理的更标准的 OLTP 工作负载相比，具有不同的访问模式。OLAP 查询一般只命中少数几个列来执行计算，可以使用为此设计的列式数据库进行优化。例如，由于性能优势，大多数数据仓库都建立在面向列的数据库之上。

一旦您大致确定了工作负载的类型，您现在需要考虑查询的延迟要求以及写入数据的频率等问题。如果您的场景需要低延迟的近实时查询来执行诸如监控之类的任务，您可能会考虑一个时间序列数据库，该数据库旨在处理高写入吞吐量，同时还允许在摄取后立即查询数据。

对于 OLTP 样式的工作负载，您通常会在关系数据库或文档数据库之间做出决定。这里的关键因素是查看您的数据模型并确定您是想要 NoSQL 文档数据库提供的模式灵活性，还是更倾向于关系数据库提供的一致性。

您可以考虑的最后一件事是，您的服务是不是只要保证最终一致性即可，另外它是否会“突发”并要求数据库偶尔处理大量的读取和写入。在这种情况下，可以考虑使用轻松扩展和缩小硬件的数据库是有意义的，这样您就不会面临停机或大多数时间不需要的高成本硬件。

内部知识

在决定使用什么数据库时，应考虑您团队的现有技能组合。确定使用专用数据库的潜在收益是否值得投资（学习新技术的同时会损失一定的生产力）。

如果您知道您正在构建的服务不需要针对性能进行全面优化，那么可以使用您的团队最熟悉的任何数据库来完成工作。另一方面，如果您知道性能至关重要，那么采用新数据库的痛苦可能是值得的。

架构复杂性

保持软件架构尽可能简单是最理想的，因此向系统添加另一个组件（如新数据库）应该权衡管理数据库会给系统增加的额外复杂性。

如果您的应用程序非常适合专用数据库，以至于它可以充当应用程序数据的主数据库，那么这不是什么大问题。另一方面，如果您将使用更通用的数据库作为应用程序的主要存储，那么为数据子集引入额外的数据库可能不值得，除非您面临严重的性能问题。

结论

数据库生态系统正在迅速发展。虽然使用您知道的数据库始终是一个不错的选择，但对于开发人员来说，密切关注正在发布的一些新技术并查看它们是否适合您正在构建的内容是有意义的。构建在专用数据库上可以帮助您的应用程序以多种方式取得成功，为您节省成本、提高用户性能、使其更易于扩展并提高开发人员的工作效率。

原创不易，随手关注或者”在看“，诚挚感谢！