以下是判断数据库何时适合您的项目的方法。

当您为最新用例选择数据库时（或更换不满足当前需求的数据库），现在的好消息是您有很多选项可供选择。当然，这也是坏消息。你有很多东西要整理。

有比以往更多的数据库需要考虑和比较。2012 年 12 月，即 DB-Engines.com 首次开始对数据库进行排名的第一年年底，他们列出了73个系统（比他们最初列出的18 个系统有了显着增加）。截至 2022 年 12 月，他们只有不到 400 个系统。这代表了过去十年数据库技术的寒武纪大爆发。有大量的选项可供导航：SQL、NoSQL 和“多模型”数据库的混合，可以是 SQL 和 NoSQL 的混合，或者 NoSQL 的多个数据模型（结合两个或更多选项：文档，键值、宽列、图表等）。

此外，用户不应将完全流行与适用于他们的用例相混淆。虽然网络效应肯定有优势（“如果每个人都在使用 X，它就不会出错”），但它也可能导致群体思维、扼杀创新和竞争。

我的同事 Arthur Pesa 和我最近讨论了用户在筛选和比较数据库时需要首先考虑的五个因素。

五个因素

让我们直接进入列表。

• 软件架构——数据库是否使用最高效的数据结构、灵活的数据模型和丰富的查询语言来支持您的工作负载和查询模式？
• 硬件利用——能否充分利用现代硬件平台？或者您是否会留下大量未充分利用的 CPU 周期？
• 互操作性——集成到您的开发环境中有多容易？它是否支持您的编程语言、框架和项目？它是否旨在集成到您的微服务和事件流架构中？
• RASP——它是否具有可靠性、可用性、可扩展性、可维护性，当然还有性能的必要品质？
• 部署——这个数据库是否只能在有限的环境中工作，比如只能在本地，或者只能在单个数据中心或单个云供应商中工作？或者它是否适合在全球范围内以您想要的方式部署？

任何此类故障都是主观的。您可能有自己的 4 个因素列表，或 12 个、20 个或 100 个标准。当然，软件架构等这些因素中的每一个都分解为子类别，例如“存储引擎”、“分布式处理架构”，甚至“查询语言”。但这就是我将它们分为一般类别的方式。

软件架构

这里的关键考虑因素是“数据库是否使用最有效的数据结构、灵活的数据模型和丰富的查询语言来支持您的特定工作负载和查询模式？”

• 工作负载——您是否需要执行大量写入或混合读写的事务性工作负载？或者你打算做一个大部分阅读的分析工作量？您是否需要混合事务和分析的混合工作负载？该工作负载是实时的、批处理的还是混合的？是每秒稳定的事件流，还是平稳、规律的日内可预测涨跌？或者您是否需要计划应对突发流量的随机冲击（例如，突发新闻或任何其他突然流行的记录）？
• 数据模型——你在处理键值对吗？宽列存储（基于行的“键-键-值”数据）？列存储（列数据）？文档？图形？RDBMS（带有表和 JOIN）？或者完全是别的东西。您是否真的有时间并且需要对数据进行完全规范化，或者您是否会如此迅速地吸收如此多的非结构化数据以致于规范化是徒劳的，而您最好从非规范化数据模型开始？这里没有单一的“正确”答案。“这取决于”应该作为你的口头禅。
• 查询语言——这里肯定有更多的偏见。因为虽然您的数据工程团队可能能够掩盖或隐藏后端查询模型，但您的许多用户都有自己的偏见和偏好。这是 SQL 仍然如此锁定的主要原因之一。同时，还有新的查询语言可供使用。有些类似于 SQL，例如 Cassandra 和 ScyllaDB 使用的 Cassandra 查询语言 (CQL)。SQL 用户对它非常熟悉。但不要被愚弄——没有表 JOIN！然后是一系列新派的查询语言可能会用到，比如JSON。这就是 Amazon DynamoDB 查询的工作方式。同样，在这里，ScyllaDB 使用我们的 Alternator 接口支持这样的 JSON 查询模型，它与 DynamoDB 兼容。不管你往哪个方向倾斜，
• 交易/运营/ CAP——哪个对你更重要？完全一致的 ACID 事务？还是高性能、高可用的基本 CRUD 操作？CAP 定理说您可以拥有以下三个中的任意两个：一致性、可用性或分区容错性。考虑到分布式数据库始终需要分区容忍，这让您可以在所谓的“CP”模式一致性导向系统或“AP”模式可用性导向系统之间做出选择。在这些模式中，需要考虑实施细节。例如，在分布式系统中实现强一致性的方式可能千差万别。甚至考虑选择各种共识算法来确保线性化，如 Paxos、Raft、Zookeeper (ZAB) 等。除了不同的算法之外，每个实现都可能与另一个有很大差异。
• 数据分布——当你说“分布式系统”时，你到底指的是什么？我们是在谈论本地的单数据中心集群吗？或者我们在谈论多数据中心集群？跨集群更新是如何发生的？它是否被视为所有一个逻辑集群，还是需要集群间同步？它如何处理数据本地化，例如 GDPR 合规性？

硬件利用率

我们正处于底层硬件的持续革命之中，这场革命继续推动软件的发展。许多软件应用程序，尤其是许多数据库，仍然植根于几十年前的起源、设计和假设。

• CPU 利用率/效率——如果 CPU 利用率超过 40% 或 50%，很多软件就会运行不佳。这意味着您应该低效地运行该软件，定期让一半的机器未得到充分利用。实际上，您支付的基础设施费用是您实际需要的两倍（或更多）。因此，您有必要查看您的系统处理分布式处理的方式。
• RAM 利用率/效率——您的数据库是否始终受内存限制？它的缓存是否过于激进或过于臃肿（例如具有多层缓存），将不需要的数据保留在内存中？它如何优化其读写路径？
• 存储利用率/效率——你的数据库使用什么存储格式？它是否具有可能需要重量级文件锁定机制的紧凑型可变表？或者它是否使用可能产生快速写入但以空间和读取放大为代价的不可变表？它是否允许分层存储？它如何处理并发？文件是按行存储（适合事务用例）还是按列存储（适合对高度重复的数据进行分析）？请注意，不只有一个“正确”答案。每个解决方案都针对不同的用例进行了优化。
• 网络利用率/效率——在这里您应该同时考虑客户端-服务器集群通信的效率，以及集群内通信的效率。通过并发、连接池等，可以使客户端/服务器模型更加高效。集群内通信涵盖典型的操作/交易聊天（在更新或写入中复制数据），以及管理任务，例如在拓扑更改期间在节点之间流式传输和平衡数据。

互操作性

没有数据库是一座孤岛。集成到您的开发环境中有多容易？它是否支持您的编程语言、框架和项目？它是否旨在集成到您的微服务和事件流架构中？

• 编程语言/框架——您一遍又一遍地听到“我们是一家X商店”，其中X代表您首选的编程语言或框架。如果您的数据库没有必要的客户端、SDK、库、ORM 和/或其他包来将其集成到该语言中，那么它可能不存在。公平地说，数据库的大规模爆炸与编程语言的大规模爆炸同时发生。然而，查看对客户端的编程语言支持是值得的。请注意，这与数据库本身可能编写的语言不同（这可能会影响其软件架构和效率）。这纯粹是关于您可以使用哪些语言编写应用程序来连接到该后端数据库。
• 事件流/消息队列——数据库可能是单一的事实来源，但它们并不是您公司中运行的唯一系统。事实上，您可能拥有不同的数据库，它们都在处理、分析和共享公司整体数据和信息空间的不同部分。事件流是现代企业避免数据孤岛的越来越普遍的媒体，如今，您的数据库只有与实时事件流和消息队列技术集成才能发挥作用。您的数据库能否同时充当数据接收器和数据源？它是否具有变更数据捕获 (CDC)？它是否连接到您最喜欢的事件流和消息队列技术，例如 Apache Kafka、Apache Pulsar 或 RabbitMQ？
• API——为了促进您的数据库集成到您的应用程序和微服务架构中，您的数据库是否支持一个或多个 API，例如 RESTful 接口或 GraphQL？它是否具有管理 API，以便您可以通过编程方式配置它而不是通过 GUI 界面执行所有操作？起初使用 GUI 似乎很方便，直到您必须管理和自动化您的部署系统。
• 其他集成——CI/CD 工具链呢？可观察性平台？如何将您的数据库用作可插拔存储引擎或更广泛架构的底层元素？它作为基础设施的作用如何，或者适合您已经使用的基础设施？

RASP

这个首字母缩略词可以追溯到几十年前，通常用于硬件上下文中。它代表可靠性、可用性、可维护性（或可扩展性）和性能。基本上，这些“-ilities”是“facilities”——让你的系统运行起来更容易的东西。在数据库中，考虑您可能需要执行多少手动干预和“转盘”以保持系统正常运行和稳定是至关重要的。它们表示数据库在一般操作条件下可以在多大程度上照顾好自己，甚至尽可能地减轻故障状态。

典型的平台工程师启动了一堆新节点。

• 可靠性——为了防止这个东西崩溃或数据消失，你需要进行多少修补？你的数据库是否具备良好的持久化能力？它的生存能力如何？它包括什么反熵机制来让集群恢复同步？您的备份系统有多好？更重要的是，您的还原系统有多好？是否有操作护栏来防止个人用一个“哎呀！”把事情搞砸了？
• 可用性——当您遇到短期网络分区和临时节点不可用时，您的数据库会做什么？当一个节点完全失败时会发生什么？如果网络故障持续超过几个小时怎么办？
• 可服务性——如今流行的流行语是“可观察性”，它通常包含日志记录、跟踪和指标这三大支柱。当然，您的数据库需要内置可观察性。然而，可维护性远不止于此。在不停机的情况下执行升级有多容易？维护操作有多轻松？
• 可扩展性——一些数据库非常适合入门。然后……你撞墙了。难的。可扩展性意味着您不必担心在管理的总数据量、每秒总操作数或地理限制方面达到极限——例如超越单个数据中心以实现真正的全球部署。此外，还有水平可扩展性——向集群添加更多节点的横向扩展——以及垂直可扩展性——将您的数据库放在具有不断增加的 CPU 数量、更多 RAM 和更多存储的服务器上（参见硬件部分）多于）。
• 性能——底线：如果数据库不能满足您的延迟或吞吐量 SLA，它就不会在生产中运行。此外，与可扩展性相关，许多数据库似乎可以在小规模下或基于使用测试数据的静态基准满足您的性能要求，但当遇到实际生产工作负载时，就无法跟上不断增加的频率、可变性和查询的复杂性。因此性能需要与线性比例有很强的相关性。

部署

然后，以上所有内容都需要在您需要的地方运行。这个数据库是否只能在有限的环境中工作，比如只能在本地，或者只能在单个数据中心或单个云供应商中工作？或者它是否适合在全球范围内以您想要的方式部署？问自己这些问题：

• 锁定——这可以在本地运行吗？或者，相反，它是否仅限于本地部署？它仅限于某个公共云供应商，还是可以在您选择的云供应商中运行？您的混合云或多云部署选项是什么？
• 管理/控制——同样，这是否只能作为自我管理的数据库使用，还是可以作为完全托管的数据库即服务 (DBaas) 使用？前者允许团队完全控制系统，后者减轻团队的管理负担。两者都有其权衡。只能选择一个，还是数据库允许用户在这两种商业模式之间切换？
• 自动化和编排——是否有 Kubernetes Operator 在生产中支持它？Terraform 和 Ansible 脚本？虽然这是列表中的最后一项，但请放心，在任何生产考虑中都不应事后考虑。