数据库选型

一、我们所说的数据库是什么意思

数据库管理系统（正确术语），它将基于文本的信息存储在硬盘驱动器/SSD 上，以便立即（几秒钟）访问。

这意味着我们不是在谈论：

• 纯内存缓存，例如Memcached，一旦进程停止就会丢失数据。
• 文件或其他存储方式，例如AWS S3或Azure 托管磁盘。
• 长期存档和数据仓库解决方案，例如AWS Glacier。

那么如何为您的项目选择合适的数据库呢？

二、专有的还是开源的

让我们从一个平凡的商业问题开始：您准备好为您的数据库付费了吗？这不涉及为基于云的产品付费（我们将在下一段中讨论这些），而是为自托管的本地数据库提供许可证。

但是等等——难道没有很棒的开源数据库可以免费使用吗？嗯 - 是的，但许多公司更喜欢 99.999% 正常运行时间 SLA 带来的安心，第一支持可以在早上 5 点致电。事实上，前十大最受欢迎的数据库中有四个带有商业许可证（Oracle、Microsoft SQL Server、IBM DB2和Microsoft Access），其中包括第一名（Oracle）。

三、云还是自托管

运行数据库非常简单：您只需单击可执行文件或启动服务，您的数据库服务器就会很好地运行。但实际上在生产环境中运行数据库真的很难。分片、创建读写副本、连续备份、不停机更新——唷——我猜 DB-Admin 是一个工作档案是有原因的。

如果这不适合您，您最好使用托管数据库作为云服务的一部分。在这里，我们需要区分两个类别——我们称它们为“托管”和“无服务器”：

托管数据库是一种云服务，它为您提供一个经常流行的开源数据库作为完全托管的服务。AWS RDS就是一个例子，运行 MySQL/MariaDB/Postgres 等实例。这里的问题是您仍然需要做出诸如“数据库有多大/我需要多少实例？”、“我想要多久进行一次备份以及将它们存储在哪里？”之类的决定。等等。

如果您不想这样做，现在可以提供不断增长的“无服务器”或“即服务”数据库。这些是云提供商的专有产品，可让您简单地连接到端点并存储数据。AWS DynamoDB、Azure CosmosDB和Google Firebase就是这样的例子。

四、数据模型

现在可能是最重要的问题：哪种模型最适合您的数据结构？

1、关系/表

关系数据库将数据行存储在具有多列的表中，每列都有自己的数据类型（文本、数字、日期等）。每一行都由一个唯一的 id 标识，称为“主键”。通过从其他行引用此键来指定数据之间的关系。

通常使用具有丰富功能词汇表的富有表现力的“结构化查询语言”（SQL）创建和读取数据。

为什么选择关系数据库？

关系数据库是最常见和最广泛使用的类型 - 并且有充分的理由。该模型虽然不灵活，但却是可靠的，避免了数据重复，并使开发人员能够使用保存和可预测的结果。此外，该类别包含许多可用的最成熟的数据库，例如PostgreSQL或MySQL - 成熟度以及由此产生的稳定性和安全性可能是选择任何数据库时最重要的因素。

为什么不选择关系数据库？

关系数据库的预定义表结构通常是相当静态的。虽然可以修改现有表的列，但这确实会带来一些开销。同样，每列只能存储某种类型的数据。这有助于数据库管理系统减少存储空间并避免重复，但 NoSQL 运动的支持者（见下一段）认为存储空间已经变得如此便宜和丰富，以至于这种灵活性的折衷已经没有多大意义了。

2、对象/文档/NoSQL 数据库

除了一些例外，这些数据库将与给定对象（例如应用程序的用户或记录目录中的专辑）相关的所有信息存储在单个、松散结构的 JSON 数据块中，称为“对象”或“文档”。相同类型的多个文档排列在“列表”或“集合”中。对象数据库在如何创建、读取和搜索数据方面差异很大，从 RESTful API ( CouchDB ) 到 Map-Reduce ( MongoDB ) 等函数式编程概念。

为什么选择对象数据库？

几年前，NoSQL 的炒作如浪潮般席卷了通常如此平静的数据库环境。NoSQL 不是一个概念，它是一种运动：“打倒关系数据库！” 风靡一时。今天，在无数 DevOps 紧急情况和后来过于仓促的迁移之后，NoSQL 在存储解决方案中找到了它应有的位置——作为正确任务的绝佳工具，而不是治愈所有疾病的灵丹妙药。只需将不同结构的文档放入同一个集合中即可带来的灵活性，不必担心数据类型和强关系并将其留给 DBMS 进行分类，这些都是让开发人员的生活更轻松的好方法。

为什么不选择对象数据库？

有点混乱可能很好——但是对象数据库缺乏强制执行需要通过开发人员的纪律和警惕来弥补——这在大公司中不是一个容易的要求。同样，高度相关的数据仍然更好地存储在关系或图形数据库中，只有具有相当隔离数据集的用例子集非常适合文档/集合模型。

3、图形数据库

图形数据库提供了另一种思考数据中关系的方式，并且可以在严格的表格和松散的文档之间做出很好的折衷。在图形数据库中，每个实体（节点）都是一个独立的文档，列出了一组可嵌套的属性。这些节点由指定它们关系的“边”连接。边可以有自己的属性。这听起来可能很复杂，但可以这样想：像“约翰有四个红苹果”这样的语句可以分解为约翰（节点 A）有（边缘）四个（边缘属性）红色（节点 B 属性）苹果（节点乙)"

大多数 GraphDB 都带有丰富的工具集来查询、遍历和评估复杂的节点和边网络，例如查找所有连接的节点、连接最多的节点、最近的邻居等。

为什么选择 GraphDB？

GraphDB 是构建高度互连数据的好方法。如果您正在构建一个支付系统，在单个交易中的多个账户之间进行货币易手，那么 GraphDB 将显着降低例如通过多个步骤跟踪单个支付的复杂性。

为什么不选择 GraphDB？

对于更简单的用例，GraphDB 可能会带来相当多的开销。尤其是线性数据系列，例如会话日志，不太适合图形模型。此外，在图表中思考可能是此列表中最具挑战性的模型，这给开发人员带来了额外的压力。

4、键值存储

有时，您所需要的只是一种快速存储某些数据的方法，这些数据由键标识 - 而键值存储让您可以做到这一点。它们的简单性使得访问速度非常快，这使得它们非常适合非关系数据 - 例如像 bit.ly 这样的 URL 缩短器，它只需要查找原始 URL 以获取短代码，而无需进行复杂的查询。

何时使用键值存储？

如果您的数据的简单性允许，键值存储可以帮助您快速且廉价地扩展。

什么时候不使用键值存储？

如果您的数据是关系数据、具有复杂结构或需要查询和搜索。

5、宽列存储

想象一下具有第二维的键值存储——或者更好的是，具有任意数量的动态列和行的无限 Excel 电子表格。宽列存储可以快速查找行、列或它们的交集，并允许快速写入或读取大量数据。

何时使用宽列存储？

如果您能想象将所有数据组织在一张巨大的 Excel 表格中。WCS 的简单数据模型使其能够很好地扩展，并使复制和分片变得容易。

什么时候不使用宽列存储？

虽然Apache Cassandra等一些商店支持基本查询，但聚合（总和、计数、平均值）等更高级别的功能可能仍然不受限制。同样，许多宽列存储提供最终一致性而不是强一致性，这使得它们成为事务应用程序的糟糕选择。

6、时间序列数据库

时间序列数据库只做一件事并且做得很好。它们存储具有二维的线性数据序列，通常是时间和一个或多个值。时间序列经常用于服务器监控或财务记录，但绝不是通用解决方案。

为什么选择时间序列数据库？

如果您必须有效地存储和查询时间序列数据。如果您的应用程序只有一些时间序列方面，那么关系数据库可能就足够了。许多时间序列数据库还提供有用的更高级别的功能，例如当某个值被破坏时发出警报。

为什么不选择时间序列数据库？

如果您的数据不是时间序列，或者您只需将少量时间序列数据存储为较大应用程序的一部分。

7、其他类型数据库

这涵盖了数据库的主要类别。然而，还有许多更专业的类型，例如复制底层数据库数据的搜索引擎，例如Elasticsearch或用于 XML 或 YAML 的特殊格式存储。此外，还有许多多概念数据库，例如将关系数据和图形数据结合起来，或者允许创建几乎类似于对象的灵活性的动态表结构。根据您的要求，它们可能是一个不错的选择。

五、其他考虑因素

1、扩展性和一致性

许多数据库提供“强”一致性——保证所有写入都已完成，并且所有数据在读取时都是最新的——即使 DB-Cluster 中的某些节点发生故障或发生其他混乱事件。这会带来很大的性能开销，但对于许多应用程序来说，这是绝对必要的。要确定数据库是否满足您的一致性要求，您可能需要查找其“ACID 合规性”（原子性、一致性、隔离性、持久性）。要更深入地测试和了解其在故障情况下的行为，请查看其相关的Jepsen 报告。

2、实时查询、警报、触发器和其他功能

除了纯粹的数据存储和检索之外，许多数据库还提供其他功能。实时查询（随着基础数据变化而更新其结果集的查询）例如由RethinkDB提供，其他如Elasticsearch或Algolia提供复杂的全文搜索，包括词干和同义词，甚至其他如PostgreSQL（作者最喜欢的： -) 是有效的完全可编程的数据环境，具有触发功能和发布-订阅消息传递。

有了上述内容，我建议您确定您的标准 - 一旦您必须前往DB Engines Ranking，它列出了每个可以想象的数据库，并根据其受欢迎程度进行评分。在那里，选择一两个符合您标准的最受欢迎的选项，并将您的项目带到明星！