2023 年如何选择合适的数据库
作者：Charles Mahler / 用例
2023 年 4 月 3 日
导航至
本文最初发表于 The New Stack，并经许可在此处转载。
数据库通常是应用程序中最大的性能瓶颈。一旦投入生产使用，也很难迁移，因此为您的应用程序选择合适的数据库至关重要。
做出正确决定的很大一部分是了解您的选择。在过去的几年中，数据库领域一直在快速变化，因此本文将尝试通过介绍以下主题来为您简化事情
- 2023 年数据库生态系统的概述
- 从技术角度来看，是什么真正导致不同类型的数据库性能不同
- 何时使用专用数据库与通用数据库
2023 年的数据库格局
在深入探讨之前，让我们先看一下当前数据库生态系统的快照以及各种类型数据库的市场份额
正如您所见，尽管围绕 NoSQL 数据库的炒作不断，但关系数据库仍然是最常用的数据库类型。但是，如果我们查看近期趋势，排名会呈现略有不同的情况。
此图表显示，在过去两年中，关系数据库的市场份额略有下降，让位于几种不同类型的数据库模型。以下是一些主要数据库模型，它们正在获得开发人员的采用
是什么让数据库性能不同？
在数据库性能方面，没有什么神奇之处能使一个数据库比另一个数据库表现更好。像所有计算机科学一样，这归结为权衡，从而可以针对特定用例优化性能。对于数据库而言，CAP 定理 是对为调整性能而做出的一些可能权衡的一个很好的介绍。
例如，在 NoSQL 数据库的早期，围绕其可扩展性有很多炒作，但权衡通常涉及牺牲标准关系数据库提供的数据一致性保证。
一些其他会影响数据库性能的设计因素
- 磁盘存储格式 — 数据库实际在硬盘驱动器上存储和组织数据的方式对性能有重大影响。随着越来越多的公司开始存储用于分析工作负载的海量数据，以 基于列的格式（如 Parquet）在磁盘上存储数据正变得越来越流行。
- 主索引数据结构 — 数据库索引数据的方式也会对性能产生重大影响。数据库通常具有存储引擎使用的主索引，然后允许用户定义二级索引。考虑索引的最简单方法是，它们将有助于提高读取性能，但会增加写入新数据点的开销。
- 数据压缩 — 压缩数据的方式将影响存储数据的成本和数据库的查询性能。一些压缩算法旨在尽可能减小数据的大小。另一些算法可能具有较低的压缩率，但在解压缩数据时速度更快，这意味着您可以获得更好的数据查询性能。
- 热存储和冷存储 — 许多数据库系统现在允许数据在更快、更昂贵的“热”存储和更便宜但更慢的“冷”存储之间移动。从理论上讲，这可以为频繁查询的数据提供更好的性能，并节省存储成本，同时仍然允许访问冷存储中的数据，而不是完全删除。
- 持久性/灾难恢复 — 数据库处理灾难恢复的方式也会影响性能。设计数据库以减轻各种故障通常会降低性能，因此对于某些数据并非任务关键型且偶尔丢失数据点也没问题的用例，数据库可以删除一些安全保证以挤出更好的性能。
所有这些因素，以及许多未涵盖的其他因素，都会影响数据库的性能。通过调整这些杠杆，可以针对非常特定的性能特征优化数据库，而牺牲某些东西实际上不会成为问题，因为在特定情况下不需要它们。
何时为您的应用程序使用专用数据库
在决定为您的应用程序使用哪个数据库时，需要考虑许多因素。让我们看一下在为您的应用程序选择数据库时需要考虑的一些主要事项。
数据访问模式
选择数据库的主要因素是您的应用程序中的数据将如何被 创建和使用。最广泛的入手方法可能是确定您的工作负载是 在线分析处理 (OLAP) 还是在线事务处理 (OLTP)。OLAP 工作负载以分析为中心，与关系数据库旨在处理的更标准的 OLTP 工作负载相比，具有不同的访问模式。OLAP 查询通常只命中几列以执行计算，并且可以通过使用为此设计的列式数据库进行优化。例如，大多数 数据仓库 都建立在面向列的数据库之上，这归功于性能优势。
在您大致确定了工作负载的类型后，您现在需要考虑查询的延迟要求以及数据写入的频率等因素。如果您的用例需要近乎实时的低延迟查询来进行 监控 等任务，您可能会考虑使用时间序列数据库，该数据库旨在处理高写入吞吐量，同时还允许在摄取后不久查询数据。
对于 OLTP 风格的工作负载，您通常会在关系数据库或文档数据库之间做出决定。这里的关键因素是查看您的数据模型，并确定您是想要 NoSQL 文档数据库提供的架构灵活性，还是更喜欢关系数据库提供的一致性保证。
您可以考虑的最后一件事是，您是否期望您的工作负载在一天中相当一致，或者它是否会是“突发性”的，并要求您的数据库偶尔处理远大于平常的读取和写入量。在这种情况下，使用一种可以轻松扩展和缩减硬件的数据库是有意义的，这样您就不会面临停机时间或大部分时间不需要的硬件的高成本。
内部知识
在决定使用哪个数据库时，应考虑您团队现有的技能组合。您需要确定使用专用数据库的潜在收益是否值得投入培训您的团队学习如何使用它以及学习新技术时损失的生产力。
如果您知道您正在构建的服务不需要完全针对性能进行优化，那么使用您的团队最熟悉的任何数据库来完成工作是可以的。另一方面，如果您知道性能至关重要，那么采用新数据库的成长痛苦可能是值得的。
架构复杂性
保持软件架构尽可能简单是理想的，因此向系统中添加另一个组件（如新数据库）应权衡管理数据库将给系统带来的额外复杂性。
如果您的应用程序非常适合专用数据库，以至于它可以充当应用程序数据的主数据库，那么这不是什么大问题。另一方面，如果您将使用更通用的数据库作为应用程序的主要存储，那么除非您面临严重的性能问题，否则为数据的子集引入额外的数据库可能不值得。
结论
数据库生态系统正在迅速发展。虽然使用您熟悉的数据库始终是一个不错的选择，但开发人员有必要关注正在发布的一些新技术，看看它们是否适合您正在构建的东西。构建在专用数据库之上可以通过多种方式帮助您的应用程序取得成功，例如为您节省成本、提高用户性能、使其更易于扩展和提高开发人员的生产力。
