如何选择合适的数据库？

数据库常常是应用系统中最大的性能瓶颈。一旦部署到生产环境中，就很难迁移，因此为应用系统选择合适的数据库至关重要。​

做出正确决定的一个重要部分是知道面临哪些选择。数据库领域在过去几年迅速发生了变化，本文将试图探讨以下几个主题：​

• 概述2023年的数据库生态系统。​
• 从技术角度阐述到底是什么因素使不同类型的数据库有不同的性能。​
• 何时使用专用数据库、何时使用通用数据库。​

2023年的数据库格局​

在深入研究之前，不妨看一下当前的数据库生态系统以及各类数据库的市场份额：​

如您所见，尽管NoSQL数据库被大肆宣传，但关系数据库仍是最常用的数据库类型。如果我们看看最近的趋势，排名告诉我们略有不同的情形。​

该图显示，在过去的两年中，关系数据库已被几种不同类型的数据库模型多少抢去了地盘。以下是一些正日益被开发人员采用的主要数据库模型：​

• 文档数据库​
• 图形数据库​
• 时间序列数据库​
• 列式数据库​
• 内存数据库​
• 键-值数据库​
• 搜索引擎数据库​

什么让数据库有不同的性能？​

谈到数据库性能，没有什么神奇的因素使一种数据库的性能优于另一种数据库。与计算机科学界的所有事情一样，这归结为让企业可以针对特定用例优化性能的权衡。具体就数据库而言，CAP定理很好地介绍了为调优性能而可能做出的一些权衡。​

比如在NoSQL数据库的早期阶段，其可扩展性备受炒作，但代价通常是牺牲了标准关系数据库提供的数据一致性保证。​

会影响数据库性能的其他一些设计因素，包括如下：​

• 磁盘端存储格式——数据库如何在硬盘驱动器上实际存储和组织数据对性能有重大影响。随着更多的公司开始存储用于分析工作负载的大量数据，以Parquet等基于列的格式在磁盘上存储数据越来越受欢迎。​
• 主索引数据结构——数据库如何索引数据也会对性能产生重大影响。数据库通常有被存储引擎使用的主索引，然后允许用户定义辅助索引。简单来说，索引有助于提升读取性能，但为写入新数据点增加了开销。​
• 数据压缩——如何压缩数据将会影响到存储数据的成本以及数据库的查询性能。一些压缩算法旨在尽可能减小数据的大小。其他算法的压缩比可能较低，但在解压缩数据时速度更快，这意味着您可以获得更好的数据查询性能。​
• 热存储和冷存储——现在许多数据库系统允许数据在更快速更昂贵的热存储和更缓慢更便宜的冷存储之间移动。从理论上说，这可以为频繁查询的数据提供更好的性能，并节省存储成本，同时仍允许访问冷存储中的数据，而不是直接删除。​
• 持久性/灾难恢复——数据库如何处理灾难恢复对性能也有影响。设计数据库以应对各种故障通常会降低性能，因此对于一些用例（数据不是很关键，偶尔丢失数据点也没关系）而言，数据库可以摈弃一些安全保证以获得更好的性能。​

所有这些因素以及本文未提到的许多其他因素都会影响数据库的性能。通过调整这些因素，就可以针对非常具体的性能特征优化数据库，牺牲某些方面实际上不会成为问题，因为某些情况下不需要它们。​

何时为您的应用系统使用专门的数据库？​

决定为您的应用系统使用哪个数据库牵涉很多因素。不妨看看为应用系统选择数据库时需要考虑的几个主要因素。​

• 数据访问模式​

选择数据库的主要因素是如何创建和使用应用系统中的数据。最常见的入手途径莫过于确定您的工作负载是在线分析处理（OLAP）还是在线事务处理（OLTP）。OLAP工作负载以分析为中心，与关系数据库旨在处理的更为标准的OLTP工作负载相比，OLAP工作负载有不同的访问模式。OLAP查询通常只触及少数列来执行计算，可以通过使用为此设计的列式数据库进行优化。举例说，由于性能优势，大多数数据仓库构建在面向列的数据库之上。​

一旦大致确定了工作负载的类型，现在就需要考虑查询的延迟需求和写入数据的频率等方面。如果您的用例需要对监测之类的任务进行低延迟的近实时查询，可以考虑使用时间序列数据库，这种数据库旨在处理高写入吞吐量，同时还允许在摄取数据后很快查询数据。​

对于OLTP类型的工作负载而言，通常需要选择关系数据库还是文档数据库。这里的关键因素是查看数据模型，确定您是想要NoSQL文档数据库提供的模式灵活性，还是更喜欢关系数据库提供的一致性保证。​

可能考虑的最后一点是，您是否预计工作负载在一天当中相当一致，还是会呈“突发式”，要求数据库偶尔处理大得多的读写量。在后一种情况下，就有必要使用这种数据库：很容易扩增或缩减硬件，这样您不会因大多数时候不需要的硬件而面临停运或高昂成本。​

• 内部知识​

在决定使用什么数据库时，应该考虑到团队现有的技能组合。您需要确定使用专用数据库的潜在好处是否值得为此投入资源来培训团队学习如何使用它，是否值得为了学习新技术而牺牲生产力。​

如果您知道所构建的服务不需要针对性能全面优化，可以使用团队最熟悉的数据库来完成工作。另一方面，如果您知道性能很重要，克服采用新数据库带来的困难可能是值得的。​

• 架构复杂性​

确保软件架构尽可能简单很理想，因此为系统添加另一个组件（比如新数据库）应该与管理数据库将给系统增添的额外复杂性进行权衡。​

如果您的应用系统非常适合专门的数据库，它可以充当应用系统数据的主数据库，那么这不是一个大问题。另一方面，如果您将使用偏通用的数据库作为应用系统的主存储，那么为一小部分数据添加一种额外的数据库可能不值得，除非您面临严重的性能问题。​

结论​

数据库生态系统在迅速发展。虽然选择自己熟知的数据库始终是不错的选择，但开发人员有必要密切关注一些新发布的技术，看看它们是否适合自己构建的系统。搭建一种专门的数据库可以从许多方面帮助应用系统取得成功，比如节省成本、为用户提升性能、更容易扩展以及提高开发人员的生产力。